IPv6 DNS: записи AAAA, двустековое разрешение и лучшие практики

DNS — это место, где развёртывание IPv6 живёт или умирает. Опубликуете запись AAAA до того, как IPv6-подключение заработает, и пользователи будут ждать таймаутов. Пропустите обратный DNS, и почтовые серверы отклонят ваш трафик. Неправильно настроите двустековое разрешение, и сделаете сеть медленнее, а не быстрее.

Это руководство объясняет, как работает DNS с IPv6, что ломается и как это исправить до того, как это станет проблемой.

Записи AAAA: ответ IPv6 на A-записи#

Запись AAAA (произносится «квад-эй») сопоставляет имя хоста с IPv6-адресом. Это эквивалент A-записи для IPv6, но она содержит 128-битный адрес вместо 32 бит.

Формат и структура#

example.com.    3600    IN    AAAA    2001:db8::1

Структура совпадает с A-записями: имя, TTL, класс, тип и адрес. Адрес использует стандартную IPv6-нотацию с двоеточиями и шестнадцатеричными цифрами.

Ведущие нули в каждой группе можно опустить, а последовательные группы нулей сжимаются до ::. Оба варианта валидны и идентичны:

example.com.    IN    AAAA    2001:0db8:0000:0000:0000:0000:0000:0001
example.com.    IN    AAAA    2001:db8::1

Используйте сжатый формат. Его проще читать и меньше вероятность ошибок при вводе.

Запрос AAAA-записей#

Запрашивайте AAAA-записи так же, как A-записи, просто укажите тип.

С помощью dig:

dig AAAA example.com
dig AAAA @2001:4860:4860::8888 example.com

С помощью nslookup:

nslookup -type=AAAA example.com
nslookup -type=AAAA example.com 2001:4860:4860::8888

С помощью host:

host -t AAAA example.com

Вы также можете использовать наш инструмент DNS Lookup для одновременного запроса A и AAAA записей и сравнения результатов.

AAAA против A записей#

Обе служат одной цели — переводят имена в адреса — но отличаются в ключевых аспектах:

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

Двустековое DNS-разрешение#

Большинство сетей работают в двустековом режиме: IPv4 и IPv6 работают одновременно. Когда клиент ищет имя хоста, он получает как A, так и AAAA записи. Затем операционная система решает, какую использовать.

Happy Eyeballs (RFC 8305)#

Современные операционные системы реализуют Happy Eyeballs — алгоритм, который пробует IPv4 и IPv6, но предпочитает IPv6, когда он работает. Алгоритм:

1. Запрашивает DNS для A и AAAA записей
2. Начинает подключение к IPv6-адресу первым
3. Ждёт 50-250 мс (зависит от реализации)
4. Если IPv6 ещё не подключился, запускает IPv4-подключение параллельно
5. Использует то подключение, которое завершится первым

Этот подход балансирует производительность с надёжностью. IPv6 получает приоритет, но сломанный IPv6 не задерживает подключения надолго.

Порядок разрешения#

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

Большинство Unix/Linux систем:

• Запрашивают A и AAAA одновременно или AAAA первым
• Предпочитают IPv6-адреса, если они существуют
• Контролируется через /etc/gai.conf (конфигурация getaddrinfo)

macOS:

• Запрашивает оба типа записей параллельно
• Строго реализует Happy Eyeballs
• Сильно предпочитает IPv6, когда доступен

Windows:

• Запрашивает оба типа записей
• Предпочитает IPv6 по умолчанию (настраивается через реестр)
• Реализует Happy Eyeballs начиная с Windows 8

Браузеры:

• Chrome и Firefox реализуют свой собственный Happy Eyeballs
• Не полагаются только на поведение ОС
• Могут агрессивно кешировать результаты разрешения

Когда выигрывает IPv6 (или проигрывает)#

IPv6 обычно выигрывает гонку, когда:

• IPv6-подключение нативное (не туннельное)
• IPv6-маршрутизация прямая без лишних хопов
• Пункт назначения хорошо подключён по IPv6

IPv6 проигрывает, когда:

• Он туннельный (6to4, Teredo) с добавленной задержкой
• Маршрутизация идёт более длинными путями, чем IPv4
• Сервер плохо подключён по IPv6
• Проблемы с файрволом или middlebox замедляют подключения

Тестирование двустекового поведения#

Принудительно используйте IPv4 или IPv6 для тестирования поведения:

# Принудительно IPv4
curl -4 https://example.com
 
# Принудительно IPv6
curl -6 https://example.com
 
# Позволить ОС выбрать
curl https://example.com

Сравните время ответа. Если IPv6 значительно медленнее, исследуйте проблемы маршрутизации или подключения перед широкой публикацией AAAA-записей.

DNS64 и NAT64#

DNS64 синтезирует AAAA-записи из A-записей, позволяя сетям только с IPv6 обращаться к сервисам только с IPv4. Он работает в паре с NAT64, который транслирует пакеты между IPv6 и IPv4.

Как работает DNS64#

Когда клиент только с IPv6 запрашивает имя хоста:

1. DNS64-сервер получает запрос
2. Проверяет наличие AAAA-записи
3. Если AAAA существует, возвращает её нормально
4. Если существует только A-запись, синтезирует AAAA-запись, используя специальный префикс
5. Клиент подключается к синтезированному IPv6-адресу
6. NAT64-шлюз транслирует подключение в IPv4

Известный префикс: 64:ff9b::/96#

Самый распространённый префикс DNS64 — это 64:ff9b::/96, определённый в RFC 6052. Последние 32 бита адреса встраивают IPv4-адрес.

Пример синтеза:

A-запись:    192.0.2.1
Префикс:     64:ff9b::/96
AAAA-запись: 64:ff9b::192.0.2.1
             или 64:ff9b::c000:201 (в hex)

Некоторые сети используют другие префиксы, например 2001:db8::/96 или пользовательские диапазоны. Префикс должен быть настроен одинаково на DNS64 и NAT64.

Когда вам нужен DNS64/NAT64#

DNS64 необходим для:

• Мобильных сетей только с IPv6 (распространено у T-Mobile, AT&T)
• Дата-центров только с IPv6, обращающихся к legacy IPv4-сервисам
• Тестирования поведения клиентов только с IPv6

Вам не нужен DNS64, если:

• Ваша сеть двустековая
• Все сервисы, к которым вы обращаетесь, имеют нативный IPv6
• Вы можете требовать IPv6 на всех бэкенд-сервисах

Ограничения и подводные камни#

DNS64 ломает несколько вещей:

Валидация DNSSEC не работает — синтезированная AAAA-запись не соответствует подписанной зоне. DNS64-серверы должны удалять DNSSEC-подписи, снижая безопасность.

Приложения, встраивающие IP-адреса, ломаются — если приложение получает IPv4-адрес в JSON, XML или других форматах данных, DNS64 его не транслирует. Приложение пытается подключиться к IPv4-адресу из стека только с IPv6 и падает.

Балансировщики нагрузки и CDN путаются — DNS64 заставляет всех клиентов выглядеть так, будто они приходят с адреса NAT64-шлюза. Геолокация, ограничение скорости и идентификация клиентов ломаются.

Referrals и редиректы не работают — если DNS-ответ включает IPv4-адреса в дополнительных секциях (например, NS glue records), клиенты не могут до них добраться.

Обратный DNS (PTR-записи)#

Обратный DNS сопоставляет IPv6-адрес обратно с именем хоста. Это не обязательно для подключения, но требуется для почтовых серверов и полезно для инструментов логирования и безопасности.

Зона ip6.arpa#

Обратный IPv6 DNS использует домен ip6.arpa. Каждый ниббл (4 бита, или одна шестнадцатеричная цифра) адреса становится меткой в доменном имени, записанной в обратном порядке.

Конвертация адресов в PTR-формат#

Возьмите полный несжатый IPv6-адрес, переверните его по нибблам и добавьте ip6.arpa.

Пример: 2001:db8::1

Шаг 1: Расширить до полной формы:

2001:0db8:0000:0000:0000:0000:0000:0001

Шаг 2: Выписать все нибблы:

2 0 0 1 0 d b 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1

Шаг 3: Перевернуть порядок:

1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8 b d 0 1 0 0 2

Шаг 4: Разделить точками и добавить ip6.arpa:

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

Это имя PTR-записи. Оно указывает на ваше имя хоста.

Запрос обратного DNS#

С использованием dig с автоматической конвертацией:

dig -x 2001:db8::1

Прямой запрос PTR-записи:

dig PTR 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

С использованием host:

host 2001:db8::1

Делегирование обратного DNS#

Обратные DNS-зоны делегируются вашим ISP или RIR. Если у вас есть /48, вы контролируете /48 обратного DNS-пространства. Большинство провайдеров позволяют управлять им через веб-интерфейс или позволяют запустить собственные DNS-серверы для обратной зоны.

Для меньших выделений (например, /64) некоторые ISP обрабатывают индивидуальные PTR-записи за вас. Свяжитесь с ними, указав адрес и имя хоста.

Распространённые ошибки DNS с IPv6#

Публикация AAAA без работающего IPv6#

Это ошибка номер один. Вы включаете IPv6 на сервере, создаёте AAAA-запись и предполагаете, что всё работает. Но если файрвол блокирует IPv6, маршрутизация сломана или сервер фактически не слушает на IPv6, клиенты получают таймауты.

Симптом: Медленная загрузка веб-сайта, особенно в мобильных сетях, которые предпочитают IPv6.

Исправление: Протестируйте подключение из множества внешних IPv6-сетей перед публикацией AAAA-записи. Используйте наш инструмент Ping для проверки доступности.

Забыли обратный DNS#

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

Симптом: Отклонение почты, ошибки «Reverse DNS lookup failed».

Исправление: Настройте PTR-записи для всех серверных адресов. Проверьте с помощью dig -x из нескольких мест.

Несовпадение TTL между A и AAAA#

У вашей A-записи TTL 3600 секунд, но у AAAA — 300. Когда вы обновляете DNS, клиенты получают несогласованные результаты часами.

Симптом: Некоторые клиенты разрешают старые адреса, другие — новые. Сложно диагностировать.

Исправление: Согласуйте TTL для A и AAAA записей. Они должны быть идентичными. Снизьте оба перед внесением изменений, затем поднимите обратно после.

Файрвол блокирует DNS через IPv6#

Ваш DNS-сервер имеет IPv6-адрес и AAAA-запись, но файрвол блокирует UDP и TCP порт 53 через IPv6. Клиенты не могут к нему обратиться.

Симптом: DNS-запросы не проходят от клиентов или сетей только с IPv6.

Исправление: Разрешите UDP и TCP порт 53 для IPv4 и IPv6. Протестируйте с хоста только с IPv6. Помните, что DNS через TCP обязателен, а не опционален.

Неполная конфигурация двустекового режима#

Вы настроили AAAA-записи для вашего веб-сайта, но не для CDN, почтовых серверов или API endpoints. Пользователи получают смешанные результаты.

Симптом: Основной сайт работает через IPv6, но встроенный контент, API-вызовы или почта откатываются к IPv4, теряя преимущества производительности.

Исправление: Включите IPv6 для всех сервисов в цепочке, а не только для фронтенда. Протестируйте полные workflow с клиентов только с IPv6.

Жёстко закодированные IPv4-адреса в конфигурации#

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

Симптом: Приложение падает с ошибками подключения в сетях только с IPv6.

Исправление: Используйте имена хостов, а не IP-адреса, в конфигурационных файлах. Позвольте DNS разрешать в соответствующее семейство адресов.

Лучшие практики#

Тестируйте тщательно перед публикацией#

Перед добавлением AAAA-записей в production DNS:

1. Проверьте, что сервис слушает на IPv6: netstat -an | grep :80 (или ваш порт)
2. Протестируйте с внешнего IPv6-адреса: curl -6 https://[2001:db8::1]/
3. Проверьте, что правила файрвола разрешают IPv6-трафик
4. Проверьте правильность маршрутизации с помощью traceroute6
5. Протестируйте из множества IPv6-сетей (мобильных, широкополосных, дата-центров)

Не предполагайте, что работает, потому что у ОС есть IPv6-адрес.

Согласуйте TTL для A и AAAA записей#

Установите идентичные TTL. Это сохраняет согласованность поведения кеша и упрощает обновления DNS.

example.com.    3600    IN    A       192.0.2.1
example.com.    3600    IN    AAAA    2001:db8::1

Если нужно изменить адреса, снизьте TTL за 24-48 часов до изменения, сделайте обновление, затем поднимите обратно.

Настройте обратный DNS#

Настройте PTR-записи для всех публично маршрутизируемых IPv6-адресов. Это требуется для почтовых серверов и полезно для всего остального.

Работайте с вашим ISP или RIR для делегирования обратной зоны. Синхронизируйте PTR-записи с прямым DNS — они должны совпадать.

Мониторьте оба протокола#

Отслеживайте объём DNS-запросов, время ответа и частоту ошибок отдельно для A и AAAA записей. Мониторьте разрешение как через IPv4, так и через IPv6 транспорт.

Настройте оповещения для:

• Падения AAAA-запросов, когда A-запросы проходят
• Различий во времени ответа между IPv4 и IPv6
• Внезапных падений объёма IPv6-запросов

Раздельный мониторинг ловит проблемы до жалоб пользователей.

Используйте DNS-серверы с поддержкой IPv6#

Ваши DNS-серверы должны отвечать на запросы через IPv4 и IPv6. Настройте обе семьи адресов, даже если ваша сеть ещё не полностью двустековая.

Протестируйте с клиентов только с IPv6. Удивительное количество DNS-серверов имеет AAAA-записи, но фактически не принимает запросы через IPv6.

Внедряйте DNSSEC аккуратно#

DNSSEC работает с IPv6, но DNS64 его ломает. Если вы используете DNS64 в своей сети, вы не можете валидировать DNSSEC на синтезированных записях.

Для production развёртываний проектируйте для нативного двустекового режима и избегайте DNS64, где возможно.

Связанные статьи#

• Основы IPv6 — Поймите IPv6-адресацию и чем она отличается от IPv4
• Устранение неполадок IPv6 — Диагностируйте и исправляйте распространённые проблемы подключения IPv6
• Чек-лист развёртывания IPv6 — Полное руководство по развёртыванию IPv6 в production

Часто задаваемые вопросы#