Как IPv6 стал объявлять DNS: RDNSS, DNSSL и RFC 5006, 6106, 8106

Кратко

SLAAC мог дать узлу IPv6 адрес и маршрут, но не рекурсивный DNS-резолвер, который превращает имена в сетевые назначения.
RDNSS перенёс поиск резолвера в Router Advertisements, DNSSL добавил поисковые суффиксы, а следующие RFC определили сроки действия, порядок источников и обязательный уровень поддержки.

Адрес — ещё не резолвер

У узла IPv6 могут быть действующий адрес, префикс и маршрутизатор по умолчанию, но до открытия сайта дело не дойдёт: некому рекурсивно сопоставить имя сайта с его сетевым назначением. Сеть сообщила, куда отправлять пакеты. Где задавать вопросы о доменных именах, она не указала.

Первую задачу решали Neighbor Discovery и Stateless Address Autoconfiguration. Router Advertisements переносили сведения о канале связи; SLAAC позволял узлу сформировать адрес без аренды адреса через DHCPv6. DNS настраивался отдельно. В 2007 году RFC 5006 отмечал: DHCP был единственным способом настройки DNS у IETF, находившимся на Standards Track. Для ноутбука, который переходил между беспроводными сетями, вручную менять резолвер на каждой остановке было неудобно.

RFC 5006 предложил другой путь, но присвоил ему статус Experimental: IPv6 Router Advertisement мог содержать опцию Recursive DNS Server — RDNSS. Узел получал адрес рекурсивного резолвера из того же объявления, что и настройки канала; второй обмен протоколом не требовался. Маршрутизатор всё равно нужно было настроить: RFC не учил его автоматически находить собственный DNS-сервер.

Маршрутизатор начал объявлять имена

В 2010 году RFC 6106 перевёл DNS-опции на Standards Track и добавил DNSSL — список поисковых суффиксов. RDNSS передавал адрес одного или нескольких резолверов. DNSSL давал суффиксы, которые узел мог приписать к неполному имени из запроса приложения. Один поток Router Advertisements теперь мог нести префикс, маршрутизатор, резолвер и список поиска.

DHCPv6 никуда не делся. RFC 6106 описывал DHCPv6 и RA как механизмы, которые могут сосуществовать и подходят разным сетям и конфигурациям узлов. Позже RFC 8106 предписал вести упорядоченный список DNS-сведений, полученных из нескольких Router Advertisements или через DHCP. Статический DNS, заданный пользователем, оставался отдельным выбором. Вопрос сместился к приоритету источников, а не к выбору одного победителя для всех сетей.

Потеря пакетов изменила таймер

У записей RDNSS и DNSSL есть срок действия. По его истечении узел удаляет сведения: объявление — это временная аренда параметров резолвера, а не постоянная настройка. RFC 6106 ограничил срок действия максимальным интервалом между Router Advertisements. В 2017 году RFC 8106 отметил, что прежний нижний предел — два таких интервала — мог приводить к истечению DNS-опций на каналах с высокой потерей пакетов. Новое значение по умолчанию составило три максимальных интервала.

На схеме пакетов это небольшая поправка, а в журнале инцидента — большая: адрес и маршрут могут оставаться действующими, когда запись резолвера уже исчезла. Приложение выглядит отключённым от сети, хотя узел по-прежнему способен напрямую достичь IP-адреса.

Поддержка стала требованием к IPv6

По мере развития механизма рос и уровень требований. В 2011 году RFC 6434 говорил, что реализации SHOULD поддерживать DNS-опцию RA. В 2019 году RFC 8504 установил, что узлы IPv6 MUST поддерживать её. Экспериментальный выход стал обязательной возможностью: одного адреса мало, чтобы пользоваться Интернетом на практике.

Правила источников задают реальное операционное значение этой функции. RFC 8106 рекомендует хранить упорядоченный список сведений из RA и DHCP; обычно данные DHCP идут первыми. RA, защищённый SEND, имеет приоритет над неаутентифицированным источником DHCP. Пользовательская статическая настройка DNS может иметь приоритет над объявленными значениями.

RFC подтверждают изменения в конструкции и требованиях, но не содержат официальной переписи узлов с RDNSS; поэтому число использующих его клиентов по этим документам определить нельзя.