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».
aaindicateur n'est pas défini sur la réponse).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.
la source