DNS на практике: кэш, TTL и «сменил адрес, а открывается старое»

В прошлой части DNS работал как часы: три перехода, ответ, кэш. На практике с ним связана добрая половина вопросов «почему у меня открывается, а у коллеги нет». Почти всегда виноват не сбой, а кэш, запись «на всё» или зона, которую забыли создать. Разберём на примерах, каждый можно повторить у себя.

Это третья часть цикла «Что происходит, когда открываешь сайт».

«Сменил адрес, а открывается старый сервер»

Ответ с TTL 300 резолвер держит 5 минут — но отсчёт у каждого резолвера свой, с того момента, когда он спросил. Видно, как таймер тикает:

$ dig alekseychikun.ru A +noall +answer @8.8.8.8
alekseychikun.ru.   300  IN  A  203.0.113.22
$ sleep 3; dig alekseychikun.ru A +noall +answer @8.8.8.8
alekseychikun.ru.   297  IN  A  203.0.113.22

Кэшей на пути несколько, и каждый живёт по своим правилам:

• резолвер провайдера или публичный — по TTL, но некоторые провайдеры держат дольше, чем просят;
• операционная система — в Windows смотреть ipconfig /displaydns, сбросить ipconfig /flushdns;
• браузер — у Chrome свой кэш, сбросить на странице chrome://net-internals/#dns;
• уже открытые соединения — браузер не спрашивает DNS снова, пока жив keep-alive к старому адресу.

Поэтому «у меня уже новый сайт, а у коллеги старый» в первые минуты после переключения — нормальная картина. Если не хочется ждать, проверяйте не браузером, а прямым вопросом к серверам домена: dig example.ru A @ns1.ваш-dns. Они отвечают без кэша.

Отрицательный ответ тоже кэшируется

Спросите несуществующее имя — придёт NXDOMAIN, «такого нет». К нему приложена запись SOA зоны, и её последнее поле говорит, сколько помнить отказ:

$ dig net-takogo-domena-31337.ru A @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
ru.  3600  IN  SOA  a.dns.ripn.net. hostmaster.ripn.net. 4070741 86400 14400 2592000 3600

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

NOERROR, но пустой: запись нужного типа отсутствует

$ dig alekseychikun.ru AAAA @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1

Имя есть, IPv6-адреса нет — это нормально. Опасна обратная ситуация: при переезде поменяли запись A, а про AAAA забыли. У посетителей с IPv6 браузер пойдёт по старому адресу на старый сервер, и вы будете искать ошибку, которая воспроизводится «только у некоторых». Переезжая, смотрите все записи имени, а не одну.

Запись «на всё»: любое имя — ваш сервер

Запись *.example.ru отвечает на любое имя, для которого нет своей записи. Удобно: новый поддомен заводится без похода в DNS. Проверяем на этом сайте случайным именем:

$ dig zzz-proverka-12024.alekseychikun.ru A +noall +answer @1.1.1.1
zzz-proverka-12024.alekseychikun.ru. 300 IN A 203.0.113.22

Обратную сторону мы увидели в Search Console на этой неделе. Отчёт «Страницы не проиндексированы» показал адреса вида www.test1… и даже blog.blog.test1… — поддомены, которые когда-то были тестовыми копиями. Записи «на всё» хватило, чтобы любое имя, найденное поисковиком в старой ссылке, доходило до сервера. Страшного ничего: сервер отдавал на них запрет индексации, а теперь — 404. Но если сервер на любое имя отдаёт ваш сайт, поисковик увидит дубли на бесконечном числе поддоменов.

SERVFAIL: домен оплачен, а не резолвится

SERVFAIL означает, что резолвер не смог получить ответ вообще. Реальный случай: домен куплен, у регистратора указаны DNS-серверы хостинга, а саму зону на этих серверах никто не создал. Зона ru честно отправляет к ним, они отвечают «не знаем такой зоны», резолвер сдаётся. Сайт не открывается ни у кого, а Let’s Encrypt каждый день пытается продлить сертификат для этого имени и пишет в журнал прокси ошибку с тем же SERVFAIL. Лечится созданием зоны и записи A на стороне хостинга DNS.

# у кого делегирован домен
dig +trace +nodnssec example.ru NS | tail -4
# отвечает ли каждый из них за зону (должен быть флаг aa и запись A)
dig example.ru A @ns1.hosting-dns.example

DNS поверх HTTPS: браузер может спрашивать в обход системы

Современные браузеры умеют отправлять DNS-запросы не на системный резолвер, а по HTTPS на свой (DoH). Выглядит это как обычный запрос к веб-серверу:

$ curl -s -H 'accept: application/dns-json' \
    'https://cloudflare-dns.com/dns-query?name=alekseychikun.ru&type=A'
{"Status":0, …, "Answer":[{"name":"alekseychikun.ru","type":1,"TTL":300,"data":"203.0.113.22"}]}

Для приватности это хорошо: провайдер не видит, какие имена вы спрашиваете. Для отладки — ловушка. Прописали адрес в файл hosts или подняли свой DNS для тестового стенда, а браузер с включённым DoH их не видит: curl открывает тестовый сервер, браузер — боевой. Проверьте настройку «Использовать безопасный DNS», прежде чем искать ошибку на сервере.

Короткая шпаргалка

Симптом	Скорее всего	Проверка
у одних новый сайт, у других старый	кэш на пути, TTL	dig @сервер-домена против dig @8.8.8.8
новый поддомен «не существует» ещё час	закэширован NXDOMAIN	SOA зоны, последнее поле
ошибка только у некоторых	забытая AAAA	dig AAAA
поисковик нашёл странные поддомены	запись «на всё»	случайное имя через dig
не открывается ни у кого, SERVFAIL	зона не создана у хостинга DNS	dig +trace, затем прямой вопрос к NS
curl открывает одно, браузер другое	DoH мимо hosts	настройка безопасного DNS в браузере