Кратко

  • RFC 10001 заменяет RFC 3901 симметричным правилом: для зоны нужны минимум два авторитетных сервера, доступных по IPv4, и два по IPv6; делегация каждой семьи независима от другой, а данные на обоих транспортных путях эквивалентны.
  • Правильные NS, A, AAAA и glue не гарантируют доставку. Фрагментация, PMTU, TCP, NAT64, forwarding и реальный слушатель образуют отдельные доказательства; успех dual-stack может скрывать отказ одной семьи.

Диагностика началась с проверки записей и быстро зашла в тупик. Родитель возвращал IPv6 glue. Дочерняя зона подтверждала тот же адрес. Сервер отвечал на короткий запрос SOA. Но запрос DNSKEY из IPv6-only-сети неизменно заканчивался ожиданием, тогда как dual-stack-монитор показывал зелёный статус благодаря повтору по IPv4.

Так возникает разрыв, который нельзя найти сравнением зон. Данные и сервис существуют, но конкретный пакет не проходит конкретный путь. Для клиента результат тот же, что при отсутствующей авторитетной службе: итеративное разрешение не завершается.

RFC 10001, опубликованный в августе 2026 года как BCP 91, рассматривает и конфигурацию, и сетевые условия. Пространство имён фактически разделяется, когда резолвер доходит по ссылкам до авторитетного набора, доступного только через неподдерживаемую или неработающую семью адресов.

Сначала всё же нужна целая делегация

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

RFC перечисляет отсутствие A/AAAA, отсутствие glue, несогласованность родителя и ребёнка, неразрешимый соседний домен и недоступного родителя. Отдельно он предупреждает: наличие адреса не означает, что на нём слушает DNS. Поэтому инвентаризация и активная проверка отвечают на разные вопросы.

Исследование 2023 года How Ready Is DNS for an IPv6-Only World? проверяло всю цепочку, а не отдельный AAAA. Оно обнаружило заметную концентрацию сломанных IPv6-делегаций у небольшого числа операторов. Проценты относятся к времени измерения, но зависимость остаётся: ошибка одного провайдера может влиять на множество зон, чьи собственные файлы не менялись.

RFC 3901 защищал другую исходную точку

RFC 3901 был опубликован в 2004 году, когда важно было не отрезать IPv4-only-хосты от новых IPv6-only-авторитетов. Он требовал хотя бы один IPv4-доступный сервер.

RFC 10001 делает правило симметричным. Зона ДОЛЖНА иметь минимум два IPv4-доступных и два IPv6-доступных авторитетных сервера. Один dual-stack-сервер учитывается по одному разу в каждой семье. Делегация IPv4 не должна зависеть от IPv6, а делегация IPv6—от IPv4. Ответы должны содержать эквивалентные данные.

Четыре адреса не обязательно означают четыре домена отказа. RFC 2182 требует учитывать топологическую и операционную разнесённость. Общая платформа, anycast, маршрут и система изменений могут обрушить все адреса одновременно.

Эквивалентность ответа тоже проверяется отдельно. Два открытых порта могут отдавать разные версии зоны, RRset или состояние DNSSEC. Нужно сравнивать SOA, отпечатки данных, авторитетность и проверку подписи.

MTU превращает достоверность в молчание

При EDNS сервер может отправить UDP-ответ больше 512 октетов. DNSKEY и другие DNSSEC-ответы часто крупнее. Если пакет превышает эффективный MTU, он фрагментируется или отбрасывается. Устройство по пути может молча удалить фрагмент, и отправитель не узнает о необходимости уменьшить размер.

TCP не устраняет проблему автоматически. Если сообщения PMTU недоступны или содержат неверный размер, согласованный MSS допускает сегменты больше реального пути. Резолвер снова видит тайм-аут, а не диагноз.

RFC 10001 следует RFC 9715 и рекомендует избегать фрагментации. Для UDP он обсуждает верхнюю границу 1400 октетов и более консервативные 1232. Для TCP соответствующие значения MSS отправителя составляют 1388 или 1220. RFC 9210 требует поддерживать TCP как fallback.

Выбор 1232 связан с минимальным IPv6 MTU 1280 после учёта заголовков, но это не измерение конкретного маршрута. NAT64 может менять эффективный размер. Фильтры могут блокировать обратную связь. Поэтому журнал должен хранить EDNS, фактический размер, фрагменты, TC, TCP-соединение, MSS, задержку и участок потери.

Меньший UDP увеличивает нагрузку TCP. RFC приводит наблюдение 3–5% соединений и требует локального мониторинга. Чужая доля не заменяет собственный план мощности.

Обходной путь может скрыть исходную семью

Рекурсивный резолвер, как правило, должен быть dual-stack. IPv6-only-развёртывание может применять NAT64 или передавать неразрешённые запросы dual-stack-резолверу; IPv4-only может использовать симметричный forwarding.

Синтезированный по PREF64 адрес не является независимым IPv6-путём. Он зависит от префикса, транслятора и IPv4-цели. RFC ссылается на RFC 9872 для безопасного обнаружения PREF64. В доказательстве нужно различать нативный, транслированный и перенаправленный результат.

IPv4-only и IPv6-only-резолверы не должны пересылать невыполнимые запросы друг другу. Если зона не разрешается ни по одной семье, возникает бесконечный цикл. Цель forwarding должна сама завершать обе семьи и не возвращать обязательство назад.

Stub-резолвер может принять лишь небольшую часть предложенных серверов и непредсказуемо отбросить остальные. Список DHCP или RA показывает предложение, но не фактический выбор клиента.

Журнал должен объяснять каждый тайм-аут

Для критической зоны нужны независимые IPv4-only- и IPv6-only-трассы: точка наблюдения, время, версия резолвера, все referrals, NS, A, AAAA, glue, соседние зависимости, авторитетный адрес, UDP/TCP, EDNS, размер, стадия тайм-аута, DNSSEC и отпечаток RRset.

Затем сохраняется выбор и результат приложения. Ответ DNS не доказывает соединение; успешное соединение не доказывает здоровье обеих DNS-семей. Если применялись NAT64 или forwarding, нужно сохранить PREF64, транслятор, исходную цель и следующего резолвера.

Технические требования IANA являются отдельной процедурой. RFC 10001 не содержит действий IANA и только предлагает рассмотреть обновление. Нельзя считать публикацию доказательством уже изменившейся регистрации.

Приоритет работающего кода Хенга Лу означает, что стандарт и запись не заменяют пакет, прошедший путь. Минимальная начальная спецификация и добровольное принятие сохраняют общий инвариант совместимости, но оставляют реализацию и последующие решения оператору.

Правильная делегация необходима. Авторитетной она становится для клиента только после доставки ответа.