Quel est le rôle des enregistrements NS au sommet d'un domaine DNS?

21 
$ORIGIN example.com. ; not necessary, using this to self-document

$TTL 3600
@        IN     SOA   ns1.example.com. admin.example.com. (
                      1970010100 7200 1800 1209600 300)

@        IN     NS   ns1.example.com.
@        IN     NS   ns2.example.com.

@        IN     A    198.51.100.1
ns1      IN     A    198.51.100.2
ns2      IN     A    198.51.100.3

sub1     IN     NS   ns1.example.edu.

sub2     IN     NS   ns1.sub2
ns1.sub2 IN     A    203.0.113.1 ; inline glue record

Le rôle d'un enregistrement NS sous l'apex d'un domaine est bien compris; ils existent pour déléguer l'autorité d'un sous-domaine à un autre serveur de noms. Les exemples ci-dessus incluent les enregistrements NS pour sub1et sub2. Ceux-ci permettent au serveur de noms de distribuer des références pour des parties du domaine pour lesquelles il ne se considère pas comme faisant autorité.

Le but des enregistrements NS au sommet d'un domaine, ns1et ns2dans ce cas, semble être moins compris par Internet dans son ensemble. Ma compréhension (qui peut ne pas être holistique) est la suivante:

  1. Ils ne sont pas utilisés par la mise en cache des serveurs DNS afin de déterminer les serveurs faisant autorité pour le domaine. Ceci est géré par la colle de serveur de noms , qui est définie au niveau du registraire. Le registraire n'utilise jamais ces informations pour générer les enregistrements de colle.
  2. Ils ne sont pas utilisés pour déléguer l'autorité pour l'ensemble du domaine à d'autres serveurs de noms. Essayer de le faire avec un logiciel tel que ISC BIND n'entraînera pas du tout le comportement de référence "attendu", car le serveur de noms continuera de se considérer comme faisant autorité pour la zone.
  3. Ils ne sont pas utilisés par le serveur de noms pour déterminer s'il doit renvoyer des réponses faisant autorité ( AAjeu d'indicateurs) ou non; ce comportement est défini par le fait que le logiciel soit dit être maître ou esclave pour la zone. La plupart des logiciels de serveurs de noms serviront très volontiers les enregistrements apex NS qui ne sont pas d'accord avec les informations contenues dans les enregistrements de colle en amont, ce qui entraînera à son tour des sites Web de validation DNS connus à générer des avertissements pour le domaine.

Dans ce cas, que nous reste-t-il? Pourquoi définissons-nous ces informations si elles ne semblent pas être consommées par la mise en cache des serveurs DNS sur Internet en général?

domain-name-system ns-record glue-record Andrew B
la source

Réponses:

21

Identification subordonnée

Les enregistrements NS de niveau Apex sont utilisés par un serveur maître pour identifier ses subordonnés. Lorsque les données d'un serveur de noms faisant autorité changent, il en fera la publicité via des DNS NOTIFYmessages ( RFC 1996 ) à tous ses homologues de cette liste. Ces serveurs rappelleront à leur tour une demande d' SOAenregistrement (qui contient le numéro de série) et décideront de retirer une copie plus récente de cette zone.

  • Il est possible d'envoyer ces messages à des serveurs non répertoriés dans la NSsection, mais cela nécessite des directives de configuration spécifiques au serveur (telles que la also-notifydirective ISC BIND ). Les enregistrements apex NS comprennent la liste de base des serveurs à notifier dans une configuration par défaut.
  • Il convient de noter que les serveurs secondaires s'envoient également des messages NOTIFY sur la base de ces NSenregistrements, ce qui entraîne généralement des refus enregistrés. Cela peut être désactivé en demandant aux serveurs d'envoyer uniquement des notifications pour les zones pour lesquelles ils sont maîtres (BIND:) notify master;, ou d'ignorer les NSnotifications basées entièrement en faveur des notifications définies explicitement dans la configuration. (BIND: notify explicit;)

Définition faisant autorité

La question ci-dessus contenait une erreur:

Ils ne sont pas utilisés par la mise en cache des serveurs DNS afin de déterminer les serveurs faisant autorité pour le domaine. Ceci est géré par la colle de serveur de noms, qui est définie au niveau du registraire. Le registraire n'utilise jamais ces informations pour générer les enregistrements de colle.

Il s'agit d'une conclusion facile à atteindre, mais pas exacte. Les NSenregistrements et les données des enregistrements de collage (tels que ceux définis dans votre compte de registraire) ne font pas autorité. Il va de soi qu'ils ne peuvent pas être considérés comme "faisant plus autorité" que les données résidant sur les serveurs auxquels l'autorité est déléguée. Ceci est souligné par le fait que les références n'ont pas le aadrapeau (réponse faisant autorité) défini.

Pour illustrer:

$ dig @a.gtld-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14021
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      NS

;; AUTHORITY SECTION:
example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.

;; ADDITIONAL SECTION:
a.iana-servers.net.     172800  IN      A       199.43.135.53
a.iana-servers.net.     172800  IN      AAAA    2001:500:8f::53
b.iana-servers.net.     172800  IN      A       199.43.133.53
b.iana-servers.net.     172800  IN      AAAA    2001:500:8d::53

Notez l'absence de aadans les drapeaux pour la réponse ci-dessus. Le renvoi lui-même ne fait pas autorité. D'un autre côté, les données sur le serveur auquel il est fait référence font autorité.

$ dig @a.iana-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2349
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      NS

;; ANSWER SECTION:
example.com.            86400   IN      NS      a.iana-servers.net.
example.com.            86400   IN      NS      b.iana-servers.net.

Cela dit, cette relation peut devenir très confuse car il n'est pas possible d'en savoir plus sur les versions faisant autorité de ces NSenregistrements sans les enregistrements sans autorité NSdéfinis du côté parent de la référence. Que se passe-t-il en cas de désaccord?

  • La réponse courte est "comportement incohérent".
  • La réponse longue est que tout d' abord se nameservers stub hors de la saisine (et de la colle) sur un cache vide, mais ceux NS, Aet les AAAAdossiers peuvent éventuellement être remplacés lorsqu'ils sont régénérés. Les actualisations se produisent lorsque les TTL sur ces enregistrements temporaires expirent ou lorsque quelqu'un demande explicitement la réponse pour ces enregistrements.
    • Aet les AAAAenregistrements pour les données hors zone (c'est-à-dire les comserveurs de noms définissant la colle pour les données en dehors de la comzone, comme example.net) finiront certainement par être actualisés, car c'est un concept bien compris qu'un serveur de noms ne devrait pas être considéré comme une source faisant autorité de ces informations. . (RFC 2181)
    • Lorsque les valeurs des NSenregistrements diffèrent entre les côtés parent et enfant de la référence (tels que les serveurs de noms entrés dans le panneau de contrôle du registraire différant des NSenregistrements qui vivent sur ces mêmes serveurs), les comportements rencontrés seront incohérents, jusqu'à et y compris l'enfant NSles enregistrements étant complètement ignorés. En effet, le comportement n'est pas bien défini par les normes et l'implémentation varie entre les différentes implémentations de serveur récursif. En d'autres termes, un comportement cohérent sur Internet ne peut être attendu que si les définitions de serveur de noms pour un domaine sont cohérentes entre les côtés parent et enfant d'une référence .

Le long et le court est que les serveurs DNS récursifs sur Internet rebondiront entre les destinations si les enregistrements définis du côté parent de la référence ne sont pas d'accord avec les versions faisant autorité de ces enregistrements. Dans un premier temps, les données présentes dans la référence seront préférées, pour être remplacées uniquement par les définitions faisant autorité. Étant donné que les caches sont constamment reconstruits à partir de zéro sur Internet, il est impossible pour Internet de se contenter d'une seule version de la réalité avec cette configuration. Si les enregistrements faisant autorité font quelque chose d'illégal selon les normes, comme pointer des NSenregistrements vers des alias définis par unCNAME, cela devient encore plus difficile à dépanner; le domaine alternera entre fonctionnel et cassé pour un logiciel qui rejette la violation. (ie ISC BIND / nommé)

La RFC 2181 §5.4.1 fournit un tableau de classement pour la fiabilité de ces données, et rend explicite que les données de cache associées aux références et à la colle ne peuvent pas être renvoyées comme réponse à une demande explicite pour les enregistrements auxquels elles se réfèrent.

5.4.1. Ranking data

   When considering whether to accept an RRSet in a reply, or retain an
   RRSet already in its cache instead, a server should consider the
   relative likely trustworthiness of the various data.  An
   authoritative answer from a reply should replace cached data that had
   been obtained from additional information in an earlier reply.
   However additional information from a reply will be ignored if the
   cache contains data from an authoritative answer or a zone file.

   The accuracy of data available is assumed from its source.
   Trustworthiness shall be, in order from most to least:

     + Data from a primary zone file, other than glue data,
     + Data from a zone transfer, other than glue,
     + The authoritative data included in the answer section of an
       authoritative reply.
     + Data from the authority section of an authoritative answer,
     + Glue from a primary zone, or glue from a zone transfer,
     + Data from the answer section of a non-authoritative answer, and
       non-authoritative data from the answer section of authoritative
       answers,
     + Additional information from an authoritative answer,
       Data from the authority section of a non-authoritative answer,
       Additional information from non-authoritative answers.

   <snip>

   Unauthenticated RRs received and cached from the least trustworthy of
   those groupings, that is data from the additional data section, and
   data from the authority section of a non-authoritative answer, should
   not be cached in such a way that they would ever be returned as
   answers to a received query.  They may be returned as additional
   information where appropriate.  Ignoring this would allow the
   trustworthiness of relatively untrustworthy data to be increased
   without cause or excuse.
Andrew B
la source
Réponse bien écrite! Je ne suis pas d'accord avec le "long et court" de votre réponse. L'utilisation principale du DNS sur Internet consiste à obtenir l'adresse IP de l'hôte, donc les demandes "A". Les résolveurs DNS accepteront et remplaceront toujours la référence pour obtenir une réponse «A» faisant autorité. Et il ne mettra "toujours" en cache que le dossier de référence. La seule fois où les enregistrements seraient remplacés, c'est lorsqu'une demande explicite arrive pour un "example.com IN NS". Ensuite, le résolveur demandera au serveur à l'emplacement de référence. Et cette réponse AR remplacera la réponse de référence mise en cache (uniquement pour le TTL de cet enregistrement).
Wasted_Coder
Je peux me tromper selon la réponse de @BillThor. J'ai basé mon raisonnement sur le fait que si un serveur DNS actualise son entrée en cache NS pour example.com à partir d'une réponse NS faisant autorité (maintenant expirée). Cela brisera la chaîne DNS. Parce qu'il est maintenant coincé dans une boucle où, alors que le (l'ancien) serveur NS continue de répondre, il ne prendra pas en compte les modifications sur le serveur DNS apex ci-dessus (le registraire). Comme dans le cas où vous déplacez des serveurs DNS mais ne mettez pas à jour ou ne mettez pas l'ancien serveur DNS hors ligne. Ou ce «problème» est-il totalement le cas aujourd'hui?
Wasted_Coder
@Wasted Je suis également en désaccord avec votre premier commentaire en raison des nombreuses hypothèses avancées. Étant donné que le comportement n'est pas explicitement défini par les normes, il est en fait spécifique à l'implémentation. Cette présentation a 6 ans (commencez à la diapositive # 11), mais elle fait toujours passer le message; la préférence du serveur de noms parent / enfant variera. Au-delà, vous ne pouvez compter que sur les exigences RFC 2181.
Andrew B
Je pense que mon point de préoccupation est de savoir si les entrées en cache NS d'un résolveur atteignent TTL = 0, par exemple pour.com. Et il doit également rechercher une nouvelle entrée d'hôte non encore mise en cache, par exemple pour new.example.com. Il a maintenant besoin du ou des serveurs NS pour example.com et comme ses copies en cache sont expirées, il serait mauvais d'essayer quand même de toucher ce serveur NS "expiré" juste pour voir s'il répond toujours. Il FAUT vérifier auprès de l'ancêtre suivant, donc le NS de .com pour la direction. Cela signifie que les enregistrements NS ancêtres prévaudraient la plupart du temps (jusqu'à ce qu'une demande NS soit traitée).
Wasted_Coder
@Wasted Commencez à partir de la diapositive # 11 et notez les trois modèles: enfant centré non collant ( PPPCCCPPPCCC...), enfant centré collant ( PPPCCCCCC...) et parent collant ( PPPPPP...). Le collant centré sur l'enfant est de loin le plus courant, et le collant centré sur l'enfant est en fait plus répandu que le collant parent. Les clients vont en effet rebondir entre les deux versions de la réalité si les données NS sur l'enfant et le parent ne sont pas d'accord, sauf si le logiciel de résolution est collant pour les parents, ce qui est le résultat le moins probable.
Andrew B
3

Le NS enregistre que la zone déléguée fournit l'exhaustivité de la définition de domaine. Les serveurs NS eux-mêmes s'appuieront sur le fichier de zone. Ils ne devraient pas essayer de se retrouver en faisant une requête récursive à partir des serveurs racine. Les enregistrements NS dans le fichier de zone fournissent un certain nombre d'autres fonctions.

Les serveurs de mise en cache peuvent actualiser la liste des serveurs de noms en interrogeant un serveur de noms à partir de son cache. Tant qu'un serveur de mise en cache connaît l'adresse d'un serveur de noms, il l'utilisera plutôt que de rechercher récursivement un enregistrement NS approprié.

Lors du déplacement de serveurs de noms, il est important de mettre à jour les anciens serveurs de noms ainsi que les nouveaux serveurs de noms. Cela évitera les pannes ou les incohérences qui se produiront lorsque les deux définitions de zone seront désynchronisées. Les enregistrements mis à jour seront éventuellement actualisés par tous les serveurs qui ont mis en cache les enregistrements NS. Cela remplacera la liste mise en cache des serveurs de noms.

Les enregistrements NS aident également à confirmer l'exactitude de la configuration DNS. Le logiciel de validation vérifie souvent que les définitions de serveur de noms de la zone délégante correspondent à celles fournies par la zone. Cette vérification peut être effectuée sur tous les serveurs de noms. Tout décalage peut indiquer une mauvaise configuration.

Les enregistrements NS permettent de créer des zones (locales) déconnectées. Il peut s'agir de sous-domaines d'un domaine enregistré ou d'un domaine entièrement nouveau (non recommandé en raison des changements de TLD). Les hôtes qui utilisent les serveurs de noms comme leur serveur de noms pourront trouver les zones qui ne sont pas accessibles en recursant à partir des serveurs racine. D'autres serveurs de noms peuvent être configurés pour rechercher les serveurs de noms pour les zones locales.

Dans le cas d'un DNS partagé (interne / externe), il peut être souhaitable d'avoir un ensemble différent de serveurs DNS. Dans ce cas, la liste NS (et probablement d'autres données) sera différente, et les enregistrements NS dans les fichiers de zone répertorieront la liste de serveurs de noms appropriée.

BillThor
la source