Question Comment l'ordre de recherche DNS est-il déterminé?


Par exemple: nous avons un nom de domaine enregistré domain.com et ajouté enregistrements de serveur de noms sur le serveur de bureaux d'enregistrement:
ns1.domain.com.
ns2.domain.com.
ns3.domain.com.

Que nous cherchons domain.com. Nous avons tous les 3 noms de serveur d'adresse.
1. Lequel de ces serveurs sera demandé plus tard et pourquoi?
2. L'ordre des enregistrements NS dans le fichier de zone est-il important?
3. Est-ce déterminé dans RFC?


18
2018-01-31 14:02


origine




Réponses:


Malheureusement, la réponse est "ça dépend". Les facteurs dont il dépend varieront en fonction du domaine, de la configuration des serveurs propriétaires et de la configuration de votre propre DNS local.

Tout d’abord, par exemple, en ce qui concerne les enregistrements NS renvoyés: il est parfaitement autorisé de randomiser l’ordre dans lequel ces enregistrements sont renvoyés; l’ordre peut donc différer chaque fois que vous le demandez. D'un autre côté, cela ne se fait pas avec toutes les implémentations DNS, vous pourriez donc obtenir une liste ordonnée de manière statique. Le fait est que vous ne pouvez pas être sûr.

Ensuite, certaines implémentations DNS interrogeront chaque système de réseau en parallèle et utiliseront celui qui répond en premier. D'autres vont frapper chacun, déterminer le plus rapide sur un certain nombre de demandes et utiliser celui-ci. Ou il pourrait simplement tourner à la ronde.

Il existe plusieurs RFC pour le DNS, deux des plus utiles que j'ai trouvés sont:

http://www.faqs.org/rfcs/rfc1912.html

http://www.faqs.org/rfcs/rfc1033.html

Je réalise que c'est en quelque sorte une non-réponse, sans rien de définitif à retenir, mais compte tenu de ce qui précède, la seule vraie façon de déterminer le comportement d'un domaine donné est de tester.


18
2018-01-31 14:14



J'ai approuvé votre réponse. J'allais dire la même chose mais tu m'as battu. - Tonny
De plus, les clients qui utilisent getaddrinfo se retrouvent avec des résultats triés alors que les appels à gethostbyname étaient apparemment aléatoires. Les clients qui ne s’attendent pas à ce que leur comportement brise le round robin dns à certains égards. - Matt


L'implémentation la plus courante que j'ai vue au niveau client, telle que les FAI du monde entier, est la suivante:

  1. Quelqu'un (comme un abonné à large bande) demande aux serveurs DNS du FAI de résoudre l'enregistrement A pour foo.example.com.
  2. Le fournisseur de services Internet vérifie son propre cache et si cet enregistrement est mis en cache et toujours considéré comme "frais", il est immédiatement renvoyé via le cache. (C’est ainsi que fonctionnent tous les caches DNS afin qu’ils ne surchargent pas inutilement les serveurs DNS du site en question.)
  3. Si cet enregistrement n'a pas été mis en cache ou si le cache est considéré comme "obsolète / obsolète", le FAI sait qu'il doit à nouveau résoudre le dernier enregistrement.
  4. Le FAI doit maintenant savoir quels serveurs de noms interroger à propos du dernier enregistrement.
  5. Le fournisseur de services Internet commence par vérifier la liste des serveurs de noms qui font autorité pour le domaine (les fichiers ns1.example.com, ns2.example.com, etc., ainsi que leurs adresses IP). Si ces enregistrements sont toujours considérés comme frais, passez à l'étape 8.
  6. Si les enregistrements de serveur de noms mis en cache ont été considérés comme arrivés à expiration, ou s’il ne contient aucun enregistrement mis en cache pour ce domaine, le fournisseur de services Internet interroge les serveurs de noms racine du TLD (tels que le registre .com s'il s'agit d'un domaine .com) pour obtenir le fichier. paires de nom de serveur de noms / IP les plus récentes pour example.com. (Vous pouvez essayer cela vous-même via "dig @ b.gtld-servers.net example.com" pour voir ce que les serveurs de noms racine de votre TLD connaissent de votre domaine - si votre domaine appartient aux TLD habituels com / net / etc. Les autres TLD devraient interroger leurs serveurs racine respectifs.)
  7. Les serveurs de noms racine pour le TLD toujours renvoyer les serveurs de noms dans le ordre exact ils ont été spécifiés par vous; aucune randomisation ne se passe. Ils renvoient également les adresses IP pour chaque serveur de noms; C'est ce qu'on appelle "GLUE" et c'est ce qui permet à Internet de résoudre le problème "poule et œuf" de la résolution d'un nom d'hôte de serveur de noms en IP avant de tout savoir sur un domaine. De plus, la plupart d’entre eux (comme les registres com / net / etc qui sont les plus gros) utilisent un temps de cache de 2 jours afin de ne pas être martelés constamment par "quelle est la liste des serveurs de noms pour le domaine X?" demandes. C’est la source de la connaissance commune selon laquelle vous DEVEZ attendre 2 jours avant de pouvoir dire en toute sécurité que vos nouveaux serveurs de noms sont connus dans le monde entier, une fois que vous avez modifié votre liste de serveurs de noms.
  8. Lorsque le fournisseur de services Internet connaît les serveurs de noms d’exemple.com et leurs adresses IP, tels que ns1.example.com, ns2.example.com, ns3.example.com, il sélectionne maintenant un au hasard serveur de cette liste et envoie la requête. (C’est gentil de leur part, ils ne martèlent pas inutilement tous les serveurs DNS du site en question, et ils facilitent davantage l’équilibrage de la charge en n’interrogeant pas toujours le premier serveur de noms répertorié.)
  9. Si le fournisseur de services Internet ne reçoit pas de réponse de ce serveur de noms dans un délai donné, il en interroge un autre de la liste.
  10. Lorsqu'il a une réponse, le fournisseur de services Internet la stocke maintenant dans son propre cache local. Quant à combien de temps il restera en cache; chaque enregistrement renvoyé par un serveur DNS est également associé à une heure "expiration logicielle" (en secondes), qui correspond au temps pendant lequel le client interrogateur (tel que le serveur DNS du fournisseur de services Internet) est autorisé à mettre en cache cet enregistrement avant qu'il ne soit pris en compte " toujours utilisable mais peut-être obsolète, une nouvelle requête devrait maintenant avoir lieu SI POSSIBLE juste pour être sûr qu'elle n'a pas changé. " Il existe également une "heure d'expiration" spécifiée dans l'enregistrement "SOA" (début de l'autorité) de chaque serveur de noms (vous pouvez le voir via "dig @ ns1.exemple.com exemple.com -t soa"), qui spécifie une "limite stricte" globale pour tous les enregistrements renvoyés par ce serveur, après quoi tout cache DEVRAIT SUPPRIMER son enregistrement mis en cache même si les serveurs de noms sont hors service et qu'il est impossible de rechercher à nouveau les enregistrements. Habituellement, l'expiration douce dure de 30 minutes à 5 heures et la dure est de 1 à 3 semaines.
  11. Après ce travail exhaustif, le FAI dispose enfin du dernier enregistrement DNS et peut le restituer à l’abonné à large bande interrogateur, qui n’est pas au courant du travail colossal accompli en coulisse!

Ce processus est répété pour CHAQUE recherche d'enregistrement. Cependant, seule la première requête fait tout le travail; les adresses IP du serveur de noms seront ensuite mises en cache et les requêtes ultérieures adressées au serveur DNS de mise en cache du fournisseur de services Internet pourront rapidement passer à l'étape 8.

Maintenant, en ce qui concerne la randomisation de l'étape 8, cela fonctionne au niveau de l'enregistrement. Supposons que l'abonné à large bande de ce fournisseur de services Internet pose des questions sur les enregistrements suivants:

  • Un foo.example.com
  • Un exemple.com
  • Www.example.com
  • MX example.com (un client d'un FAI ne devrait pas demander cet enregistrement, mais ce n'est qu'un exemple)

Chaque enregistrement sera traité comme sa propre "entité" distincte, mise en cache et recherchée. Supposons donc que l'abonné et le fournisseur de services Internet n'aient encore jamais rencontré le domaine et que les deux enregistrements mis en cache sont complètement nuls. Les recherches pourraient être les suivantes:

  • Un exemple: foo.example.com via ns1.example.com, puis stocké dans le cache du FAI
  • Un exemple.com via ns3.example.com, puis stocké dans le cache du FAI
  • Un www.example.com via ns2.example.com, puis stocké dans le cache ISP
  • MX exemple.com via ns3.example.com, puis stocké dans le cache du fournisseur de services Internet

Le processus est répété chaque fois que les enregistrements mis en cache ont expiré, de sorte que vous ne savez même pas que les demandes ultérieures pour cet enregistrement utiliseront à nouveau le même serveur.

C’est pourquoi votre objectif ultime est de vous assurer que tout de vos serveurs DNS sont parfaitement synchronisés les uns avec les autres, reflétant parfaitement chaque Enregistrement DNS sur chaque serveur. Vous jamais savoir quel serveur un client DNS va frapper et vous ne pouvez vous fier à aucun ordre. Il n'y a pas une telle chose.

En outre, comme l'a mentionné Adam C, les serveurs DNS de niveau serveur (exemple.com) peuvent eux-mêmes renvoyer des enregistrements NS et en rendre l'ordre au hasard. Il est très courant que les serveurs DNS habituels randomisent leurs enregistrements NS au moindre risque qu'une implémentation DNS médiocre choisisse toujours le premier serveur renvoyé. Cependant, les serveurs de noms ROOT TLD (mentionnés précédemment) ne randomiseront jamais la liste, et c'est leur liste qui compte vraiment pour la résolution du domaine. C'est pourquoi plus les implémentations choisissent un serveur au hasard parmi les listes de serveurs de noms, pour éviter de toujours toucher le même serveur et de le surcharger.

Très bien, c’est votre introduction au fonctionnement du DNS et à ce dont vous devez vous souvenir.

  • En bref: traitez tous vos serveurs DNS comme s’ils ne formaient qu’un seul serveur, ce qui en fait votre objectif ultime dans la vie: vous assurer qu’ils sont également capables de répondre. tout requête qui pourrait être jeté sur eux.

Avertissement: des objectifs plus élevés dans la vie que la gestion du DNS peuvent être disponibles, mais sont vendus séparément, utilisez votre imagination. ;-)


3
2018-01-30 02:26