Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Aide | Shop Recherche
358 connectés 

 



 Mot :   Pseudo :  
 
 Page :   1  2
Page Suivante
Auteur Sujet :

[Debian Etch/BIND9] Un coup ça marche, un coup ça marche pas...

n°936611
Taz
bisounours-codeur
Posté le 23-07-2007 à 12:24:29  profilanswer
 

Reprise du message précédent :
Tu veux pas essayer avec ta debian en standalone sans forwarders ? Si ça fonctionne comme ça, bah c'est le netasq qui déconne.
 
C'est quoi la fréquence des problèmes ?

mood
Publicité
Posté le 23-07-2007 à 12:24:29  profilanswer
 

n°936633
Gf4x3443
Killing perfection
Posté le 23-07-2007 à 14:08:31  profilanswer
 

redvivi a écrit :

Lorsque le probleme survient (c'est à dire que je n'arrive plus à résoudre les noms de domaines internet sur le serveur debian), si je fais un dig sur le 10.48.254.254 (dig www.google.fr @10.48.254.254), là j'ai une réponse, tandis que le dig www.google.fr me donne un timeout.


 
Ouf, ca veut dire que pour les zones ou il ne forward pas, named répond correctement, quelle chance.
 
Et sinon à part ca, le souci arrive-t-il de la même manière qu'elle que soit le forwarder choisi? Que la requête parte d'un port privilégié ou pas?

n°936678
redvivi
Posté le 23-07-2007 à 16:20:50  profilanswer
 

Le souci est le même sur n'importe quel(s) forwarder(s) et BIND ne fonctionne pas (sur les adresses internet) si on ne met pas de forwarder (sinon je l'aurais mis depuis longtemps). Pour la fréquence du probleme je dirais une fois toutes les 10 minutes environ, parfois 5 minutes. Que veux tu dire par port privilégié ? BIND utilise invariablement le port 53 non ?

n°936680
Gf4x3443
Killing perfection
Posté le 23-07-2007 à 16:31:59  profilanswer
 

Pas exactement non.

 

DNS est majoritairement UDP (je dis bien majoritairement, DNS est stateless), et les requêtes DNS partent d'un port non privilégié (>1024) vers le 53, et la réponse se fait du 53 vers le port non privilégié. Et pour le forwarding, named fait pareil (depuis la version 8 je crois, du moins ca se configure, cf ce que je disais page 1)

 

Donc dépendamment de comment sont faites tes requêtes, et comment elles traversent ton firewall (ca fait quand même presque une page que je t'ai dit de t'intéresser aux sniffers genre ethereal/wireshark), on a du mal à visualiser ton problème.

 

Qui plus est, tes clients du coté de ton LAN, c'est quoi? des ouin ouin? Avant de faire des tests du coté de ces clients, faut bien faire le flushdns avant.

 

On est deux à te dire que si named résout correctement sa zone, et que ca merde ailleurs, il faut investiguer entre named et ton fw. Pour ca => sniffer. Même si j'ai une grosse option sur ton netasq, car les requêtes de résolution partent bien mais ne recoivent jamais de réponse... Donc quelque part, ca passe pas.


Message édité par Gf4x3443 le 23-07-2007 à 16:34:59
n°936685
redvivi
Posté le 23-07-2007 à 16:43:26  profilanswer
 

Ok, je vais investiguer la chose.....merci de votre patience et de votre aide en tout cas, si il y a du nouveau, je vous fait signe...encore merci

n°937502
redvivi
Posté le 26-07-2007 à 14:25:29  profilanswer
 

Je me demande si le serveur n'envoie pas de requêtes en IPV6 (record AAAA), plutot qu'en IPV4 (record A), ce qui pourrait expliquer ces timeouts et ces temps de réponses long, c'est possible ? Où peut on vérifier cette configuration ?
 
D'autre part, je vais déplacer le serveur sur un autre réseau physique pour vérifier si elle se comporte correctement.

Message cité 1 fois
Message édité par redvivi le 26-07-2007 à 14:26:24
n°937589
Gf4x3443
Killing perfection
Posté le 26-07-2007 à 17:08:10  profilanswer
 

redvivi a écrit :

Je me demande si le serveur n'envoie pas de requêtes en IPV6 (record AAAA), plutot qu'en IPV4 (record A), ce qui pourrait expliquer ces timeouts et ces temps de réponses long, c'est possible ? Où peut on vérifier cette configuration ?


 
Rien à voir. Ton serveur envoie des requêtes de résolution, et ce sont les réponses qu'il recoit des forwarders qui permettent de savoir si c'est IPv4 ou 6.
 
Un serveur DNS ne "transforme" pas des requêtes, vu que c'est le client (en appelant getaddrinfo) qui spécifie lui même ce qu'il veut (paramètres hints). Il ne fait que les forwarder à une autre machine; il ne modifie rien (quel beau bordel ca serait...)
 
Qui plus est, même si la réponse était IPv6, il y aura quand même une réponse, pas de timeout. Une résolution qui échoue retourne une erreur, pas un timeout (essaie par toi même pour t'en convaincre).

mood
Publicité
Posté le   profilanswer
 

 Page :   1  2
Page Suivante

Aller à :
Ajouter une réponse
 

Sujets relatifs
Debian Etch: iptables: Y a t il une politique par défaut ?[résolu] debian & apache 2 - config du userdir
Problème avec NeufTV sous debianDebian Etch et les accents dans les part NTFS
Debian Etch :: Empêcher le login quand pas de home[DEBIAN] Impossible de lire de gros fichiers avec MPlayer
Debian Etch, X et Nvidia 
Plus de sujets relatifs à : [Debian Etch/BIND9] Un coup ça marche, un coup ça marche pas...


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite) / Groupe LDLC / Shop HFR