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

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

Que nous recherchons domain.com . Nous obtenons les 3 adresses du serveur de noms.
1. Lequel de ces serveurs sera demandé plus loin et pourquoi?
2. L'ordre des enregistrements NS dans le fichier de zone est-il important?
3. Est-il déterminé dans un RFC ?

Malheureusement, la réponse ici est "cela dépend". Les facteurs dont il dépend varient en fonction du domaine et de la configuration des serveurs propriétaires, ainsi que de la configuration de votre propre DNS local.

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

Ensuite, certaines implémentations DNS interrogeront chaque NS en parallèle et utiliseront la première réponse. D'autres vont frapper chacun, déterminer le plus rapide sur un certain nombre de demandes et utiliser celui-ci. Ou il pourrait simplement faire un tournoi à la ronde.

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

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

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

Je me rends compte que c'est quelque chose d'une non-réponse, sans rien de définitif à retirer, mais étant donné ce qui précède, la seule vraie façon dont vous avez à déterminer le comportement pour un domaine donné est de tester.

L'implémentation la plus courante que j'ai vue au niveau du client, comme 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 FAI 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 sollicitent pas inutilement les serveurs DNS du site en question. )
3. S'ils n'avaient pas cet enregistrement mis en cache, ou si le cache est considéré comme «périmé / 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 sur le dernier enregistrement.
5. Le FAI commence par vérifier sa liste mise en cache des serveurs de noms faisant autorité pour le domaine (ce sont les ns1.example.com, ns2.example.com et ainsi de suite avec leurs adresses IP). Si ces enregistrements sont toujours considérés comme frais, il passe à l'étape 8.
6. Si les enregistrements du serveur de noms mis en cache étaient considérés comme arrivés à expiration ou s’il n’avait aucun enregistrement mis en cache pour ce domaine, le FAI interroge les serveurs de noms racine du TLD (tels que le registre .com s’il s’agit d’un domaine .com) pour obtenir le les paires nom / IP de serveur de noms les plus à jour pour example.com. ( Vous pouvez essayer 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 com / net / etc habituels. Autre Les TLD devraient interroger leurs serveurs racine respectifs. )
7. Les serveurs de noms racine pour le TLD retournent toujours les serveurs de noms dans l' ordre exact qu'ils ont été spécifiés par vous; aucune randomisation ne se produit. Ils renvoient également les adresses IP de chaque serveur de noms; ceci est connu sous le nom de "GLUE" et c'est ce qui permet à Internet de résoudre le problème "poulet et œuf" de la façon de résoudre un nom d'hôte de serveur de noms en IP avant de savoir quoi que ce soit sur un domaine. De plus, la plupart d'entre eux (comme les registres com / net / etc qui sont les plus grands) utilisent un temps de cache de 2 jours afin qu'ils ne soient pas constamment martelés avec "quelle est la liste des serveurs de noms pour le domaine X?" demandes. C'est la source de la connaissance commune que vous DEVEZ attendre 2 jours jusqu'à ce que vous puissiez dire en toute sécurité que vos nouveaux serveurs de noms sont connus dans le monde entier, après vous '
8. Lorsque le FAI connaît les serveurs de noms example.com et leurs adresses IP, telles que ns1.example.com, ns2.example.com, ns3.example.com, le FAI sélectionne désormais un serveur aléatoire dans 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 aident davantage à l'équilibrage de charge en n'interrogeant pas toujours le premier serveur de noms répertorié. )
9. Si le FAI n'obtient pas de réponse de ce serveur de noms dans un délai spécifié, il en interroge un autre sur la liste.
10. Lorsqu'il a une réponse, le FAI 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é à un délai d'expiration (en secondes), qui correspond à la durée pendant laquelle le client interrogateur (tel que le serveur DNS du FAI) est autorisé à mettre cet enregistrement en cache 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 un délai d'expiration fixe qui est spécifié dans l'enregistrement "SOA" (début de l'autorité) de chaque serveur de noms individuel (vous pouvez voir le vôtre via "dig @ ns1.example.com example.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 en panne et il est impossible de rechercher à nouveau les enregistrements. Habituellement, l'expiration douce est de 30 minutes à 5 heures et l'expiration dure est généralement comprise entre 1 à 3 semaines.
11. Après ce travail exhaustif, le FAI dispose enfin du dernier enregistrement DNS et peut le renvoyer à l'abonné haut débit interrogateur, qui n'est pas le plus sage quant à l'énorme travail qui a eu lieu dans les coulisses!

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 mises en cache après cela et les requêtes ultérieures vers le serveur DNS de mise en cache du FAI pourront rapidement passer à l'étape 8.

Maintenant, comme pour la randomisation de l'étape 8, cela fonctionne au niveau de l'enregistrement. Disons que l'abonné haut débit de ce FAI a posé des questions sur les enregistrements suivants:

• Un foo.example.com
• Un exemple.com
• Un www.example.com
• MX example.com (un client 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 indépendamment. Supposons donc que l'abonné et le FAI n'aient jamais rencontré le domaine auparavant et que les deux aient zéro enregistrement en cache. Les recherches peuvent être les suivantes:

• Un 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 du FAI
• MX example.com via ns3.example.com, puis stocké dans le cache du FAI

Chaque fois que les enregistrements mis en cache sont expirés en douceur, le processus est répété, vous ne savez même pas que les demandes suivantes pour cet enregistrement utiliseront à nouveau le même serveur.

C'est donc votre plus grand objectif absolu de vous assurer que tous vos serveurs DNS sont complètement synchronisés les uns avec les autres, reflétant parfaitement chaque enregistrement DNS sur chaque serveur. Vous ne savez jamais quel serveur un client DNS va frapper et vous ne pouvez vous fier à aucune commande. Il n'y a pas une telle chose.

De plus, comme mentionné par Adam C, les serveurs DNS au niveau du serveur (example.com) eux-mêmes pourraient renvoyer des enregistrements NS et randomiser l'ordre de ceux-ci. Il est très fréquent que les serveurs DNS normaux randomisent leurs enregistrements NS au cas où une mauvaise implémentation DNS choisit toujours le premier serveur de noms renvoyé. Cependant, les serveurs de noms ROOT TLD (mentionnés précédemment) ne randomiseront jamais la liste, et leur liste est ce qui compte vraiment lorsqu'il s'agit de résoudre le domaine. C'est pourquoi la plupart des implémentations choisissent un serveur aléatoire dans les listes de serveurs de noms, pour éviter de toujours toucher le même serveur et de le surcharger.

D'accord, c'est votre introduction au fonctionnement du DNS et à ce que vous devez retenir.

• En bref: traitez tous vos serveurs DNS comme s'ils n'étaient qu'un seul serveur, ce qui en fait votre objectif le plus élevé dans la vie de vous assurer qu'ils sont tous également capables de répondre à toute requête qui pourrait leur être adressée.

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. ;-)