DNS на VPS: A/AAAA, TTL и делегирование без ночной магии

Сайт «не открывается» чаще из‑за DNS, чем из‑за Nginx. Сервер жив, ss показывает 80/443, конфиг без ошибок — а браузер всё равно ведёт на старый IP, выдаёт NXDOMAIN или зависает на «не удаётся найти сервер». Ниже — рабочая цепочка от NS до server_name, проверки через dig до Certbot и типичные грабли с TTL, www и IPv6.

Базовый доступ по SSH мы разбирали в гайде по подключению, firewall и первичную настройку Ubuntu — в гайде по безопасности VPS. Здесь — как имя домена превращается в IP вашего сервера.

Цепочка: NS → A/AAAA → server_name → IP

Когда пользователь набирает example.com, браузер не «знает» ваш VPS. Сначала резолвер спрашивает корневые и TLD-серверы, кто отвечает за зону (NS), затем у этих NS запрашивает A (IPv4) и при наличии AAAA (IPv6). Только после этого клиент открывает TCP к полученному адресу и шлёт HTTP с заголовком Host / TLS SNI — а Nginx уже сопоставляет это с server_name.

Практический смысл цепочки:

1. NS определяют, где правится зона (панель регистратора, DNS хостера или сторонний DNS).
2. A/AAAA говорят, куда слать трафик.
3. Nginx server_name решает, какой сайт отдать на этом IP.
4. Если любой шаг врёт (старый A, чужой NS, catch-all без нужного имени) — симптомы похожи на «сайт упал», хотя процесс Nginx жив.

Типичная ошибка новичка: править A-запись в панели хостинга, пока NS домена всё ещё указывают на регистратора. Изменения в «не той» панели не попадают в публичный DNS. Сначала смотрите NS, потом записи.

A, AAAA, www и apex

A — IPv4-адрес сервера. AAAA — IPv6. Apex (корень зоны, example.com без www) и www.example.com — это разные имена. Браузер, закладка и сертификат Let’s Encrypt работают с конкретным именем, а не «с доменом вообще».

Минимальный набор для сайта на одном VPS:

example.com.     A     203.0.113.10
www.example.com. A     203.0.113.10

Либо apex на A, а www — CNAME на apex (удобно, если IP меняется редко и вы хотите править одну запись). На apex CNAME по стандарту не ставят рядом с другими записями зоны — для корня обычно A/AAAA.

Про IPv6:

• если у VPS есть рабочий IPv6 и Nginx слушает [::]:80 / [::]:443 — добавьте AAAA;
• если IPv6 нет или сервис на нём не поднят — не публикуйте AAAA. Часть клиентов и сетей предпочтут IPv6; при «битой» AAAA сайт будет казаться мёртвым при живом IPv4.

Проверьте с сервера и с ноутбука:

curl -4 ifconfig.me
curl -6 ifconfig.me   # может не ответить — это нормально, если IPv6 нет
ip -4 addr show
ip -6 addr show

Сверьте вывод с панелью VPS. В A/AAAA должны попасть именно те адреса, которые снаружи доступны, а не внутренний 10.x / fc00::.

Для двух имён в Nginx:

server_name example.com www.example.com;

Имеет смысл заранее решить канон: редирект www→apex или наоборот — и сразу закладывать оба имени в DNS и в Certbot. Подробнее про выпуск сертификата — в статье про SSL и Certbot.

TTL: когда низкий, когда высокий

TTL — сколько секунд резолверы имеют право кешировать ответ. Это не «скорость сайта», а скорость распространения изменений DNS.

Низкий TTL (300–600) — перед переездом, сменой IP, тестом делегирования, выпуском сертификата на новом сервере. За сутки (лучше за 24–48 часов) до смены снизьте TTL на старых записях, дождитесь истечения старого TTL, потом меняйте A/AAAA. После стабилизации можно поднять обратно.

Высокий TTL (3600–86400) — когда IP не трогаете месяцами: меньше запросов к NS, чуть быстрее повторные резолвы у клиентов. Минус — ошибка в A «залипает» на часы.

Формула переезда без ночной магии:

1. Заранее TTL = 300 на A/AAAA (и при необходимости на NS).
2. Подождать не меньше прежнего TTL.
3. Переключить записи на новый IP.
4. Проверять dig с разных резолверов, пока везде не совпадёт.
5. Только потом Certbot / смена продакшн-трафика.
6. Через несколько дней вернуть TTL повыше.

Не путайте TTL записи с «пропагацией 48 часов» из старых FAQ регистраторов. Современный DNS обновляется по TTL и по тому, кто ещё держит кеш. У части провайдеров и корпоративных резолверов кеш живёт дольше заявленного — поэтому проверка с 1.1.1.1 и 8.8.8.8 полезнее обещаний в панели.

dig до Certbot: что смотреть

Перед любым certbot --nginx убедитесь, что публичный DNS уже смотрит на ваш VPS. Иначе HTTP-01 challenge уйдёт на чужой IP.

# кто авторитетен за зону
dig NS example.com +short

# куда указывает сайт
dig A example.com +short
dig AAAA example.com +short
dig A www.example.com +short

# ответ конкретного резолвера (не «из кеша провайдера дома»)
dig @1.1.1.1 A example.com +short
dig @8.8.8.8 A example.com +short

# полный след, если что-то странное
dig example.com A +trace

Сравните с IP сервера:

curl -4 ifconfig.me
hostname -I

Если dig отдаёт старый адрес — не запускайте Certbot «на удачу». Снизьте TTL заранее, проверьте, что правите зону у актуальных NS, подождите.

Полезные флаги:

dig example.com A +noall +answer   # только ответ
dig example.com SOA +short         # серийник зоны — растёт после правок у нормальных панелей
dig -x 203.0.113.10                # PTR; для сайта обычно не критичен, для почты — да

С машины пользователя сайт может открываться «уже», а с другого провайдера — ещё нет: разный кеш. Поэтому смотрите несколько публичных резолверов, а не только браузер и ping.

Делегирование: регистратор vs DNS хостера

Два разных вопроса: где купили домен и где правите DNS.

Вариант A — DNS у регистратора. NS вида ns1.registrar.ru. A/AAAA правите в его панели. Просто для одного сайта, но API и интеграции часто беднее.

Вариант B — DNS у хостера VPS / отдельного DNS. В панели регистратора меняете только NS на те, что выдал хостер (например ns1.example-dns.net). Дальше все записи — уже у хостера. Удобно, если IP и домен в одном личном кабинете.

Вариант C — сторонний DNS (Cloudflare и аналоги). NS указывают на них; A/AAAA — в их панели. Плюсы: API, фильтры, иногда прокси. Минус: ещё один слой (прокси/оранжевое облако) легко перепутать с «чистым» A на VPS — Certbot HTTP-01 и firewall нужно понимать в связке с прокси.

Правило: записи имеют смысл только в зоне, на которую указывают текущие NS. Сменили NS — старая панель перестаёт влиять на интернет (после истечения TTL у NS).

Проверка делегирования:

dig NS example.com +short
whois example.com | grep -i "name server"

whois и dig NS должны сходиться на один набор серверов. Если в whois одни NS, а вы правите записи у других — вы смотрите не ту панель.

Перенос NS делайте в спокойное окно: скопируйте все нужные записи (A, AAAA, MX, TXT для почты и SPF/DKIM, CAA) в новую зону до смены NS, снизьте TTL, затем переключите делегирование. Иначе на часы можно потерять и сайт, и почту.

Грабли: старый A, кеш, только IPv6

Старый A после переезда. Самый частый сценарий «у меня открывается, у клиента — нет». Вы смотрите dig @1.1.1.1, клиент сидит за резолвером с длинным кешем. Лечится низким TTL заранее и ожиданием; «очистить DNS» у пользователя — сброс кеша ОС/браузера, другой DNS (1.1.1.1 / 8.8.8.8), режим инкогнито как слабая проверка.

Правили не ту зону. NS на регистраторе, A меняли у хостера (или наоборот). Симптом: панель пишет «сохранено», dig не меняется.

Только AAAA без рабочего IPv6. Happy Eyeballs в современных ОС пробует IPv6. Битая AAAA = таймауты при живом A. Решение: починить стек IPv6 на VPS и Nginx либо удалить AAAA до починки.

www без записи. Apex открывается, www — нет (или наоборот). Добавьте второе имя или редирект на уровне DNS/сервера и включите его в сертификат.

Несколько A «на всякий случай». Два A на разные машины без общего балансировщика дают лотерею: часть запросов уйдёт на сервер без сайта. Для одного VPS — один актуальный A (и при необходимости один AAAA).

Локальный /etc/hosts. На своём ноутбуке сайт «уже на новом IP», в интернете — ещё нет. Перед продакшн-проверками временно уберите тестовые строки из hosts.

DNSSEC / DS у регистратора после смены NS. Если включали DNSSEC и сменили DNS-провайдера, не обновив DS, зона может «ломаться» для валидирующих резолверов. Либо перенесите DNSSEC корректно, либо временно отключите на стороне регистратора по его инструкции.

Быстрый чек-лист, если «сайт не открывается»:

dig NS example.com +short
dig @1.1.1.1 A example.com +short
dig @8.8.8.8 A example.com +short
dig @1.1.1.1 AAAA example.com +short
curl -4 -I --connect-timeout 5 http://example.com/
curl -6 -I --connect-timeout 5 http://example.com/ || true

Если dig верный, а curl не коннектится — проблема уже в firewall, слушателе или маршрутизации, не в DNS. Если dig чужой — чините DNS, не Nginx.

Связка SSL/Certbot и Ubuntu

Certbot с HTTP-01 ходит на IP из публичного DNS. Порядок на Ubuntu обычно такой:

1. VPS выдан, известен IPv4 (и IPv6, если планируете).
2. В актуальной DNS-зоне выставлены A/AAAA на этот IP; dig с 1.1.1.1 совпадает.
3. Nginx с нужным server_name, порт 80 доступен снаружи (UFW + панель).
4. sudo certbot --nginx -d example.com -d www.example.com.
5. Проверка curl -I https://example.com и certbot renew --dry-run.

Установка пакетов (пример для Ubuntu 22.04/24.04):

sudo apt update
sudo apt install -y nginx certbot python3-certbot-nginx dnsutils
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

dnsutils даёт dig на самом сервере — удобно сверять «как видит мир» не только с ноутбука.

Если DNS ещё не сошёлся, Certbot получить challenge timeout / connection refused на чужом хосте. Не жгите лимиты Let’s Encrypt повторными попытками: сначала dig, потом выпуск. Для отладки используйте staging (--test-cert), как в гайде по SSL.

CAA-запись, если есть, должна разрешать Let’s Encrypt (0 issue "letsencrypt.org"). Лишняя CAA от прошлого владельца зоны — редкая, но обидная причина отказа в выпуске.

Время на сервере:

timedatectl status

Сильный рассинхрон ломает TLS и ACME. На нормальном Ubuntu с systemd-timesyncd обычно всё уже синхронизировано.

Чек-лист перед продакшном

1. dig NS указывает на ту панель, где вы правите записи.
2. A (и при необходимости AAAA) совпадают с IP VPS на 1.1.1.1 и 8.8.8.8.
3. www и apex оба существуют в DNS либо осознанно редиректятся.
4. Нет лишней AAAA при неготовом IPv6.
5. TTL осознанный: низкий на время миграции, выше после стабилизации.
6. Nginx server_name совпадает с именами в DNS; curl -I http://домен отвечает с вашего сервера.
7. Только после пунктов выше — Certbot и редирект на HTTPS.

Нужен сервер под сайт или бота — смотрите каталог VPS: выдача до 120 секунд после оплаты, тарифы от 360 ₽, поддержка 24/7. Дата-центр в Москве (Нагатинский), также доступна локация в Германии. На тарифах с лимитом трафика после 3 ТБ включается шейпинг до 1 Мбит/с — для типового сайта этого обычно достаточно.

FAQ

Почему у меня сайт открывается, а у коллеги — нет? Разный DNS-кеш. Сверьте dig @1.1.1.1 и dig @8.8.8.8. Если ответы разные или ещё старые — ждите TTL или снижайте его заранее при следующих переездах. Попросите коллегу сменить DNS резолвер или проверить с мобильного интернета.

Нужна ли AAAA обязательно? Нет. Добавляйте, только если IPv6 на VPS реально работает и веб-сервер слушает IPv6. Иначе лучше одна корректная A, чем «красивая» AAAA с таймаутами.

Где править DNS — у регистратора или у хостера? Там, куда указывают NS (dig NS). Смена панели без смены NS ничего не даст. Для простоты одного сайта часто оставляют DNS у регистратора; если хотите всё в одном кабинете с VPS — делегируйте NS на DNS хостера и перенесите записи заранее.

Можно ли запускать Certbot, пока dig ещё показывает старый IP? Для HTTP-01 — нет. Challenge пойдёт не на ваш сервер. Дождитесь совпадения A/AAAA с IP VPS хотя бы на нескольких публичных резолверах.

Что важнее при «сайте не открывается» — Nginx или DNS? Сначала dig и сравнение с IP сервера. Если DNS врёт, правки server_name и reload Nginx не помогут части пользователей. Если DNS верен — смотрите firewall, слушатели портов и логи веб-сервера.

TTL 300 — это плохо для продакшна? На время миграции — нормально и полезно. Постоянно держать совсем короткий TTL незачем: чуть выше нагрузка на NS и нет выигрыша, если IP не меняете. После переезда верните 3600 или больше.

Документация

• dig (BIND9)
• Let’s Encrypt — Challenge Types
• RFC 1035 — Domain names