Я немного запутался в объеме функциональных возможностей записей полномочий и дополнительных ресурсов.
Мне кажется, что раздел полномочий обычно содержит записи SOA (отрицательный ответ) или записи NS (указывающие на авторитетные серверы имен).
Дополнительный раздел, как мне кажется, обычно переводит записи, которые находятся либо в разделе ответов (MX), либо в разделе полномочий (NS). Вот почему он обычно содержит записи A и AAAA. Но я также видел, что он иногда содержит заголовки OPT (хотя я не знаком с опциями DNS).
Я просмотрел RFC1034 и RFC1035, и, по сути, там не было других вариантов использования. Есть ли еще варианты использования для этих разделов?
решение1
Я бы сказал, что главное, о чем следует подумать, чтобы понять разделы и то, куда какие RR должны идти, заключается в том, что, как правило, тип RR сам по себе не диктует, в какой раздел он должен идти (по крайней мере, не однозначно), а причина, по которой RR добавляется в ответ, диктует, куда именно он должен идти.
Конечно, только некоторые типы RR имеют отношение к некоторым из этих случаев, так что связь существует, но тип RR обычно может существовать в разных разделах в зависимости от ситуации.
Раздел полномочий
Информационные записи органов власти, как в направлениях, так и в ответах органов власти.
Сопутствующие типы RR: SOA(отрицательный ответ), NS(рефералы, также когда добавлены в авторитетный ответ), DS(рефералы)
Дополнительно: RRSIG, NSEC(или варианты NSEC3, ...)
Раздел ответов
RR, представляющие прямой ответ на вопрос
Ассоциированные типы RR: запрошенный тип RR (включая SOA, NS, DS, и т. д., если вы явно запрашиваете их), или CNAMEесли имя является псевдонимом. (Или что-либо существующее, если ANYзапрашивается.)
Дополнительно:RRSIG
Дополнительный раздел
Записи ресурсов, которые не были запрошены, но связаны с данными в фактическом ответе. (Клиент должен использовать их очень осторожно.)
Также используется при добавлении записей ресурсов, содержащих данные для дополнительных функций протокола DNS, таких как EDNS, TSIG и т. д.
Ассоциированные типы RR: обычно A/ AAAA(адресные записи, относящиеся к фактическому ответу)
Дополнительно: RRSIG
расширение протокола DNS: OPTдля дополнительных заголовков DNS в EDNS(0), TSIGдля аутентификации сообщений DNS, SIGдля вариации аутентификации сообщений SIG(0) и т. д.
RFC1034 и RFC1035 были исходными основными DNS RFC, но это документы 1987 года, которые, очевидно, не охватывают эволюцию, которая продолжалась с того момента до того, что мы имеем сегодня. ЕстьмногоЗапросы предложений (RFC), которые продолжают развиваться на этой основе.