OVH Cloud OVH Cloud

Delais de DNS

5 réponses
Avatar
Remi Moyen
Salut,

J'ai régulièrement des problèmes avec le DNS depuis chez moi, et j'arrive
pas trop à comprendre d'où ça vient.

Le contexte : une machine (Debian/testing) se connecte à l'ADSL, et sert
de passerelle pour les autres (Debian/testing aussi).

Le problème : quelque soit le protocole utilisé, le premier appel à une
résolution de noms (genre un ping machine.domaine.fr, ou wget, ou ssh,
...) est très long, de l'ordre de la minute (ça fait souvent qu'il échoue,
d'ailleurs, pour mon navigateur par exemple ça dépasse le timeout). Le
deuxième appel, et les suivants, sont par contre instantanés.

Sur les machines "arrière", le resolv.conf pointe sur 10.0.0.1, cad la
passerelle. Sur la passerelle le resolv.conf pointe vers deux serveurs
DNS externes (avec deux lignes "nameserver"). La passerelle fait aussi
tourner bind.

Je suppose que ce qui se passe, c'est que la première requète est traitée
par le serveur DNS de ma passerelle, qui ne connait pas (encore) le nom,
et qui va donc chercher ailleurs. Après, la résolution de nom est stockée
en local, et les autres accès sont donc immédiats.

Mais pourquoi est-ce si long la première fois ? Les serveurs DNS pointés
dans mon resolv.conf ont habituellement des temps de réponse très court,
certainement pas de l'ordre d'une minute.

Hier soir, toutefois, j'ai remarqué un truc bizarre : aucun des deux
serveurs DNS ne répondait à un ping. Je suppose que ça veut dire que leur
firewall bloque les ICMPs, parce que si les deux machines étaient mortes,
je vois mal comment j'aurais pu résoudre quoi que ce soit comme nom !

Ou alors, ça vient de la config de bind ? Je connais pas du tout cette
config, mais dans mon /etc/bind/named.conf, je vois :

options {
[...]
forwarders {

avec 3 IPs, correspondant à des serveurs DNS. Mais aucun des 3 ne répond à
un ping non plus !! (et pour l'un des 3, je sais qu'en réalité il est
maintenant inaccessible : c'était celui de mon bureau, qui est maintenant
derrière un firewall)

Est-ce que tout ça peut expliquer que les résolutions de nom soient si
longues ? Et comment ?
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."

5 réponses

Avatar
news.davenulle.org
In article ,
says...

Sur les machines "arrière", le resolv.conf pointe sur 10.0.0.1, cad la
passerelle. Sur la passerelle le resolv.conf pointe vers deux serveurs
DNS externes (avec deux lignes "nameserver"). La passerelle fait aussi
tourner bind.


Le resolv.conf devrait plutôt pointer sur bind (nameserver 127.0.0.1),
qui lui fait du forward vers les serveurs externes.

Je ne sais pas si c'est la cause de tes soucis.

Avatar
Patrick Lamaizière
In article ,
says...

Sur les machines "arrière", le resolv.conf pointe sur 10.0.0.1, cad la
passerelle. Sur la passerelle le resolv.conf pointe vers deux serveurs
DNS externes (avec deux lignes "nameserver"). La passerelle fait aussi
tourner bind.


Le resolv.conf devrait plutôt pointer sur bind (nameserver 127.0.0.1)
qui lui fait du forward vers les DNS externes. Je ne sais pas si c'est
la cause de tes soucis.

Avatar
Remi Moyen
On Mon, 11 Apr 2005, Patrick Lamaizière wrote:

Sur les machines "arrière", le resolv.conf pointe sur 10.0.0.1, cad la
passerelle. Sur la passerelle le resolv.conf pointe vers deux serveurs
DNS externes (avec deux lignes "nameserver"). La passerelle fait aussi
tourner bind.


Le resolv.conf devrait plutôt pointer sur bind (nameserver 127.0.0.1)
qui lui fait du forward vers les DNS externes. Je ne sais pas si c'est
la cause de tes soucis.


Hum, oui, en fait j'avais mal lu le resolv.conf : il pointe bien d'abord
vers 127.0.0.1, puis vers deux autres serveurs DNS externes.

Peut-être est-ce là la raison du problème : la première requète part vers
bind, qui ne trouve pas (parce que mes serveurs DNS indiqués dans
named.conf ne sont pas joignables ?), et au bout d'un timeout, la deuxième
part vers les autres DNS indiqués dans resolv.conf ?
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."


Avatar
Pascal
Salut,


Peut-être est-ce là la raison du problème : la première requète part
vers bind, qui ne trouve pas (parce que mes serveurs DNS indiqués dans
named.conf ne sont pas joignables ?), et au bout d'un timeout, la
deuxième part vers les autres DNS indiqués dans resolv.conf ?


M'étonnerait beaucoup que BIND utilise le contenu de resolv.conf.
Quand les résolutions DNS sont longues, ça veut généralement dire que le
ou les premiers serveurs dans la liste des forwarders sont morts ou à la
ramasse. Requête du premier DNS, time-out, requête du DNS suivant...

D'autre part, ping n'est pas très fiable pour vérifier la santé d'un
serveur DNS. Un serveur peut filtrer les echo-requests, ou au contraire
répondre au ping alors que son service DNS est HS. Le mieux est de tester
directement avec des requêtes DNS faites par host, dig ou nslookup en
spécifiant l'adresse du serveur, par exemple :

$ host <requete> <serveur>

--
Pascal
Vous pouvez me tutoyer.
Piège à spam (pour test) :
Annonce désespérée : cherche doc onduleur Merlin Gerin Pulsar S4. Merci.

Avatar
Remi Moyen
On Mon, 11 Apr 2005, wrote:

Peut-être est-ce là la raison du problème : la première requète part vers
bind, qui ne trouve pas (parce que mes serveurs DNS indiqués dans
named.conf ne sont pas joignables ?), et au bout d'un timeout, la deuxième
part vers les autres DNS indiqués dans resolv.conf ?


M'étonnerait beaucoup que BIND utilise le contenu de resolv.conf.
Quand les résolutions DNS sont longues, ça veut généralement dire que le ou
les premiers serveurs dans la liste des forwarders sont morts ou à la
ramasse. Requête du premier DNS, time-out, requête du DNS suivant...


En effet. En supprimant le premier DNS (qui est mort) de named.conf, ça a
l'air de marcher correctement.

D'autre part, ping n'est pas très fiable pour vérifier la santé d'un serveur
DNS. Un serveur peut filtrer les echo-requests, ou au contraire répondre au
ping alors que son service DNS est HS.


Je sais bien (et je le signale dans mon post initial), mais je ne me
rappelle jamais quelle autre commande il faut utiliser :-)

Le mieux est de tester directement
avec des requêtes DNS faites par host, dig ou nslookup en spécifiant
l'adresse du serveur, par exemple :


Ah ben voila, avec host tout va mieux ! Les tests sont nettement plus
faciles et précis.

Bon, ben le problème semble résolu. Je vérifierais ce soir quand
j'utiliserais vraiment mes machines (là, je contrôle juste rapidement
deux-trois trucs par ssh), mais ça a l'air bon.

Merci pour les deux réponses !
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."