4 votes

Comment les enregistrements NS sont-ils résolus ?

Note : Je sais qu'il existe des enregistrements glue et que les serveurs DNS ne les utilisent que si le domaine du serveur ns est le même que le domaine pour lequel vous avez envoyé la requête.

Ma question était la suivante : Disons que vous avez exemple.com qui a ns1.example.org (un domaine différent de celui 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 la suivante : COMMENT fait-il cela (sans disque de colle) ?

Je pense qu'il recommence le processus, en allant d'abord au DNS racine, puis à l'adresse .org DNS, puis il atteint les serveurs de noms de example.org ...mais attendez, les serveurs de noms ont-ils des serveurs de noms ? Si c'est le cas, on se retrouve alors dans une grande boucle sans fin, car il faut maintenant trouver les enregistrements NS de example.org et s'y rendre, etc.

Ce que je veux dire, c'est que ces adresses IP pour les serveurs de noms DOIVENT être stockées quelque part. J'ai entendu des gens dire que les enregistrements glue ne sont utilisés que si, par exemple, vous avez example.com et ses serveurs NS sont ns1.example.com , même domaine. S'il s'agit d'un domaine différent, j'ai lu qu'il fallait résoudre ce domaine pour trouver l'adresse IP... mais cela implique que des serveurs de noms tels que ns1.example.org ont leurs propres serveurs de noms, ce qui n'a aucun sens.

3voto

Shane Madden Points 112034

La délégation à un serveur de noms dans un domaine différent ne change pas grand-chose - il s'agit simplement de faire faire plus de travail au résolveur.

Dans l'exemple que vous donnez, le example.org doit être fonctionnel pour le example.com pour résoudre avec succès un nom - pourquoi n'aurait-il pas ses propres serveurs de noms fonctionnels, ou enregistrements glue ?

Le scénario d'échec de la boucle infinie que vous semblez imaginer n'interviendrait que si vous créiez une boucle de délégation impossible, comme si vous tentiez de déléguer ns1.example.org vers un serveur de noms sous example.com .

1voto

galileoMonkey Points 665
  • Le résolveur souhaite obtenir l'adresse 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 fait autorité pour example.com
  • n'ayant pas de meilleure idée, il demande à l'un des serveurs racine 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 s'ils ne sont pas sous com, les serveurs racine ajoutent des enregistrements de colle ; nous connaissons donc l'adresse IP de a.gtld-servers.net.
  • Nous posons donc notre question "A www.example.com" à a.gtld-servers.net
  • Là encore, a.gtld-servers ne connaît pas la réponse, mais nous indique que ns.example.org est responsable. serait être des registres de colle à ce stade, mais supposons que ce n'est pas le cas
  • Nous lançons une sous-requête "A ns.example.org"
  • Comme ci-dessus, les serveurs racine nous conduisent aux serveurs DNS pour les org. tels que a0.org.afilieas-nst.info ; dans un mauvais monde, nous devrions recommencer le jeu depuis le début pour localiser ce type, mais à ce niveau, nous pouvons faire obtenir des relevés de colle
  • Nous pouvons donc demander à a0.org.afilieas-nst.info de s'occuper de 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 racine (car nous avons appris entre-temps ce qu'est un com. et un org. mais pas encore ce qu'est un net.)
  • La réponse nous indique que, par exemple, a.gtld-servers-net est responsable de net. et nous obtenons également glue, 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 glue (ou peut-être que ces serveurs de noms sont inaccessibles) et devons donc résoudre ns.icann.org ; nous savons déjà que nous devons interroger a0.org.afilieas-nst.info pour "A ns.icann.org"
  • Curieusement, les serveurs de noms renvoyés sont les mêmes que précédemment : trois de icann-servers.net et ns.icann.org lui-même ; cette fois-ci, ns.icann.org est accompagné d'une colle
  • Nous connaissons maintenant l'adresse IP de ns.icann.org et nous pouvons lui demander "A a.iana-servers.net" et obtenir son adresse.
  • Nous pouvons donc enfin demander à a.iana-servers.net "A ns.example.org" et obtenir une adresse IP (enfin, pas dans la réalité, bien sûr).
  • Nous pouvons demander à ns.example.org sous cette ip pour "A www.example.com" et finalement résoudre notre problème original.

Au cours de cette formation, nous avons appris beaucoup de choses sur plusieurs zones importantes, telles que com, net et org. En mettant en cache ces informations, nos prochaines requêtes feront beaucoup moins de détours ...

0voto

niglesias Points 210

Vous avez raison de dire que les adresses IP des serveurs de noms sont stockées quelque part - vous ne pouvez pas résoudre un FQDN sans DNS. C'est pourquoi vous avez les adresses IP dans votre configuration 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 à l'adresse IP correspondante, mais au(x) serveur(s) de noms qui gère(nt) le nom de domaine racine (par exemple, .com), puis ce serveur de noms pourrait répondre au serveur de noms qui gère le domaine en question (par exemple, nasa.com).

Vous pouvez faire quelques explorations en faisant une demande de traçage 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