IPv6 в продакшене почти всегда начинается с двух вопросов: «как правильно прописать AAAA» и «почему не работает IPv6 reverse DNS». В IPv4 всё привычно: A и PTR, обратная зона in-addr.arpa. В IPv6 логика та же, но детали (формат адреса, делегирование, длина зоны) часто ломают ожидания и затягивают диагностику.
Ниже разберём, как устроены AAAA и PTR для IPv6, почему обратная зона называется ip6.arpa, как собрать имя обратной записи из адреса, кто именно должен её создавать, и какие проверки действительно помогают быстро найти проблему.
AAAA record: что это и как его правильно публиковать
AAAA record — DNS-запись, которая сопоставляет имя хоста с IPv6-адресом. Это прямой аналог A-записи для IPv4. Если у вас dual stack (и IPv4, и IPv6), обычно публикуют и A, и AAAA для одного и того же имени.
Минимальный пример зоны
Допустим, есть домен example.com и сервер с IPv6 2001:db8:1234:5678::10.
; example.com zone
www 3600 IN AAAA 2001:db8:1234:5678::10
@ 3600 IN AAAA 2001:db8:1234:5678::10Если сайт и API живут на одном адресе, удобно дать AAAA на корень зоны (@) и на www. Если сервисов много — заводите отдельные имена (api, mail, git) и отдельные записи: так проще сопровождать и переносить.
Dual stack: как клиент выбирает между A и AAAA
Когда у имени есть и A, и AAAA, современные клиенты используют алгоритмы вроде Happy Eyeballs: пытаются быстро выбрать рабочий маршрут (IPv6 или IPv4) с минимальной задержкой. Поэтому dual stack часто повышает доступность, но при одном условии: IPv6 должен быть реально «живым».
Практически это означает: есть маршрутизация, firewall не режет нужные порты, ICMPv6 не «убит» (иначе можно поймать проблемы с PMTU), TLS-цепочка не ломается на большом пакете и т. д.
Типовые ошибки с AAAA
Опубликовали AAAA, но сервис не слушает IPv6. Например, веб-сервер слушает только
0.0.0.0:443, а[::]:443не включили. Часть клиентов пойдёт по IPv6 и получит таймаут.Firewall разрешает IPv4, но не IPv6. В nftables/iptables/UFW это разные правила. Снаружи IPv6-подключения будут висеть или сбрасываться.
Указали не тот адрес. В IPv6 легко перепутать адрес интерфейса для другого VLAN, временный адрес, или адрес, который не маршрутизируется снаружи.
Слишком длинный TTL во время миграций. Для переезда временно ставьте TTL 60–300 секунд, после стабилизации возвращайте 3600 и выше.
IPv6 reverse DNS: что такое PTR и почему это почти всегда «не вы»
IPv6 reverse DNS — обратное сопоставление: по IP-адресу получаем имя хоста через запись PTR. В IPv6 обратная зона — ip6.arpa. На практике reverse чаще всего нужен для почты (антиспам-проверки) и иногда для аудита, репутации и читаемых логов.
Ключевой момент: для публичного адреса PTR задаётся в зоне, которую контролирует владелец IP-диапазона (обычно провайдер/хостинг). В большинстве случаев вы не можете создать PTR в своей обычной DNS-зоне домена.
Как устроен ip6.arpa: нибблы и разворот
В IPv4 обратная запись строится из октетов. В IPv6 — из шестнадцатеричных цифр (нибблов). Адрес разворачивается по одной hex-цифре в обратном порядке и дополняется суффиксом ip6.arpa.
Возьмём адрес:
2001:db8:1234:5678::10Сначала раскрываем сокращение до полного вида (32 hex-цифры):
2001:0db8:1234:5678:0000:0000:0000:0010Теперь убираем двоеточия и разворачиваем каждую hex-цифру:
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.7.6.5.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpaИменно под таким именем (или под его делегированной частью) живёт PTR запись.
Если вы делегируете управление DNS под домен, заранее проверьте, кто отвечает за NS-записи и как оформляется делегирование на стороне регистратора: это экономит часы при разборе «почему не сходится авторитативность». Полезная памятка: делегирование поддомена на свои NS: типовые схемы и проверки.
Почему reverse DNS в IPv6 сложнее организационно
Потому что делегирование может происходить на разных границах префикса, а управляет обратной зоной тот, кому принадлежит адресное пространство. Типичные сценарии:
У вас выделен префикс
/64, и провайдер даёт возможность управлять PTR на уровне отдельных адресов внутри/64(панель/тикет/API).У вас
/56или/48, и провайдер готов делегировать обратную зону на ваши NS (это требует аккуратной настройки и проверки доступности DNS-серверов).У вас один IPv6-адрес на услугу, и reverse настраивается только через поддержку. Это нормальная практика для небольших выделений.
Технически всё упирается в то, кто авторитативен за соответствующую ветку ip6.arpa. Если вы не контролируете NS этой обратной зоны, вы не «впишете PTR сами» в обычной зоне домена.
Практика: как проверить AAAA и PTR для IPv6
Для диагностики удобно использовать dig: он быстро показывает, есть ли запись, какой TTL, и что говорит авторитативная сторона.
Проверяем AAAA
dig AAAA example.com +noall +answer
dig AAAA www.example.com +noall +answerЧто проверяем в первую очередь:
Есть ли ответ и корректный IPv6-адрес.
Не отдаётся ли старое значение из кеша (если нужно — сравните ответ через авторитативные NS).
Проверяем reverse (PTR)
dig -x 2001:db8:1234:5678::10 +noall +answerЕсли PTR настроен, ответ будет похож на:
10.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.7.6.5.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa. 3600 IN PTR host.example.com.Если PTR не настроен — часто будет NXDOMAIN (записи нет). Если видите SERVFAIL, это обычно не «записи нет», а проблема у авторитативной стороны или на уровне делегирования/доступности.
Проверяем согласованность forward и reverse (FCrDNS)
Хороший тон для инфраструктуры и обязательная база для почты: PTR должен указывать на имя, а это имя должно иметь AAAA (и часто A) на тот же IP.
dig -x 2001:db8:1234:5678::10 +short
dig AAAA host.example.com +shortЕсли PTR вернул host.example.com, то AAAA host.example.com должен вернуть исходный IPv6. Иначе часть систем будет считать reverse «кривым».
Делегирование обратной зоны: когда оно нужно и как не ошибиться
Если у вас много адресов и вы хотите управлять reverse самостоятельно (без панели провайдера), потребуется делегирование. Важный нюанс: граница делегирования в IPv6 чаще всего идёт по nibble-boundary (кратность 4 битам), а префиксы бывают «некратные». Отсюда появляются дополнительные схемы (вроде CNAME/DNAME-цепочек) и потенциальные ошибки.
В типичных хостинг-сценариях надёжнее и проще:
управлять PTR через панель/тикеты на уровне выданного префикса (например,
/64);или изначально брать такую схему выдачи, где провайдер поддерживает делегирование на нужной границе.
Если делегируете, обязательно проверяйте базовые вещи: NS доступны по UDP и TCP 53, отвечают и по IPv4, и по IPv6 (если заявлено), и нигде не ломается DNSSEC (например, DS опубликован, а зона не подписана).
Частые симптомы и быстрый troubleshooting
Сайт «иногда открывается, иногда нет» после добавления AAAA
Классика для dual stack: часть клиентов выбирает IPv6 и упирается в проблему на сетевом уровне или в конфигурации сервиса.
Проверьте, что сервис слушает IPv6 сокет (например,
[::]:80,[::]:443).Проверьте firewall для IPv6 и не блокируйте критичный ICMPv6 (без него легко поймать проблемы с PMTU).
Проверьте доступность порта с внешнего узла по IPv6 (не только «с самого сервера»).
dig -x даёт SERVFAIL
SERVFAIL по reverse чаще означает «резолвер не смог получить валидный ответ». Типовые причины:
битое делегирование: NS указаны, но зона фактически не обслуживается;
NS недоступны по сети или блокируется UDP/TCP 53;
ошибки DNSSEC: есть DS в родительской зоне, но подписи/ключи неверные.
Для уточнения включайте трассировку:
dig -x 2001:db8:1234:5678::10 +traceТак видно, на каком уровне ip6.arpa цепочка ответов перестаёт быть валидной.
PTR есть, но почта всё равно не проходит проверки
Reverse — лишь один из сигналов. Для почтовых сценариев обычно также нужны SPF/DKIM/DMARC, корректный HELO/EHLO и совпадение FCrDNS. Если вы поднимаете почту на IPv6, дополнительно следите за TLS: корректный сертификат и цепочка доверия часто проверяются более строго, чем кажется.
Если хотите автоматизировать выпуск и обновление сертификатов без ручных процедур и с учётом DNS, пригодится материал: Wildcard SSL и DNS-01: автоматизация и типовые ошибки.
Рекомендации по эксплуатации: чтобы IPv6 DNS не стал источником инцидентов
Не публикуйте AAAA, пока IPv6 не проверен энд-ту-энд. Маршрут, firewall, слушающие сокеты, TLS, MTU.
Держите понятный нейминг для PTR. Например,
vps-10.example.comилиedge-1.example.com. Особенно критично для почты и репутации.Следите за согласованностью. PTR → hostname и AAAA hostname → тот же IPv6 (и при необходимости A на IPv4).
Документируйте, где управляется reverse. Панель провайдера, API, делегирование на ваши NS, ответственные и сроки изменений.
Проверяйте с разных резолверов. Иногда один резолвер кеширует ошибку, попадает под ограничения или видит недоступность NS иначе, чем другие.
Шпаргалка: команды для быстрых проверок
# AAAA
dig AAAA example.com +noall +answer
dig AAAA host.example.com +noall +answer
# Reverse (PTR)
dig -x 2001:db8:1234:5678::10 +noall +answer
# Согласованность (FCrDNS)
dig -x 2001:db8:1234:5678::10 +short
dig AAAA host.example.com +short
# Трассировка делегирования ip6.arpa
dig -x 2001:db8:1234:5678::10 +traceЕсли часто переносите сервисы между серверами/провайдерами, держите под рукой чек-лист: где меняется AAAA, где настраивается PTR, какой TTL сейчас выставлен и какие резолверы уже успели закешировать старое значение.
Итоги
AAAA — запись технически простая, но в режиме dual stack она мгновенно проявляет любые проблемы с IPv6 на сервере и в сети. Reverse DNS для IPv6 (ip6.arpa) чаще всего становится не технической, а организационной задачей: PTR живёт у владельца адресного пространства, и вам нужен либо доступ к настройке у провайдера, либо корректное делегирование.
Если действовать по порядку (проверить IPv6 энд-ту-энд, затем публиковать AAAA, и отдельно согласовать PTR), IPv6 перестаёт быть «магией» и становится предсказуемой частью эксплуатации.
Если вы разворачиваете инфраструктуру под IPv6 на отдельном сервере, удобнее всего тестировать и отлаживать это на VDS, чтобы иметь полный контроль над сетевыми правилами, слушающими сокетами и DNS-обвязкой.
