Кратко

  • RFC 9718 отделяет материал корневого ключа DNSSEC от механизмов аутентификации распространяющего его файла; ни УЦ ICANN, ни Web PKI не являются якорем DNSSEC.
  • Пригодный якорь требует пяти независимых суждений: подлинный файл, допустимое время, согласованные представления, поддерживаемый разбор и явное принятие оператором.

Цепочку доверия легко описывать сверху вниз. Валидатор начинает с доверенного ключа, проверяет корень и следует по подписанным делегированиям. Неудобный вопрос направлен вверх: кто проверил самый первый ключ?

RFC 4033 не скрывает эту границу. Якорь доверия — авторитетный DNSKEY либо дайджест DS, настроенный в валидаторе; начальное значение получают безопасным или доверенным способом вне DNS. DNSSEC аутентифицирует продолжение цепочки, но не решение, сделавшее якорь доверенным.

В этом состоит долговременный вклад RFC 9718, соавтором которого был Joe Abley. Документ опубликован в январе 2025 года как информационный RFC IETF, заменяет RFC 7958 и описывает публикацию IANA сведений о якорях корневой зоны. Он не устраняет внешнее доверие, а обозначает его швы.

Первый шов проходит между объектом и конвертом. IANA публикует XML с записями KeyDigest. Отделённая подпись CMS может вести к центру сертификации под контролем ICANN, а HTTPS — аутентифицировать доставку посредством Web PKI. Эти механизмы помогают установить ожидаемого издателя и неизменность документа.

Однако УЦ ICANN прямо не является якорем DNSSEC. Цепочка сертификатов аутентифицирует опубликованный объект. Дайджест или открытый ключ внутри него может стать якорем DNSSEC только после обработки и принятия. Если назвать оба «корнем доверия», исчезнут две разные системы и момент, когда оператор меняет состояние валидатора.

Переход от RFC 7958 подчёркивает разделение. В прежней схеме были сертификаты PKIX, запросы на сертификаты для отдельных ключей и отделённый механизм OpenPGP. RFC 9718 убрал их, поскольку они смешивали внешнее доверие к ключам аутентификации с внешним доверием к корневым ключам DNSSEC. Дополнительная криптографическая упаковка не отменяла стартового выбора.

В XML также существуют независимые состояния. validFrom и validUntil ограничивают период допустимого использования KeyDigest. Они не доказывают повсеместную установку и не предписывают её. Правильно подписанный, но устаревший файл не становится автоматически приемлемой текущей конфигурацией.

Необязательный publickeyinfo может содержать открытый DNSKEY и flags в дополнение к дайджесту. Он позволяет непосредственно сформировать DNSKEY, но создаёт требование согласованности: при расхождении открытого ключа и дайджеста данный KeyDigest использовать нельзя. Действительная подпись CMS не исправляет внутреннее противоречие.

Необязательность отражает и локальные возможности. Два соответствующих стандарту обработчика способны получить разные множества кандидатов из одного подлинного XML, если лишь один понимает publickeyinfo. Общее происхождение не гарантирует одинакового толкования; версию парсера, преобразование и вывод надо сохранять в эксплуатационной квитанции.

Даже атрибут source носит лишь рекомендательный характер. URL указывает местонахождение документа, но не получает полномочий от самого факта записи в нём. Адрес — не мандат.

Последним следует принятие. RFC 9718 оставляет оператору право принимать якоря по собственной политике. IANA публикует; системы сертификатов помогают проверить происхождение; разработчики разбирают; поставщики упаковывают; оператор решает, что войдёт в доверенное состояние резолвера.

RFC 5011 не отменяет первого решения. Валидатор, уже доверяющий якорю, может после периодов наблюдения изучать преемников внутри протокола. Имеющееся доверие аутентифицирует переход, но не оправдывает задним числом первоначальную установку.

На текущей странице IANA поверхности распределены наглядно: root-anchors.xml несёт данные, root-anchors.p7s — отделённую подпись, icannbundle.pem — сертификаты для её проверки. Там же отмечено, что поставщики распространяют обновления разными способами и в разные сроки.

В уведомлении ноября 2024 года IANA рекомендовала регулярно получать XML и испытывать обновлённый формат. Успешная публикация не равна успешному внедрению: подлинный и своевременный файл может быть отвергнут парсером, задержан старым пакетом или не принят оператором.

Действующий root-anchors.xml — машиночитаемый объект публикации, а не заявление о принятии его записей конкретным резолвером.

Биография NSRC указывает, что Abley руководил DNS Operations в ICANN и участвовал во внедрении DNSSEC в корневой зоне. Это не делает его сувереном корня. Зато объясняет эксплуатационную дисциплину RFC: соседние доказательства не должны подменять друг друга.

Проверяемая квитанция должна хранить пять ответов: чем проверены источник и содержимое? Находилась ли запись в допустимом периоде? Совпали ли представления? Какой парсер и преобразование создали кандидата? Кто принял его, в какой валидатор и по какой политике? «Подпись действительна» отвечает лишь на первый вопрос.