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.