Кратко

  • RFC 9975 строит область проверки по делегированию дочерней зоны в родительской: учитываются все имена NS и все полученные для них адреса.
  • NODATA является содержательным авторитетным ответом; отсутствие ответа требует повторов, задержки и при необходимости второй сетевой точки наблюдения.
  • При любом существенном расхождении операция отменяется целиком: родитель не создаёт, не удаляет и не изменяет затронутые записи. Согласие доказывает общий запрос, но не личность, полномочия или безопасность итогового DNSSEC-состояния.

Один сервер показывает новый ключ CDS, другой возвращает корректно подписанный NODATA. Это не обязательно атака или авария. Возможно, публикация ещё распространяется или два DNS-провайдера находятся на разных этапах перехода. Но если родитель возьмёт первый ответ, скорость доставки пакета станет источником власти.

Обычному резолверу достаточно найти пригодный ответ. Родительский агент, готовящий изменение DS, NS или glue, выполняет иную работу: превращает наблюдение в дочерней зоне в долговечное решение на верхнем уровне пространства имён. Успешное разрешение и достаточное основание для записи — разные стандарты доказательства.

RFC 9975 опубликован в мае 2026 года; его единственный автор — Peter Thomassen. Документ называет требование «правдоподобной согласованностью». Оно не обещает увидеть каждый экземпляр anycast, но задаёт воспроизводимый раунд наблюдения и запрещает выводить изменение из противоречивой части службы.

Круг опроса задаёт действующее делегирование

Агент не доверяет списку серверов, приложенному к самому сигналу. Он извлекает NS дочерней зоны из родительского делегирования, получает через валидирующий резолвер все IP-адреса каждого имени, включая доступный glue, а затем напрямую спрашивает каждый адрес.

Порядок устраняет конфликт интересов. Если запрос сам выбирает свидетелей, ошибочный или злонамеренный источник может исключить провайдера, который ещё публикует прежнее состояние. Родительское делегирование не доказывает юридическое владение, но описывает авторитетную службу, уже объявленную родителем Интернету.

Одного рекурсивного запроса к имени NS тоже недостаточно. Имя может иметь несколько адресов, ведущих к разным экземплярам и маршрутам. Один anycast-адрес из другой точки может попасть на другое оборудование. Поэтому RFC допускает дополнительную сетевую точку, если первая не получает ответа.

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

NODATA — ответ, молчание — неопределённость

NODATA означает, что сервер ответил авторитетно, но не вернул требуемый тип записи. RFC 9975 прямо включает такое состояние в сравнение. Ключ CDS/CDNSKEY на одном сервере и NODATA на другом не образуют общий запрос.

Если отбросить NODATA, изменение получит скрытое преимущество: учитываться будут только серверы, предлагающие движение, а валидная публикация без запроса исчезнет из набора доказательств.

Полное отсутствие ответа имеет иную природу. Его могут вызвать потеря пакетов, маршрут, фильтр или отказ. Агент должен повторять запрос перед тем, как признать адрес постоянно недоступным. В качестве примера документ приводит экспоненциальные интервалы 5, 10, 20 и 40 минут; конкретный график остаётся локальной политикой. Вторая точка наблюдения помогает отделить неисправность сервера от проблемы одного пути.

Бесконечное ожидание не требуется. Требуется явное правило сокращения круга свидетелей: срок, точки, эскалация и ответственный. Отсутствие доказательства не должно незаметно становиться доказательством согласия.

Расхождение означает атомарное сохранение родителя

При несовместимых ответах агент не выбирает большинство, максимальный SOA serial или минимальную задержку. Он прекращает операцию. Запланированные записи не создаются, предназначенные для удаления не удаляются, существующий набор не меняется.

Прежнее состояние не объявляется вечной истиной. Оно уже опубликовано родителем, и его последствия известны. Выбор одной из конфликтующих дочерних картин способен сломать разрешение или DNSSEC. Сохранение даёт время завершить репликацию, устранить разрыв между провайдерами либо применить аутентифицированный внеполосный процесс.

Следующая попытка формирует новый раунд запросов, а не складывает удобные ответы разных периодов. Если один ответ уже подтверждает status quo, некоторые ожидающие запросы решения можно остановить: оставшиеся либо подтвердят отсутствие изменения, либо обнаружат несогласованность — в обоих случаях записи не будет. Диагностический сбор может продолжаться.

Атомарность также запрещает применить «безопасную половину» противоречивого CSYNC. Рассматривается вся проектируемая операция.

CDS и CDNSKEY сравнивают ссылки на ключи

Правдоподобная согласованность не требует побайтового равенства пакетов. Для CDS/CDNSKEY каждый допустимый ключ, упомянутый в одном релевантном ответе, должен быть упомянут и в остальных. Наличие здесь и отсутствие там означает несогласованность.

Полное удаление набора DS тоже должно быть общим намерением. Нельзя смешать запрос удаления с другим обновлением или NODATA и назвать это промежуточной фазой. Для типов дайджеста стандарт задаёт границы сравнения. Родитель может выбирать разрешённую форму публикации, но не переопределять задним числом набор ключей, согласованно показанный дочерней зоной.

RFC 10026, подготовленный Steve Sheng и Thomassen и опубликованный как Best Current Practice в июле 2026 года, добавляет независимую проверку. Проектируемый DS должен сохранить действительный путь DNSSEC-валидации. Все серверы могут единогласно запросить технически опасное изменение. Согласованное намерение и непрерывность валидации — разные квитанции.

CSYNC допускает разные serial, но не разные решения

В CSYNC нормальная репликация создаёт разрешённые различия. Флаг immediate и битовая карта типов должны совпадать во всех полученных ответах. SOA serial могут различаться; каждый serial CSYNC оценивается вместе с SOA того же сервера. Итоговое решение — допустимо ли обновление — должно быть одинаковым.

Когда CSYNC задаёт наборы для синхронизации, например NS или адреса, релевантные RDATA должны быть равны, включая случай, когда все наборы пусты. Другие правила CSYNC, в том числе порядок обработки серверов имён и glue, продолжают действовать.

Поэтому «спросить всех» описывает лишь охват. Реализации нужна модель сравнения для каждой семьи записей, различающая допустимую вариацию, переходное состояние и противоречие, при котором изменение нельзя вывести.

Уведомление запускает проверку, а не выигрывает её

Thomassen также входит в число авторов RFC 9859. Дочерняя зона может сообщить, что состояние, связанное с CDS, изменилось, и родителю не нужно ждать периодического сканирования.

Сообщение не сокращает цепочку доказательств. Получатель запускает те же DNS-запросы и проверки, что запустил бы таймер. Доставка уведомления, охват адресов, согласованность, проверка проектируемого DS, публикация родителя и видимость после истечения кэшей — отдельные подтверждения.

Один зелёный статус «автоматизация завершена» заставил бы последнее сообщение изображать доказательство предыдущих и будущих этапов. Уведомление сокращает время обнаружения, но не расширяет полномочия запроса.

Согласованность не устанавливает право распоряжаться

Одинаковое значение на серверах не доказывает владельца домена, полномочия лица, давшего команду DNS-оператору, или отсутствие компрометации аккаунта. Существующая DNSSEC-цепочка технически аутентифицирует часть обслуживания. При начальном запуске родительского DS ещё нет, поэтому нужны подходы вроде RFC 9615. Контроль реестра, регистратора и регистранта остаётся вне сравнения RDATA.

Успешная запись родителя также не означает, что все рекурсивные резолверы уже видят её. Кэши сохраняют прежний DS или делегирование до окончания TTL. Слишком ранний следующий шаг rollover способен вызвать сбой после корректной публикации. RFC 10026 отделяет время, валидацию, откат и отчётность.

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

Авторство фиксирует вклад, а не операционный контроль

RFC Editor указывает Peter Thomassen единственным автором RFC 9975. Его открытый профиль IETF на момент проверки называет его основателем и техническим директором deSEC, управляющим директором SSE, председателем Domain Connect и секретарём DNSOP. Он также соавтор RFC 9615, RFC 9859 и RFC 10026.

Эти сведения документируют вклад в развитие стандартов. Они не означают, что Thomassen управляет всеми родительскими агентами или реестрами, сертифицирует реализации либо вызвал конкретный инцидент. RFC задаёт минимальное поведение; только эксплуатационные данные покажут, какие адреса спросили и действительно ли конфликт оставил родителя без изменений.

Граница симметрична механизму: имя автора — доказательство вклада, не власти над каждым внедрением; имя сервера в делегировании — источник свидетельства, не единоличное разрешение переписать родителя.

Настоящий результат — воспроизводимая квитанция решения

Система должна хранить родительское делегирование, задавшее охват, все адреса и происхождение glue, время и точки запросов, каждый релевантный ответ или NODATA, результаты валидации и сравнения, повторы, задержки и любое исключение как постоянно недоступного.

Затем фиксируются проектируемая разница в родителе, проверка непрерывной валидации, решение отменить или применить и фактически наблюдаемое состояние после публикации. Секретам там не место; фактам, нужным для повторения решения, — место.

Общая минимальная спецификация проста: противоречивая часть авторитетной службы не порождает вывод, меняющий делегирование. Окна повторов, точки наблюдения, каналы отчёта и допустимая политика дайджестов могут быть локальными. Работающий код должен доказать, что граница существует не только в тексте.

Источники