Какова роль записей NS на вершине домена DNS?

Подчиненная идентификация

Записи NS уровня Apex используются главным сервером для идентификации его подчиненных. Когда данные на авторитетном сервере имен меняются, он будет рекламировать это через DNS NOTIFY сообщения ( RFC 1996) для всех своих коллег в этом списке. Эти серверы в свою очередь перезвонят с запросом на SOA запись (которая содержит серийный номер), и принять решение о том, чтобы развернуть более свежую копию этой зоны.

• Можно отправлять эти сообщения на серверы, не указанные в NS раздел, но для этого требуются специфические для сервера директивы конфигурации (например, ISC BIND also-notify Директива). Записи NS Apex содержат основной список серверов, которые необходимо уведомить в конфигурации по умолчанию.
• Стоит отметить, что вторичные серверы также будут отправлять сообщения NOTIFY друг другу на основе этих NS записи, обычно приводящие к зарегистрированным отказам. Это можно отключить, указав серверам отправлять уведомления только тем зонам, для которых они являются хозяевами (BIND: notify master;) или пропустить NS На основе уведомлений полностью в пользу уведомлений, явно определенных в конфигурации. (BIND: notify explicit;)

Авторитетное определение

Вопрос выше содержал ошибку:

Они не используются кэширующими DNS-серверами, чтобы определить полномочные серверы для домена. Это обрабатывается клеем сервера имен, который определяется на уровне регистратора. Регистратор никогда не использует эту информацию для создания склеенных записей.

Это простой вывод, но не точный. NS записи и данные клея (например, определенные в вашей учетной записи регистратора) не являются официальными. Само собой разумеется, что их нельзя считать "более авторитетными", чем данные, находящиеся на серверах, которым делегированы полномочия. Это подчеркивается тем фактом, что рефералы не имеют aa (Авторитетный ответ) флаг установлен.

Проиллюстрировать:

$ 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

Обратите внимание на отсутствие aa в флагах за ответ выше. Само направление не является авторитетным. С другой стороны, данные на упомянутом сервере являются достоверными.

$ 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.

Тем не менее, эти отношения могут стать очень запутанными, так как невозможно узнать об авторитетных версиях этих NS записи без неавторизированных NS записи, определенные на родительской стороне реферала. Что будет, если они не согласятся?

• Короткий ответ - "противоречивое поведение".
• Длинный ответ заключается в том, что серверы имен будут изначально заглушать все от реферала (и клея) в пустом кеше, но те NS, A, а также AAAA записи могут быть в конечном итоге заменены при обновлении. Обновления происходят по истечении срока действия TTL для этих временных записей или когда кто-то явно запрашивает ответ для этих записей.
  • A а также AAAA записи для данных вне зоны (т.е. com серверы имен, определяющие клей для данных за пределами com зона, как example.net) определенно будет обновляться, поскольку существует хорошо понятная концепция, согласно которой сервер имен не следует считать авторитетным источником такой информации. (RFC 2181)
  • Когда значения NS записи различаются между родительской и дочерней сторонами реферала (например, серверы имен, введенные в панель управления регистратора, отличаются от NS записи, которые живут на тех же серверах), поведение будет противоречивым, вплоть до ребенка NS записи полностью игнорируются. Это связано с тем, что поведение не совсем определено стандартами, а реализация различается в разных рекурсивных реализациях сервера. Другими словами, согласованного поведения в Интернете можно ожидать только в том случае, если определения сервера имен для домена согласованы между родительской и дочерней сторонами реферала.

Короче говоря, рекурсивные DNS-серверы по всему Интернету будут восстанавливаться между пунктами назначения, если записи, определенные на родительской стороне реферала, не согласуются с официальными версиями этих записей. Первоначально данные, представленные в реферале, будут предпочтительными, только для замены авторитетными определениями. Поскольку кеши постоянно перестраиваются с нуля по всему интернету, для интернета невозможно выбрать одну версию реальности с такой конфигурацией. Если авторитетные записи делают что-то незаконное в соответствии со стандартами, например, указание NS записи под псевдонимами, определенными CNAME это становится еще труднее устранять; домен будет чередоваться между работающим и неработающим для программного обеспечения, которое отклоняет нарушение. (т.е. ISC BIND / named)

RFC 2181 §5.4.1 предоставляет таблицу ранжирования для достоверности этих данных и делает явным, что данные кеша, связанные с ссылками и склеиванием, не могут быть возвращены в качестве ответа на явный запрос записей, на которые они ссылаются.

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.