4 votes

Comment les enregistrements NS sont-ils résolus?

Note : Je suis conscient des enregistrements de glue et que les serveurs DNS les utilisent seulement dans le cas où le domaine du serveur ns est le même que le domaine pour lequel vous avez envoyé la requête.

Maintenant, ma question était : Imaginons que vous avez example.com qui a ns1.example.org (un domaine différent de example.com) comme enregistrement NS. À un moment donné, le résolveur devra également résoudre et trouver l'adresse IP de ns1.example.org. Ma question est, COMMENT fait-il cela (sans enregistrement de glue) ?

Je suppose qu'il recommence le processus, en allant d'abord au DNS racine, puis au DNS .org, puis il atteint les serveurs de noms pour example.org... mais attendez, est-ce que les serveurs de noms ont des serveurs de noms? Si oui, cela finirait par créer une grande boucle sans fin, car maintenant vous devrez trouver les enregistrements NS pour example.org et y aller, etc.

Mon point est que ces adresses IP des serveurs de nom DOIVENT être stockées quelque part. J'ai entendu certaines personnes dire que les enregistrements de glue ne sont utilisés que si, par exemple, vous avez example.com et que ses serveurs NS sont ns1.example.com, même domaine. S'il s'agit d'un domaine différent, alors j'ai lu qu'il y a une résolution de ce domaine pour trouver l'IP... mais cela implique que des serveurs de noms comme ns1.example.org ont leurs propres serveurs de noms, ce qui n'a vraiment aucun sens.

3voto

Shane Madden Points 112034

La délégation à un serveur de noms dans un domaine différent ne change vraiment pas grand-chose - cela ne fait que compliquer la tâche du résolveur.

Dans l'exemple que vous avez fourni, le domaine example.org doit fonctionner pour que le nom example.com puisse être résolu avec succès - pourquoi n'aurait-il pas ses propres serveurs de noms fonctionnels, ou enregistrements de liaison?

Le scénario d'échec de boucle infinie que vous semblez imaginer ne se produirait que si vous créiez une boucle de délégation impossible, par exemple si vous essayiez de déléguer ns1.example.org à un serveur de noms sous example.com.

0 votes

Eh bien, continuons avec la chaîne. Disons que example.org a 'ns1.example.info' comme serveur de noms. Maintenant, disons que example.info a 'example.cc' comme serveur de noms...et supposons que cela continue avec 10 domaines de plus jusqu'à ce que nous arrivions enfin à un domaine comme example.tv qui a un enregistrement de liaison (glue record). Ainsi, afin d'obtenir example.com, le serveur a-t-il dû effectuer plus de 10 recherches ?

1 votes

@daremkd Oui, en supposant qu'il n'y avait rien en cache à propos de ces domaines. Vous pouvez créer une chaîne de délégation arbitrairement longue, bien qu'en pratique, elle soit limitée par le temps qu'un client en résolution passera à suivre la chaîne de délégation pour une seule requête, généralement quelques secondes.

0 votes

C'est intéressant. En considérant qu'un plus petit site web, disons que vous possédez smallSite.com, est sur un hébergeur partagé, disons sur "ns1.hostgator.com" qui pointe vers ns1.p13.dynect.net, qui pointe vers ns0.dynamicnetworkservices.net, qui a ENFIN un enregistrement de lien, cela fait passer la résolution par 3 résolutions de noms de serveurs différents. Et en considérant que c'est un petit site, je suppose que la plupart des serveurs DNS n'ont pas beaucoup mis en cache à son sujet. Donc en créant un enregistrement de lien DNS pour ce petit site, la résolution ne serait-elle pas beaucoup plus rapide? Vous évitez de voyager 3 fois.

1voto

galileoMonkey Points 665
  • Le résolveur veut l'IP de www.example.com (requête "A www.example.com.")
  • Il n'est pas mis en cache, il doit donc demander à un serveur DNS qui est autoritaire pour example.com
  • N'ayant pas d'idée meilleure, il demande à l'un des serveurs root préconfigurés
  • Au lieu d'une réponse finale, nous sommes informés des serveurs autoritaires pour com., tels que a.gtld-servers.net; même si ceux-ci ne sont pas sous com, les serveurs root ajoutent des enregistrements de colle; donc nous connaissons l'IP de a.gtld-servers.net
  • Nous posons donc notre question "A www.example.com" à a.gtld-servers.net
  • Encore une fois, a.gtld-servers ne connaît pas la réponse, mais nous dit que ns.example.org est responsable; typiquement, il y aurait des enregistrements de colle à ce stade, mais supposons que ce n'est pas le cas
  • Nous commençons une sous-requête "A ns.example.org"
  • Comme ci-dessus, les serveurs root nous dirigent vers des serveurs DNS pour org., tels que a0.org.afilieas-nst.info; dans un monde mauvais, nous aurions dû recommencer le jeu pour localiser ce type, mais à ce niveau, nous obtenons des enregistrements de colle
  • Nous pouvons donc demander à a0.org.afilieas-nst.info pour ns.example.org
  • Nous apprenons que nous devrions demander à a.iana-servers.net à propos de example.org, mais malheureusement sans colle
  • Nous demandons donc aux serveurs root (parce que nous avons entre-temps appris sur com. et org., mais pas encore sur net.)
  • La réponse nous dit que par exemple a.gtld-servers-net est responsable de net. et nous obtenons également de la colle, mais nous connaissions déjà l'IP de a.gtld-servers.net
  • Nous demandons à a.gtld-servers.net "A a.inana-servers.net" et apprenons les enregistrements NS pour iana-servers.net; trois d'entre eux sont dans iana-servers.net (et viennent avec de la colle) et un quatrième serveur est ns.icann.org
  • Pour une raison stupide, nous ignorons les enregistrements de colle (ou peut-être que ces serveurs de noms sont inatteignables) et avons donc besoin de résoudre ns.icann.org; eh bien, nous savons déjà que nous devrions interroger a0.org.afilieas-nst.info pour "A ns.icann.org"
  • De manière intrigante, les serveurs de noms retournés sont les mêmes qu'auparavant: trois de icann-servers.net et ns.icann.org lui-même; cette fois ns.icann.org vient avec de la colle
  • Donc maintenant nous connaissons l'IP de ns.icann.org et pouvons lui demander "A a.iana-servers.net" et obtenir son adresse
  • Maintenant nous pouvons enfin demander à a.iana-servers.net "A ns.example.org" et obtenir une IP (en réalité, bien sûr)
  • Nous pouvons demander à ns.example.org sous cette IP pour "A www.example.com" et enfin résoudre notre problème initial

Au cours de cela, nous avons appris beaucoup sur plusieurs zones importantes, comme com, net et org. En mettant en cache ces informations, nos prochaines requêtes prendront beaucoup moins de détours ...

1 votes

Dites-vous que lorsque vous faites "A ns.someDomain.com", qui est enregistré en tant que serveur de noms, le domaine de racine .com vous donne toujours les enregistrements de liant ?

0voto

niglesias Points 210

Vous avez raison sur le fait que les adresses IP des serveurs de noms sont stockées quelque part - vous ne pouvez pas résoudre de FQDN sans un DNS. C'est pourquoi vous avez les adresses IP dans la configuration de votre réseau, et non leurs noms.

Les serveurs DNS racine sont référencés par leurs adresses IP configurées dans chaque serveur DNS. Ainsi, lorsqu'un serveur DNS reçoit une requête pour un nom de domaine qu'il ne connaît pas, il

  1. interroge son DNS configuré
  2. interroge le DNS racine, qui ne répondra pas avec l'IP respective mais indiquera quel(s) serveur(s) de noms gère(nt) le domaine racine (disons, .com) et ensuite ce serveur de noms pourrait indiquer quel serveur de noms gère le domaine particulier (disons, nasa.com)

Vous pouvez faire quelques explorations en effectuant une requête de suivi avec :

dig +trace www.google.com

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