Кратко

  • Опция 23 RFC 3646 передаёт предпочтительный порядок рекурсивных серверов, а опция 24 — список поиска только для DNS; ни одна не доказывает, что хост применил значения.
  • Система управления должна раздельно фиксировать источник, локальный приоритет, установленное состояние, преобразование имени, выбранный сервер, ответ, проверку и результат приложения.

Типичная автоматизация строит короткую цепочку: Reply получен, опция распознана, задача закрыта. Но между последними двумя событиями скрыта вся операционная ответственность. Ручная настройка могла иметь приоритет. Router Advertisement мог предоставить то же значение с другим временем жизни. Резолвер мог выбрать второй адрес. Короткое имя могло превратиться в неожиданный FQDN. Ответ мог быть криптографически верным, но относиться не к тому имени.

RFC 3646 определяет OPTION_DNS_SERVERS с кодом 23: один или несколько IPv6-адресов рекурсивных серверов в порядке предпочтения клиентского резолвера. OPTION_DOMAIN_LIST с кодом 24 задаёт список доменов поиска для DNS-разрешения имён узлов и не распространяется на другие механизмы. Текстовая версия допускает обе опции только в Solicit, Advertise, Request, Renew, Rebind, Information-Request и Reply.

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

Список поиска создаёт ещё один переход состояния. Введённая приложением строка дополняется суффиксами и превращается в последовательность кандидатов. RFC 1535 и RFC 1536 описывают опасности неявного поиска и обработку имён с точками. Для доказательности нужны исходная строка, порядок суффиксов, каждый сформированный запрос и выбранный ответ, а не только итоговое имя.

RFC 3646 рекомендует требовать аутентификацию DHCP до установки списка серверов или принятия списка поиска. Это помогает отличить разрешённый источник сообщения от постороннего. Однако аутентификация не подтверждает работоспособность рекламируемого сервера и не проверяет намерение пользователя. RFC 4033 отделяет DNSSEC: данные в ошибочно выбранном домене могут иметь совершенно законную подпись. Проверка подтверждает происхождение данных под запрошенным именем, но не правильность выбора этого имени.

Локальная власть сохраняется отдельной нормой: вручную заданные DNS-параметры не следует заменять значениями DHCP. Следовательно, сетевой пакет показывает предложение, а не окончательную конфигурацию. Для вывода нужны предшествующие ручные настройки, правило приоритета, решение о принятии и последующее чтение активного состояния.

RFC 8106 добавляет автоматическую передачу рекурсивных серверов и поисковых доменов через Router Advertisement. Одинаковый адрес из DHCPv6 и RA имеет разную доказательную историю и может жить по разным таймерам. Если система схлопывает записи по значению, она теряет источник, необходимый для правильного удаления и восстановления.

RFC 3315 был исходной основой DHCPv6; его заменил RFC 8415. RFC 8504 фиксирует требования к IPv6-узлам. Нормативное требование задаёт ожидаемую способность, но не удостоверяет текущее состояние конкретного устройства.

Архитектура RFC 1034 и сообщения RFC 1035 объясняют уровень DNS. RFC 3397 даёт сопоставимый механизм списка поиска в DHCPv4. Документы объясняют возможное поведение, но фактическое действие подтверждает только наблюдение.

Реестр параметров DHCPv6 IANA закрепляет коды 23 и 24. Он подтверждает общий словарь, а не объявление, принятие, установку или исход. Запись Datatracker, страница RFC Editor, список errata и история документа ограничивают происхождение спецификации, но не доказывают её развёртывание.

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

Полная запись включает интерфейс и сеть, идентичность DHCP-сервера и аутентификацию, байты опций, ручной приоритет, решение о принятии, срок каждой записи по источнику, установленное состояние, исходное имя, кандидаты, выбранный сервер и транспорт, кэш, ответ, вердикт DNSSEC и результат приложения. Автоматизация не должна заполнять отсутствующие звенья предположениями.