В какой момент записи NS, определенные в вершине зоны, запрашиваются во время нормальной работы?
Из того, что я исследовал, эти записи используются:
DNS NOTIFY, для главного, чтобы сигнализировать подчиненным серверам, чтобы они извлекли его SOA и обновили свои файлы зоны при изменении главного.
Некоторые инструменты для проверки правильности определений зон DNS
Итерационные преобразователи DNS, если они кэшировали авторитетные записи NS для зоны, они будут использовать их для ответов на запросы для этой зоны вместо перехода на корневые / TLD / родительские серверы.
Сам сервер, чтобы объявить себя авторитетным для своей зоны (хотя я не уверен, что это так, я считаю, что это устанавливается либо извне каждой реализацией DNS, либо ссылочными NS-записями родительского DNS-сервера, а не в файле зоны, или через запись SOA)
Я не понимаю, при каких обстоятельствах итеративный преобразователь DNS когда-либо кэширует записи NS для зоны. если он не получит запрос специально для записей NS этой зоны
Позвольте мне уточнить. Насколько я понимаю, когда итеративному преобразователю с пустым кешем выдается запрос на ресурс (например, IN A www.example.com.), Так и будет:
Запросить корневой DNS-сервер для IN A www.example.com.
1.1. Он получит пустой раздел ответа
1.2. Раздел полномочий с записями NS для .com. зона (они не являются авторитетными).
1.3. Он будет кэшировать эти неавторизованные NS-записи (если это не липкие дочерние или родительские записи). Хотя RFC 2181 говорит, что вы НЕ ДОЛЖНЫ этого делать.
Запросить TDL .com. DNS-сервер для IN A www.example.com.
2.1. Та же сделка, что и выше, но неавторизованные записи NS предназначены для example.com.
Запросить NS-сервер example.com. для IN A www.example.com.
3.1 Получите авторитетный ответ на www.example.com.
3.2 Он кэширует полученную запись A.
3.3 Он вернет ответ клиенту
Ни разу во время вышеуказанного обмена итеративный преобразователь не отправлял запрос IN NS example.com. или IN NS .com. или любой другой запрос для авторитетный Записи NS для любой зоны. Итак, из того, что я собираю, если какой-либо клиент / пользователь итеративного преобразователя DNS не отправит точный запрос IN NS example.com., итеративный преобразователь будет никогда кэшировать авторитетные записи NS для IN NS example.com.
Это так? Или реализации итеративных DNS-преобразователей запускают NS-запросы для зон с целью кэширования их авторитетных NS-записей и ускорения будущих запросов для того же домена? Или они кэшируют только авторитетные записи NS, если клиент случайным образом запрашивает записи NS для зоны? Есть ли вообще общий или самый популярный шаблон в реализациях DNS-преобразователей?
Ссылки:
Смотрите алгоритм на https://tools.ietf.org/html/rfc7816#appendix-A это касается только использования NS-записей и того, как их использовать.
Запрос на NS Записи необходимы, чтобы найти информацию о срезах зон, что затем необходимо для правильной проверки DNSSEC, а также для минимизации QNAME.
RFC 7816 по минимизации QNAME говорит об этом в разделе 2:
Вместо отправки полного QNAME и исходного QTYPE в восходящем направлении преобразователь, который реализует минимизацию QNAME и еще не имеет ответа в своем кэше, отправляет запрос на сервер имен, уполномоченный для ближайшего известного предка исходного QNAME.
Запрос выполняется с помощью:o QTYPE NS
o QNAME, которое является исходным QNAME, разделенное на одну метку больше, чем зона, для которой сервер является полномочным
С помощью NS записи, таким образом заставляет клиента (рекурсивный сервер имен) не передавать какие-либо данные о текущем летающем запросе авторитетным серверам имен, которые он запрашивает.
Это правда, что в разделе 3 объясняется, что для обхода некоторых сломанных серверов имен вы (рекурсивный клиент) можете попробовать A записи вместо NS ед. Однако это все еще и только обходной путь для других сломанных DNS-серверов.
Кроме того, в широко распространенном представлении DNS является «дочерним», что означает, что релевантный набор NS исходит от дочернего, а не от родителя, поскольку это единственный набор записей, который может быть подписан в DNSSEC (ссылки, не входящие в раздел ОТВЕТ). Но если преобразователь делает только это и перепроверяет только дочерний элемент, это означает, что домен никогда не может исчезнуть или изменить серверы имен ... следовательно, преобразователь должен периодически проверять родительский элемент на наличие NS.
См. Этот черновик, над которым в настоящее время работают: https://datatracker.ietf.org/doc/draft-huque-dnsop-ns-revalidation/?include_text=1
Он имеет следующий соответствующий абзац:
Официально верхний NS RRset дочерней зоны является авторитетным и, следовательно, имеет более высокую надежность кеширования, чем родительский делегированный NS RRset, который не является авторитетным связующим звеном ([RFC2181], раздел 5.4.1. Данные ранжирования). Следовательно, набор NS RRset «ниже разреза зоны» должен немедленно заменить родительский делегирующий набор NS RRset в кеше, когда преобразователь DNS с итеративным кэшированием пересекает границу зоны. Однако это может произойти только в том случае, если (1) преобразователь получает авторитетный NS RRset в разделе Authority ответа от дочерней зоны, что не является обязательным, или (2) если преобразователь явно выдает запрос NS RRset дочернему элементу зона как часть его итеративного алгоритма разрешения. В отсутствие этого резольвер с итеративным кэшированием может никогда не узнать авторитетный NS RRset для зоны, если только нижестоящий клиент резолвера явно не выдает такой NS-запрос, что не является тем, что делают обычные приложения конечного пользователя, и таким образом, нельзя полагаться на то, что оно будет происходить с какой-либо регулярностью.
Затем обратите внимание на все следующие подробности в разделе 3 о том, когда и почему рекурсивный сервер имен должен выдавать NS Запросы типов записей для правильной повторной проверки данных.
Обратите внимание, что этот документ в настоящее время запрашивается для принятия рабочей группой IETF по DNS. Если это произойдет, позже он может стать полным стандартом (RFC).
Я думаю, что на самом деле есть один основной случай, который будет отклоняться от заявленных вами ожиданий, и дополнительный случай, который менее распространен, и оба относятся к конкретной реализации:
Авторитетный сервер для example.com кнопки на NS записи на свой ответ для www.example.com. IN A. Это не обязательно, но может. Традиционно это было довольно распространенным поведением.
minimal-responses опция включена.Сервер резолвера ищет example.com. IN NS как часть отслеживания реферала. Необычное поведение.
harden-referral-path опция включена.