Я не уверен, что действительно вижу ваш вопрос.
ДОПОЛНИТЕЛЬНЫЙ определяется как необязательный (поэтому клиент может игнорировать эти данные, и по соображениям безопасности он действительно должен игнорировать их большую часть времени) ... за исключением случаев, когда нет другого способа добиться чего-либо, которые являются клеями.
Но проблема в том, что ДОПОЛНИТЕЛЬНЫЕ клеи не покрываются DNSSEC, следовательно, не аутентифицируются, поэтому с ними нужно обращаться осторожно.
Обратите внимание, что ваш случай Adobe.net используя серверы имен под omtrdc.net не является определением «в бейливике». Это было бы в бейливике, если бы имена серверов имен также находились под Adobe.net. Таким образом, ваш случай - это то, что называется «внутренними серверами имен», поскольку имена серверов имен являются внутренними для того же реестра, что и доменное имя, для которого они являются авторитетными.
[Боковое личное примечание, если честно: я считаю эту настройку домена A с использованием серверов имен в домене B, чьи серверы имен вернулись в домен A, действительно опасной. Любая ошибка в А или же B, возможно, отключает разрешение обоих A и Б; это своего рода петли, и следует избегать петель в DNS (или относиться к ним с осторожностью и применять соответствующие меры и меры защиты)].
В RFC 8499 можно найти множество замечательных определений терминологии DNS.
У него есть, например:
Bailiwick: «In-bailiwick» — это модификатор для описания сервера имен.
чье имя является субдоменом домена или (редко) совпадает с
происхождение зоны, содержащей делегирование на имя
сервер.
Что касается
Есть ли смысл или я забыл некоторые важные детали?
Вы отлично справляетесь, показывая DNS-выводы dig или подобного, но что отсутствует/неясно, так это то, какой сервер имен вы запрашиваете для данных, вы должны показать это и изучить это, чтобы иметь четкую картину. Я вижу, что в большинстве случаев непонимание в DNS происходит из-за путаницы между авторитетными и рекурсивными серверами имен.
ДОПОЛНИТЕЛЬНЫЙ section определен так, как в RFC 1034:
Дополнительный
Содержит RR, которые могут быть полезны при использовании RR в
другие разделы.
Затем он полностью появляется в §4.3.2, в котором описывается алгоритм разрешения:
Скопируйте записи NS RR для подзоны в центр
часть ответа. Ставьте любые адреса
доступны в дополнительном разделе, используя клеевые РР
если адреса недоступны у официальных
данные или кеш. Перейти к шагу 4.
Вернувшись к RFC 8499, вы получите дополнительные пояснения:
Ответ, содержащий только реферал, содержит пустой ответ
раздел. Он содержит NS RRset для упомянутой зоны в
Раздел авторитета. Он может содержать RR, предоставляющие адреса в
дополнительный раздел. Бит AA ясен.
и
В случае, когда запрос соответствует псевдониму, а сервер
не является авторитетным для цели псевдонима, но является авторитетным
для некоторого имени над целью псевдонима разрешение
алгоритм выдаст ответ, который содержит оба
авторитетный ответ для псевдонима и направления. Такое частичное
ответ и реферальный ответ имеют данные в разделе «Ответ». Это
имеет NS RRset для упомянутой зоны в Уполномоченном
раздел. Он может содержать RR, предоставляющие адреса в
дополнительный раздел.
Что касается:
Тем не менее, я видел некоторые реализации
Так, содержание ДОПОЛНИТЕЛЬНЫЙ может измениться в зависимости от того, какой сервер имен вы запрашиваете и как он настроен. См., например, минимальные ответы опция Bind, задокументированная на https://bind9.readthedocs.io/en/latest/reference.html заявляя: «Эта опция управляет добавлением записей в авторитетные и дополнительные разделы ответов. Такие записи могут быть включены в ответы, чтобы быть полезными для клиентов; например, записи NS или MX могут иметь связанные записи адресов, включенные в дополнительный раздел, устраняя необходимость в отдельном поиске адреса. Однако добавление этих записей в ответы не является обязательным и требует дополнительных поисков в базе данных, что приводит к дополнительной задержке при упорядочивании ответов». У него 4 возможных значения, так много разных вариантов поведения в сети.
И, наконец, для:
поскольку сервер TLD управляет сетью. зоне, мы можем верить чему угодно под сетью.
Да и нет :-). Возьмем, к примеру, «эксперимент» Verisign SiteFinder в прошлом: вы запрашиваете любые авторитетные серверы имен com для любого несуществующего имени, и вы получаете обратно А записывать. Вы верите в это или нет?
