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

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

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

• Эти сообщения можно отправлять на серверы, не указанные в NS раздел, но для этого требуются специфические для сервера директивы конфигурации (такие как ISC BIND also-notify директива). Записи вершины NS составляют основной список серверов, которые необходимо уведомить в конфигурации по умолчанию.
• Стоит отметить, что вторичные серверы также будут отправлять друг другу сообщения NOTIFY на основе этих NS записи, обычно приводящие к зарегистрированным отказам. Это можно отключить, указав серверам отправлять уведомления только для зон, для которых они являются главными (BIND: notify master;) или пропустить NS based уведомляет полностью в пользу уведомлений, явно определенных в конфигурации. (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 записи могут быть в конечном итоге заменены при обновлении. Обновления происходят по мере истечения срока жизни этих временных записей или когда кто-то явно запрашивает ответ для этих записей.
  • A и AAAA записи для данных вне зоны (т. е. com серверы имен, определяющие клей для данных за пределами com зона, как example.net) обязательно в конечном итоге будет обновлен, поскольку это хорошо понимаемая концепция, согласно которой сервер имен не должен считаться авторитетным источником такой информации. (RFC 2181)
  • Когда значения NS записи различаются между родительской и дочерней сторонами реферала (например, серверы имен, введенные в панель управления регистратора, отличаются от NS записи, которые хранятся на тех же серверах), поведение будет непоследовательным, вплоть до дочерних NS записи полностью игнорируются. Это связано с тем, что поведение не определено стандартами, а реализация варьируется в зависимости от реализации рекурсивного сервера. Другими словами, согласованного поведения в Интернете можно ожидать только в том случае, если определения сервера имен для домена согласованы между родительской и дочерней сторонами перехода.

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

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.

Записи NS о делегированной зоне обеспечивают полноту определения домена. Сами серверы NS будут полагаться на файл зоны. От них не ожидается попыток найти себя, выполнив рекурсивный запрос с корневых серверов. Записи NS в файле зоны предоставляют ряд других функций.

Кэширующие серверы могут обновлять список серверов имен, запрашивая сервер имен из его кеша. Пока кэширующий сервер знает адрес сервера имен, он будет использовать его, а не рекурсивно искать соответствующую NS-запись.

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

Записи NS также помогают подтвердить правильность конфигурации DNS. Программное обеспечение для проверки часто проверяет, соответствуют ли определения сервера имен зоны делегирования тем, которые предоставлены этой зоной. Эта проверка может выполняться на всех серверах имен. Любые несоответствия могут указывать на неправильную конфигурацию.

Наличие записей NS позволяет создавать отключенные (локальные) зоны. Это могут быть поддомены зарегистрированного домена или совершенно новый домен (не рекомендуется из-за изменений TLD). Хосты, которые используют серверы имен в качестве своих серверов имен, смогут находить зоны, которые недоступны, путем рекурсии с корневых серверов. Другие серверы имен могут быть настроены для поиска серверов имен в локальных зонах.

В случае разделения DNS (внутреннего / внешнего) может потребоваться другой набор DNS-серверов. В этом случае список NS (и, вероятно, другие данные) будет другим, а записи NS в файлах зоны будут содержать соответствующий список серверов имен.