Кратко

  • Бит DNS Authoritative Answer привязан к имени в Question либо к первому имени-владельцу в Answer; цель псевдонима, записи Authority, glue и данные Additional в том же сообщении могут иметь иную историю происхождения.
  • Проверяемая квитанция хранит для каждого RRset владельца, тип, раздел, границу зоны, источник кэша и состояние DNSSEC, а также последующие запросы, не превращая один бит заголовка в авторитетность или подлинность всего пакета.

Резолвер спрашивает адрес shop.example. Сервер авторитетен для этого имени и возвращает CNAME. Следом идёт адрес цели, взятый из кэша, а в Additional находится ещё один полезный адрес. В заголовке установлен AA.

Операционная база сохраняет три RRset в одной строке с признаком authoritative=true. Позже прямой ответ из зоны цели сообщает другой адрес, но объяснить расхождение уже нельзя: утверждение об alias, кэшированный результат и дополнительная подсказка потеряли свои границы.

Это условная проверка модели доказательств, а не описание реального сбоя или атаки.

У одного бита один ориентир

RFC 1035, написанный Paul Mockapetris, определяет AA для DNS-ответов. Он означает, что отвечающий сервер авторитетен для доменного имени в разделе Question. Поскольку из-за псевдонимов в Answer бывает несколько владельцев, документ связывает AA с именем запроса или с первым владельцем в Answer.

AA не повторяется возле каждого RRset. Он характеризует полномочия сервера в начале пути ответа, но не распространяет их на последующие имена, все разделы сообщения и любые внутренние источники.

RFC 1034 показывает, откуда берётся неоднородность. Найдя CNAME в авторитетной зоне, сервер копирует его в Answer, меняет QNAME на каноническое имя и начинает обработку заново. При делегировании NS попадает в Authority, а доступные адреса — в Additional; они могут происходить из glue, авторитетных данных или кэша. Перед отправкой добавляются и другие локально доступные полезные записи.

Одна транспортная единица поэтому не обязана быть одним классом доказательства.

Раздел сохраняет контекст, но не выдаёт сертификат

В RFC 1035 Answer содержит ответ на вопрос, Authority указывает на авторитетный сервер, Additional несёт связанные сведения, которые не являются строгим ответом. Положение RRset необходимо сохранить, однако одного названия раздела недостаточно для атрибуции.

На границе делегирования родитель может передать адрес сервера дочерней зоны как glue. Иначе возникает круг: чтобы узнать адрес сервера, надо обратиться к серверу, адрес которого ещё неизвестен. Glue позволяет продолжить разрешение, но не даёт родителю полномочий ниже zone cut и не становится утверждением дочерней зоны.

RFC 2181 задаёт разные ранги: данные основного файла и трансфера зоны без glue, авторитетный Answer, Authority из авторитетного ответа, glue, неавторитетный Answer и Additional. Новый авторитетный RRset может заменить значение, прежде полученное как Additional. Более слабый источник не должен побеждать лишь потому, что первым оказался в кэше.

Если ранг отбросить, кэш отмывает происхождение. Вспомогательный адрес позже выдаётся в Answer и выглядит получившим новый статус. Но время в памяти уменьшило TTL, а не изменило автора данных.

Псевдоним переносит вопрос в другую юрисдикцию

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

RFC 6604 повторяет правило для цепочек CNAME и DNAME: статус полномочий может различаться на каждом звене xNAME. AA всё равно определяется первым владельцем в Answer.

Сервер shop.example вправе авторитетно сказать, что имя указывает на service.vendor.test. Кэшированный адрес цели полезен, но не превращается в заявление зоны поставщика. Граница пересекается лишь следующим запросом, у которого собственные сервер, время и ответ.

Журнал должен хранить рёбра: исходное имя, RRset CNAME или DNAME, исходную зону и ответ, следующее имя и новый запрос. Сведение цепочки к конечному адресу подходит быстрому кэшу, но лишает аудит возможности назвать автора каждого утверждения.

Полномочие не равно криптографической подлинности

RFC 6604 прямо указывает: DNSSEC не защищает бит AA. TSIG или SIG(0) способны защитить транзакцию между сторонами, а DNSSEC проверяет RRset по собственной цепочке доказательств.

RFC 4035 требует определять для каждого RRset состояние Secure, Insecure, Bogus или Indeterminate. Вывод строится из RRSIG, DNSKEY, DS, якоря доверия, доказательства отрицательного ответа и политики. AA ни одно из этих состояний не создаёт.

AD — не усиленный AA. DNSSEC-aware сервер должен устанавливать AD, только когда считает подлинными соответствующие RRset в Answer и Authority. Клиенту всё равно требуется доверять рекурсивному серверу и каналу либо выполнить локальную проверку. Additional не получает автоматической защиты от одного флага.

В одном пакете могут одновременно быть корректный AA для первого имени, Secure CNAME, Insecure цель, glue в Additional и неаутентифицированный канал к посреднику. Это не противоречие, а нормальная многомерность DNS-доказательств.

Что подтверждает имя Mockapetris

Internet Hall of Fame называет Paul Mockapetris создателем DNS в 1983 году в Information Sciences Institute при USC. RFC 1034 и 1035 фиксируют его авторство. Исторический публичный портрет на странице служит основой идентичности для редакционной иллюстрации.

Источники не делают его оператором современного сервера, владельцем зоны или распорядителем конкретной реализации. Поздние RFC — коллективная работа. Точная оценка вклада требует не расширять исходный бит: распределённая система имён нуждается в сохранении границ полномочий.

Квитанция RRset вместо ярлыка пакета

Сначала сохраняются QNAME, QTYPE, QCLASS, запрос рекурсии, DO/CD, идентификатор транзакции и время отправки. Для ответа фиксируются исходные байты, endpoint, транспорт, время получения и защита транзакции.

Затем сообщение делится на RRset. Каждый получает владельца, тип, класс, раздел, наблюдавшийся TTL, zone cut, bailiwick, известный источник, время помещения в кэш и срок. Если клиент не знает, использовал ли сервер зону или кэш, неопределённость остаётся открытой; AA не заполняет её.

Отдельная запись AA содержит исходный QNAME, первого владельца Answer, сервер и авторитетную зону. Каждый alias и referral связывается со следующим запросом. NS родителя, glue и прямой ответ ребёнка остаются родственными, но разными фактами.

DNSSEC-слой добавляет к RRset состояние, подписи, путь DS/DNSKEY, якорь доверия, время и причину. Полученный AD хранится как утверждение upstream. Приложение записывает, какой RRset и поколение кэша оно использовало.

Итоговая формулировка становится проверяемой: этот сервер установил AA для первого имени; этот RRset пришёл из такого раздела и источника; этот валидатор назначил ему такое состояние; следующий запрос установил полномочие для следующего имени; приложение использовало этот результат. Бит остаётся точным, когда ему не поручают говорить за весь ответ.

Источники