Clarification de la raison pour laquelle les fichiers de zone DNS nécessitent des enregistrements NS


18

Cette question a été posée à l'origine ici: pourquoi les fichiers de zone DNS nécessitent-ils des enregistrements NS?

Pour résumer: "Lorsque je vais chez mon registraire et achète example.com, je dirai à mon registraire que mes serveurs de noms sont ns1.example.org et ns2.example.org".

Mais quelqu'un peut-il clarifier les points suivants:

Après l'enregistrement, le registre .com aura désormais un enregistrement qui indique qu'un résolveur doit visiter ns1.example.org ou ns2.example.org afin de trouver l'adresse IP de example.com. L'adresse IP réside dans un enregistrement A dans un fichier de zone sur ns1.example.org et a une copie identique sur ns2.example.org.

Cependant, à l'intérieur de ce fichier, il doit également y avoir 2 enregistrements NS qui répertorient ns1.example.org et ns2.example.org comme serveurs de noms. Mais puisque nous sommes déjà sur l'un de ces serveurs, cela semble être des informations en double.

La réponse initialement donnée à la question indiquait que les serveurs de noms répertoriés dans le fichier de zone étaient "faisant autorité". Si les serveurs de noms ne correspondent pas, les serveurs de noms faisant autorité auront la priorité. C'est très bien et bien, mais le résolveur est arrivé au serveur de noms en utilisant les serveurs de noms répertoriés dans le registre .com , et si le serveur de noms ne correspond pas, alors le résolveur chercherait le fichier de zone sur le mauvais serveur de noms et ne le ferait pas '' t être en mesure de le trouver.

Ou s'agit-il d'un cas où le registre .com extrait les informations du serveur de noms de l'enregistrement ns du fichier de zone? (Mais je suppose que si vous modifiez l'enregistrement ns du fichier de zone sans en informer le registre, il n'aurait aucun moyen de savoir où chercher.)

Merci

Réponses:


23

Décomposons-le un peu.

Les enregistrements NS dans la zone TLD (par exemple, example.com NS ...dans com) sont des enregistrements de délégation .

Les enregistrements A et AAAA dans la zone TLD (par exemple, ns1.example.com A ...dans com) sont des enregistrements collés .

Les enregistrements NS dans la zone elle-même (c'est-à-dire example.com NS ...dans example.com) sont des enregistrements d' autorité .

Les enregistrements A et AAAA dans la zone elle-même ( ns1.example.com A ...en example.com) sont des enregistrements d' adresse , clairs et simples.

Lorsqu'un résolveur (récursif) démarre sans cache des données de votre zone et uniquement le cache de la zone racine (qui est utilisé pour amorcer le processus de résolution de nom), il ira d'abord à ., puis com.. Les comserveurs répondront avec une réponse de la section de l' autorité qui dit essentiellement « Je ne sais pas, mais regardez ici pour quelqu'un qui ne connaît », même que les serveurs pour .faire au sujet com. Cette réponse à la requête ne fait pas autorité et ne comprend pas de section de réponse remplie. Il peut également inclure un soi-disant supplémentairesection qui donne les mappages d'adresses pour tous les noms d'hôtes que le serveur particulier connaît (soit à partir des enregistrements de collage, soit, dans le cas des résolveurs récursifs, à partir de données précédemment mises en cache). Le résolveur prendra cette réponse de délégation, résoudra le nom d'hôte d'un enregistrement NS si nécessaire et procédera à une requête sur le serveur DNS auquel l'autorité a été déléguée. Ce processus peut se répéter un certain nombre de fois si vous avez une hiérarchie de délégation approfondie, mais aboutit finalement à une réponse à la requête avec l'indicateur "réponse faisant autorité" défini .

Il est important de noter que le résolveur (généralement, espérons-le) n'essayera pas de décomposer le nom d'hôte en cours de résolution pour le demander pièce par pièce, mais l'enverra simplement dans son intégralité au "meilleur" serveur qu'il connaît. Étant donné que le serveur de noms faisant autorité moyen sur Internet ne fait pas autorité pour la grande majorité des noms DNS valides, la réponse sera une réponse de délégation sans autorité pointant vers un autre serveur DNS.

Désormais, il n'est plus nécessaire de nommer un serveur dans les enregistrements de délégation ou d'autorité pour faire autorité pour une zone. Prenons par exemple le cas d'un serveur maître privé; dans ce cas, il existe un serveur DNS faisant autorité que seuls les administrateurs des serveurs DNS esclaves de la zone connaissent. Un serveur DNS fait autorité pour une zone si, à travers un certain mécanisme, à son avis, il a une connaissance complète et précise de la zone en question. Un serveur DNS normalement faisant autorité peut, par exemple, devenir sans autorité si le ou les serveurs maîtres configurés ne peuvent pas être atteints dans le délai défini comme l'heure d'expiration dans l'enregistrement SOA.

Seules les réponses faisant autorité doivent être considérées comme des réponses de requête appropriées; tout le reste est soit une délégation, soit une erreur quelconque. Une délégation à un serveur sans autorité est appelée une délégation "boiteuse" et signifie que le résolveur doit revenir en arrière d'une étape et essayer un autre serveur DNS nommé. Si aucun serveur de noms accessible faisant autorité n'existe dans la délégation, la résolution de noms échoue (sinon, elle sera juste plus lente que la normale).

Tout cela est important car les données ne faisant pas autorité ne doivent pas être mises en cache . Comment pourrait-il en être ainsi, car le serveur sans autorité n'a pas l'image complète? Le serveur faisant autorité doit donc, de son propre chef, être en mesure de répondre à la question "qui est censé faire autorité et pour quoi?". Ce sont les informations fournies par les enregistrements NS dans la zone.

Il existe un certain nombre de cas extrêmes où cela peut réellement faire une différence sérieuse, principalement centré sur plusieurs étiquettes de nom d'hôte à l'intérieur d'une seule zone (probablement assez courant, par exemple avec des zones DNS inversées en particulier pour les grandes plages IP dynamiques) ou lorsque la liste des serveurs de noms diffère entre la zone parent et la zone en question (ce qui est très probablement une erreur, mais peut aussi être fait intentionnellement).


Vous pouvez voir comment cela fonctionne de manière un peu plus détaillée à l'aide de digses fonctionnalités +norec(ne pas demander de récursivité) et de @spécificateur de serveur. Ce qui suit est une illustration du fonctionnement d'un serveur DNS de résolution réel. Recherchez les enregistrements A pour unix.stackexchange.comcommencer, par exemple a.root-servers.net:

$ dig unix.stackexchange.com. A @a.root-servers.net. +norec

Examinez attentivement le nombre flagsainsi que le nombre par section. qrest la réponse à la requête et la aaréponse faisant autorité. Notez que vous êtes uniquement délégué aux comserveurs. Suivez manuellement cette délégation (dans la vie réelle, un résolveur récursif utilise l'adresse IP de la section supplémentaire si elle est fournie, ou lance une résolution de nom distincte de l'un des serveurs de noms nommés si aucune adresse IP n'est fournie dans la réponse de la délégation, mais nous allons sautez cette partie et revenez au résolveur normal du système d'exploitation pour la brièveté de l'exemple):

$ dig unix.stackexchange.com. A @a.gtld-servers.net. +norec

Vous voyez maintenant que cela stackexchange.comest délégué à (entre autres) ns1.serverfault.com, et vous n'obtenez toujours pas de réponse faisant autorité. Suivez à nouveau la délégation:

$ dig unix.stackexchange.com. A @ns1.serverfault.com. +norec
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35713
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;unix.stackexchange.com. IN A

;; ANSWER SECTION:
unix.stackexchange.com. 300 IN A 198.252.206.16

Bingo! Nous avons obtenu une réponse, car l' aaindicateur est défini, et il se trouve qu'il contient une adresse IP exactement comme nous l'espérions. Soit dit en passant, il convient de noter qu'au moins au moment où j'écris ce message, les listes de serveurs de noms délégués à et énumérés diffèrent, montrant que les deux n'ont pas besoin d'être identiques. Ce que j'ai illustré ci-dessus est essentiellement le travail effectué par n'importe quel résolveur, sauf que tout résolveur pratique mettra également en cache les réponses en cours de route afin qu'il n'ait pas à frapper les serveurs racine à chaque fois.

Comme vous pouvez le voir dans l'exemple ci-dessus, les enregistrements de délégation et de collage ont un objectif distinct des enregistrements d'autorité et d'adresse dans la zone elle-même.

Un serveur de noms de mise en cache et de résolution effectuera également généralement des vérifications d'intégrité sur les données renvoyées pour se protéger contre l'empoisonnement du cache. Par exemple, il peut refuser de mettre en cache une réponse nommant les serveurs faisant autorité pour compartir d' une source autre que celle qui a déjà été nommé par une zone mère comme deleged à pour com. Les détails dépendent du serveur, mais l'intention est de mettre en cache autant que possible tout en n'ouvrant pas la porte de la grange de permettre à n'importe quel serveur de noms aléatoires sur Internet de remplacer les enregistrements de délégation pour tout ce qui n'est pas officiellement sous sa «juridiction».


Merci beaucoup pour cette réponse détaillée. Imaginez donc que l'enregistrement de délégation envoie le résolveur à ns4.serverfault.com. Ce n'est pas répertorié dans les enregistrements NS du fichier de zone. Le résolveur remarque-t-il le décalage et la marche arrière? (une délégation boiteuse)? Je suppose que cela pose alors la question, pourquoi serait ns4.serverfault.com. être répertorié comme un enregistrement de délégation s'il n'est pas répertorié dans le fichier de zone?
Lars

@Lars Non, ns4.serverfault.com ferait toujours autorité; l'autorité (est-ce même un mot?) est indépendante du fait que le serveur en question soit nommé dans les enregistrements NS ou non, soit dans la zone elle-même, soit dans la délégation. Il s'agit uniquement d'une délégation boiteuse si un serveur délégué répond de manière non autorisée (c'est-à-dire que l' aaindicateur n'est pas défini sur la réponse).
un CVn du

1

Le registre .com est le "record de colle" qui a l'emplacement de vos serveurs de noms comme adresse IP. Le résolveur n'a aucun moyen de connaître l '"identité" de votre serveur DNS, il utilise donc l'enregistrement NS pour s'assurer que les numéros correspondent.

Demande DNS -> Registre .com (ip is xxxx) -> Correspondances DNS (NS xxxx), résolution.

S'ils ne correspondent pas ou n'existent pas, alors c'est une réponse sans autorité pour le domaine.


Merci mais je suis toujours un peu confus. Le résolveur utilise l'adresse IP dans l'enregistrement de colle dans le registre .com pour accéder au fichier de zone stocké à cette adresse IP. Il peut désormais récupérer l'enregistrement A. Pourquoi doit-il vérifier que cette IP de serveur de noms correspond à l'enregistrement NS dans le fichier de zone?
Lars

Pour qu'il sache qu'il cherche au bon endroit. Par exemple, si vous aviez un sous-domaine dont les enregistrements A résidaient sur un autre serveur, les enregistrements NS indiqueraient au résolveur où chercher. Un peu comme de la chapelure.
Nathan C
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.