Кратко

  • Версия IP, по которой передаётся DNS-обмен, не определяет семейство адресов в запрашиваемых записях: запрос AAAA может пройти по IPv4, а запрос A — по IPv6.
  • RFC 3596 добавил 128-битную запись AAAA и обновил часть правил формирования ответа, не связывая DNS-данные с сетевым путём запроса.

IPv6 — но на каком уровне?

Представим, что резолвер отправляет DNS-вопрос внутри IPv4-пакета: «Какие записи AAAA относятся к этому имени?» Заголовок IPv4 описывает путь именно этого сообщения. Тип вопроса запрашивает данные IPv6-адреса. Противоречия нет. RFC 3596 прямо говорит: версия IP, используемая для запроса записей, независима от версии протокола в самих записях. RFC 4472 формулирует практическое следствие: AAAA можно запрашивать по IPv4, а A — по IPv6.

Эту разницу легко потерять, поскольку в обоих слоях используются слова IPv4 и IPv6. В одном случае речь идёт о сетевой оболочке запроса, в другом — о содержимом DNS-записи ресурса. Если сервер меняет ответ в зависимости от наблюдаемого транспорта, DNS-факт начинает зависеть от пути вопроса, хотя этот путь не определяет, какие адреса связаны с именем.

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

Добавить запись, не меняя путь

В ранней модели DNS запись A хранила 32-битный адрес IPv4. RFC 1886 ввёл AAAA для 128-битного адреса IPv6 и механизм обратного поиска. Затем RFC 3152 перенёс дерево обратных имён из IP6.INT в IP6.ARPA. RFC 3596 объединил эти изменения, сохранил поддержку IPv4 и определил AAAA с типом 28 как запись, содержащую полный IPv6-адрес.

Это было расширением модели данных DNS, а не созданием отдельного транспорта IPv6 для DNS-сообщений. Вопросы и ответы по-прежнему использовали существующий обмен DNS. IP-транспорт мог быть IPv4 или IPv6 независимо от того, спрашивали ли A или AAAA. Общему пространству имён не пришлось делиться на «DNS IPv4» и «DNS IPv6» только потому, что теперь в нём могли храниться адреса обоих семейств.

Существовала и другая идея. Записи A6 могли разбивать адрес на части и связывать их через DNS; при смене префикса это могло сократить некоторые обновления. Но гибкость добавляла цепочки запросов и зависимости. RFC 3363 зафиксировал решение оставить AAAA на пути стандартизации, а A6 и Bit Labels перевести в Experimental; RFC 3364 описал компромиссы. RFC 3596 выбрал полный адрес, который проще получить, но не универсальное решение перенумерации или развёртывания IPv6.

Правила ответа тоже изменились

RFC 3596 изменил обработку секции Additional для запросов NS, SRV и MX: доступные локально соответствующие адреса A и AAAA могли добавляться к ответу. Сам запрос AAAA такую обработку не запускает. Запрошенная напрямую RR и адрес, приложенный как вспомогательные данные к другому ответу, — это разные виды поведения.

Фраза «сервер может включить» не доказывает существование всех адресов. Локальных данных может не быть, кэш может быть неполным, а DNS-запись — не проверочный пакет. RFC 4472 предостерегает от выбора или фильтрации данных только по семейству транспорта: путь к DNS-серверу часто не соответствует семейству записей, нужному клиенту. Если по этой причине скрыть одно семейство, одно и то же имя может показывать разные факты в зависимости от пути запроса.

Ответ AAAA доказывает лишь то, что DNS вернул данные IPv6-адреса для имени. Он не подтверждает наличие IPv6-маршрута от этого резолвера, прослушивание сервиса на адресе, разрешение сессии межсетевым экраном, валидацию DNSSEC или подключение приложения. Получение ответа по IPv4 также не говорит, какую версию IP использует последующее соединение с сервисом.

Граница, которая прояснила сосуществование

Историю RFC 3596 часто сводят к фразе «в DNS появился AAAA». Но стандарт также сохранил инвариант при добавлении нового семейства адресов: пакет, переносящий вопрос, и семейство адресов в записи — независимые измерения. Во время перехода транспорт IPv4 мог получать данные IPv6, а IPv6 — данные IPv4, оставаясь в общем пространстве имён.

RFC определяют механизм и задуманное разделение. Они не показывают, насколько широко реализации ему следовали, как вёл себя конкретный резолвер или были ли одновременно полезны записи A и AAAA одного имени. Для этих выводов нужны отдельные свидетельства реализации, конфигурации, измерения и доступности.

Источники: RFC 1034; RFC 1035; RFC 1886; RFC 3152; RFC 3363; RFC 3364; RFC 3596; RFC 3597; RFC 4472.