Кратко

  • RFC 9527 определяет три DHCPv6-опции: зарегистрированный домен Homenet, прямой Distribution Manager и обратный Distribution Manager.
  • Корректный Reply подтверждает доставку параметров, но не родительское делегирование, приём зоны, валидность DNSSEC или ответ для внешнего резолвера.
  • Для эксплуатационного вывода нужны семь связанных квитанций: конфигурация, полномочия, аутентифицированный канал, публикация, валидация, внешняя доступность и жизненный цикл.

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

Это контрольная гипотеза, а не сообщение о конкретной аварии. Она показывает границу RFC 9527: стандарт автоматизирует передачу координат, но не обещает, что публичная DNS-реальность уже изменилась.

Что содержат три опции

OPTION_REGISTERED_DOMAIN с кодом 145 несёт FQDN домашней сети. OPTION_FORWARD_DIST_MANAGER с кодом 146 задаёт FQDN прямого менеджера и поддерживаемые транспорты. OPTION_REVERSE_DIST_MANAGER с кодом 147 делает то же для обратной зоны.

Клиент запрашивает их через ORO, а настроенный сервер включает значения в Reply. Сырые байты, сервер, интерфейс, lease и время дают точное доказательство того, что было получено.

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

После Reply начинается RFC 9526

Процедура аутсорсинга описана в RFC 9526. RFC 9527 доставляет необходимые параметры, после чего HNA связывается с менеджерами и передаёт зоны. DHCPv6 и изменение DNS-состояния намеренно разделены.

В Supported Transport обязателен бит DomTLS. Он объявляет поддержку DNS и передачи зоны по взаимно аутентифицированному TLS. Это не завершённый handshake и не запись о принятом сертификате, политике доверия или serial зоны.

Поэтому безошибочный пакет может вести к устаревшей привязке абонента, выведенному endpoint, отказу после TLS, зоне без обновлённого делегирования или рассинхронизации DS и DNSKEY.

Реестр координирует значения

IANA закрепляет коды и транспортные биты. Это предотвращает разные трактовки одного числа, но не подтверждает поддержку в продукте, правильность данных ISP или наличие публичной зоны.

Нормативный текст, DHCPv6-capture, журнал менеджера и внешний DNS-ответ относятся к разным слоям. Их соединение создаёт доказательство. Замена всей цепочки первым зелёным статусом создаёт лишь символическое завершение.

Прямая и обратная зоны подчиняются разным сторонам

Оператор доступа знает делегированный префикс и естественно подходит для обратной зоны. Прямой домен может контролировать ISP, абонент или сторонний DNS-провайдер. Поэтому менеджеры разделены.

При смене префикса прямая зона может обновиться раньше обратной. При замене HNA новая зона может быть принята без удаления старой. Для каждого направления нужны свои объект, менеджер, TLS-peer, версия зоны, авторитетные серверы, подпись и наблюдаемый ответ.

Удобство концентрирует управление

В базовой модели ISP может управлять DHCPv6, обоими менеджерами и авторитетными серверами. Пользователь получает почти нулевую настройку и простой обмен оборудования. Одновременно выдача домена, аутентификация и публикация оказываются у одной стороны.

Это не доказывает злоупотребление. Это требует независимого наблюдения. Запросы из других сетей проверяют, совпадает ли внутреннее «опубликовано» с тем, что видит Интернет.

Сторонний домен добавляет регистратора, проверку владения, перенаправление и credentials. Несколько ISP могут выдать несколько доменов; RFC оставляет их обработку реализации. Поэтому failover доступа и непрерывность имени — разные решения.

Семь квитанций

Конфигурационная квитанция хранит DHCPv6-обмен, опции, сервер, интерфейс и lease. Квитанция полномочий фиксирует владельца домена, обратного префикса и ожидаемые делегирования. Канальная квитанция хранит разрешение имени, TLS-партнёра, сертификат, правило доверия и принятую транзакцию.

Публикационная квитанция содержит версию зоны, serial, серверы и время. Валидационная — DNSSEC и отрицательные ответы. Квитанция доступности выполняет запросы из независимых сетей по IPv4 и IPv6. Жизненный цикл охватывает renew, rebind, новый префикс, замену HNA, переключение ISP, rollback и удаление старого состояния.

Разделение спецификации, работающего кода и наблюдаемой реальности у Heng Lu становится практической схемой. RFC даёт общий минимум; локальные решения соединяют идентичности и провайдеров; публичный DNS показывает итог.

Чего источники не доказывают

Нет переписи внедрений, списка продуктов, названного сбоя или статистики отказов. Начальный пример — аналитический. Регистрация IANA также не доказывает поддержку конкретным устройством.

Точное утверждение звучит так: «HNA получила конфигурацию RFC 9527». Для вывода о действующем, валидном и восстанавливаемом авторитетном DNS нужны остальные квитанции.

Источники