8 votes

Rechercher et Domaine dans resolv.conf = recherches lentes sur Ubuntu

J'ai une machine exécutant ubuntu 10.04 serveur. J'ai commencé à rencontrer des retards longs (5 à 10 secondes) lors de la connexion à (certains) sites en dehors du LAN en utilisant des outils comme curl et wget.

En utilisant tcpdump et wireshark, j'ai trouvé que le problème se situait dans les recherches DNS effectuées pour établir la connexion :

EXEMPLE

Quand j'exécute :

wget www.site1.com

Je vois le comportement suivant :

RECHERCHE: AAAA www.site1.com       
        # => échec, pas de retard, site1 n'a pas d'enregistrement AAAA IPv6
RECHERCHE: AAAA www.site1.com.mydomain.lan
        # => échec, GROS RETARD, domaine fou n'existe pas
RECHERCHE: A www.site1.com
        # => succès, pas de retard, se résout comme prévu (site1 a un enregistrement A IPv4)
CONNEXION PROGRESSE ...

MA CONFIGURATION

Le resolv.conf de mon serveur ressemble à ceci :

nameserver 192.168.0.1  # mon routeur
domain mydomain.lan    # nom de domaine inventé, pour mon lan
search mydomain.lan

Le fichier hôtes de mon serveur ressemble à ceci :

127.0.0.1       localhost.localdomain   localhost
192.168.0.10    server1.mydomain.lan   serveur1
# Les lignes suivantes sont souhaitables pour les hôtes compatibles IPv6
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

RÉSOLUTIONS ?

Pourquoi ma liste de recherche resolv.conf est-elle utilisée pour construire le nom de la 2ème recherche, alors que la page man de resolv.conf suggère qu'elle est seulement utilisée lors de recherches de noms d'hôtes (sans points) :

"Les requêtes Resolver ayant moins de ndots points (par défaut 1) seront tentées en utilisant chacun des composants du chemin de recherche tour à tour jusqu'à ce qu'une correspondance soit trouvée."

J'ai l'impression que la 2ème recherche est erronée et ne devrait pas être effectuée du tout...

Si je supprime les lignes domain et search du resolv.conf, la 2ème recherche n'est plus effectuée et mes retards disparaissent.

(aussi, si je force wget à ne traiter qu'en IPv4, les recherches AAAA ne sont plus effectuées, donc les retards disparaissent) :

wget --inet4-only www.site1.com

4voto

Shane Madden Points 112034

Ce comportement est intentionnel.

IPv6 est privilégié - donc le statut de la ressource en termes de AAAA est déterminé en premier. Une réponse NXDOMAIN est renvoyée - donc le client estime qu'il doit ajouter le chemin de recherche search.

Notez que le commentaire sur ndots que vous avez fait est correct - mais ce n'est pas toute l'histoire. Si le nombre de ndots est supérieur au nom recherché (s'il s'agissait ici d'un nom à un seul label), la seule différence dans le comportement de la requête est que la requête avec le suffixe ajouté se produira avant que le nom brut soit tenté. Étant donné que vous dépassez le seuil de ndots, le nom est d'abord essayé, tel qu'il est fourni. Consultez plus bas dans la page de manuel :

La valeur par défaut de n est 1, ce qui signifie que s'il y a des points dans un nom, le nom sera d'abord essayé en tant que nom absolu avant que des éléments de la liste de recherche ne lui soient ajoutés.

Cette requête a échoué, donc la liste de recherche doit être utilisée. Remarquez la différence de comportement de requête avec wget http://site1/.


Ce que vous voyez est un comportement intentionnel - ce que je pense que vous devez corriger est la confluence de facteurs qui cause cette recherche lente.

  • Corrigez votre serveur DNS, ou corrigez le serveur sur lequel il fait une récursivité. Un serveur récursif devrait facilement mettre en cache le NXDOMAIN qu'il reçoit des racines lorsqu'il tente de rechercher un TLD inexistant. Puisque désactiver IPv6 résout le problème, vous devez avoir un serveur DNS sur le chemin qui échoue lamentablement à mettre en cache lorsque des recherches AAAA sont impliquées. Essayez de changer votre résolveur en 8.8.8.8 pour vérifier.
  • Cessez d'ajouter un chemin de recherche pour une zone DNS pour laquelle vous ne pouvez visiblement pas effectuer de recherches. Si votre serveur DNS était l'autorité pour cette zone (ce qui serait nécessaire pour que ce paramètre search soit utile, étant donné qu'il ne s'agit pas d'un nom valide dans la hiérarchie publique), il répondrait immédiatement. Vous n'avez probablement pas besoin de cette configuration de search - mais définissez-la sur quelque chose qui résoudra, pour éviter de le deviner à partir du nom de machine. search com devrait faire l'affaire.

0voto

Si vous saisissez hostname à un shell prompt et que vous obtenez foo.bar.baz, alors le résolveur DNS comprend que votre nom d'hôte est foo et que votre nom de domaine est bar.baz. Généralement, les lignes "domain" et "search" dans /etc/resolv.conf ne sont utiles que si cela n'est pas vrai (ou si vous avez l'intention de provoquer un comportement inhabituel).

Si votre nom de domaine est vraiment bar.baz, alors il est très probable que vous ne devriez pas spécifier les lignes "domain" ou "search" dans /etc/resolv.conf. Contrairement à ce qui se passe souvent ailleurs, dans /etc/resolv.conf, être "précis" en répétant des informations déjà disponibles à partir de hostname produira généralement des comportements bizarres et indésirables (y compris des délais d'attente ridiculement longs). Cela est vrai aussi bien dans de grandes entreprises que dans de petits environnements domestiques.

(Attention : Chaque programme d'application peut interpréter /etc/resolv.conf un peu différemment, donc en théorie cela pourrait ne pas être universellement vrai. Sur la plupart des systèmes modernes cependant, 99% des demandes du résolveur passent par GLIBC, donc en pratique ce qui précède est presque toujours vrai.)

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X