Что такое распространение DNS и как снизить его влияние

Под распространением DNS (DNS propagation) понимают период, в течение которого часть резолверов продолжает отдавать старое значение записи после её изменения на авторитетном DNS-сервере. На самом деле ничего не рассылается: каждый резолвер хранит ответ в кеше, пока не истечёт TTL. Задержка составляет от нескольких минут до 24 или 48 часов при смене серверов имён и зависит от TTL записи до изменения, а для серверов имён ещё и от TTL делегирования в реестре. Ниже разбираем, как это работает и как снизить влияние.

Главное

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

Чем распространение DNS не является: рассылкой

Термин вводит в заблуждение. Ни один сервер не отправляет ваше изменение другим. Когда вы сохраняете правку у DNS-провайдера, авторитетный сервер имён зоны сразу начинает отдавать новое значение. Задержка возникает в другом месте, в кешах.

Когда устройство ищет адрес доменного имени, запрос проходит несколько уровней, и каждый из них может запомнить ответ:

• браузер, кеш которого обычно живёт около минуты и не всегда соблюдает TTL;
• операционная система, хранящая недавние ответы;
• рекурсивный резолвер интернет-провайдера или публичного сервиса (например, 8.8.8.8 у Google, 1.1.1.1 у Cloudflare), который обходит иерархию DNS и сохраняет результат.

Каждый резолвер применяет TTL, который авторитетный сервер сообщил ему в момент кеширования ответа. Поскольку обращались они не одновременно, их копии истекают в разное время. Запись с TTL 3600 секунд, закешированная 5 минут назад, обновится через 55 минут. Отсюда противоречивые отчёты: один видит новый сайт, другой старый, третий ошибку.

Сколько длится распространение DNS

Длительность зависит от типа изменения. TTL в одни сутки (86 400 секунд) встречается часто, а для редко меняющихся записей, например серверов имён, значения выше.

Три фактора, которые определяют задержку

TTL до изменения

Допустим, у записи TTL 86 400 секунд, и сегодня вы ставите 300. Резолвер, закешировавший её вчера, хранит старое значение до 24 часов, каким бы ни было новое: TTL в 300 секунд подействует только после обновления его копии. У CNAME каждое имя в цепочке имеет свой TTL, и самый длинный определяет общую задержку.

Делегирование в реестре

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

Резолверы, которые не следуют TTL буквально

Некоторые резолверы ограничивают или повышают TTL, а у браузеров есть собственный краткоживущий кеш. Поэтому одинаковую длительность везде гарантировать нельзя. TTL задаёт теоретическую границу, а не обещание всех кешей.

Ловушка негативного кеширования

Большинство руководств говорят о TTL записей и забывают об отрицательных ответах. Когда резолвер узнаёт, что имя не существует (ответ NXDOMAIN) или что записи нужного типа нет, он может запомнить это отсутствие. RFC 2308 устанавливает срок негативного кеша как меньшее из двух значений: TTL записи SOA зоны и её поле MINIMUM. Разумными стандарт считает сроки от одного до трёх часов и предупреждает, что значения больше суток вызывают проблемы.

Типичный сценарий: вы проверяете new.example.com до создания записи, получаете ошибку, а затем создаёте запись. Для вашего резолвера имя «не существует» до конца негативного кеша, даже если запись работает уже минуту. Как этого избежать:

• создавайте запись до того, как проверять или анонсировать имя;
• если DNS-провайдер позволяет настраивать SOA, держите умеренное поле MINIMUM;
• очистите локальный кеш, прежде чем решить, что «не работает»: Microsoft указывает, что ipconfig /flushdns удаляет в том числе отрицательные записи кеша.

Как снизить влияние при миграции

1. Запишите текущий TTL каждой затронутой записи (команды ниже). Именно он определяет задержку.
2. Снизьте TTL до 300 секунд, причём заранее, не меньше чем на срок старого TTL. При 86 400 секундах сделайте это за 24-48 часов до переключения. Проверьте минимум, который принимает ваш провайдер.
3. Подготовьте новое место назначения: сайт, почтовый сервер или CDN, отдающие тот же контент, что и старые. В переходный период должны работать оба.
4. Переключите запись, по одному изменению за раз, чтобы знать, что проверять.
5. Проверьте сначала авторитетный сервер, затем публичные резолверы.
6. Оставьте старый сервер включённым как минимум до конца самого длинного старого TTL и только потом отключайте.
7. Верните TTL обратно (3600 секунд и больше), когда всё стабильно.

При смене серверов имён сначала воссоздайте полную зону у нового провайдера (A, CNAME, MX, TXT, включая SPF и DKIM, и всё остальное), убедитесь, что она отвечает правильно, и только потом меняйте серверы имён у регистратора. Оставьте зону у прежнего провайдера включённой и идентичной на 48 часов: резолверы, помнящие старое делегирование, продолжают к ней обращаться.

Как проверить, что видит каждый резолвер

Команда dig (macOS, Linux) или nslookup (Windows) позволяет сравнить ответы авторитетного сервера и нескольких публичных резолверов.

# Значение и оставшийся TTL у публичных резолверов
dig +noall +answer example.com A @8.8.8.8
dig +noall +answer example.com A @1.1.1.1

# Серверы имён, указанные для домена
dig +short NS example.com

# Значение от авторитетного сервера (подставьте свой сервер имён)
dig +noall +answer example.com A @ns1.dns-provider.example

# Серийный номер SOA, для сравнения между серверами имён
dig +short SOA example.com @ns1.dns-provider.example
dig +short SOA example.com @ns2.dns-provider.example

# Аналог в Windows
nslookup -type=A example.com 8.8.8.8
nslookup -type=NS example.com

В ответе резолвера показываемый TTL уменьшается от запроса к запросу: это время, оставшееся до истечения его копии. Если резолвер возвращает старое значение с TTL, который продолжает убывать, а авторитетный сервер уже отдаёт новое, остаётся только ждать.

Сравните также серийный номер SOA на ваших серверах имён. Если они различаются, какой-то сервер отдаёт устаревшие данные: проблема на стороне DNS-провайдера, а не в распространении. На странице dns.google можно запросить конкретный тип записи, в том числе SOA, а руководство по устранению неполадок Google Public DNS описывает эту проверку.

Очистка кешей, которые вы контролируете

Очистка собственного кеша ничего не меняет для остальных посетителей, но показывает, что вы видите на самом деле.

# Windows (командная строка)
ipconfig /flushdns

# Современный macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux с systemd-resolved
resolvectl flush-caches

Microsoft описывает /flushdns и /displaydns на странице команды ipconfig. После этого полностью закройте браузер: у него своя краткая память.

Два публичных резолвера предлагают и очистку, полезную после смены серверов имён или для их пользователей: инструмент Flush Cache в Google Public DNS (Google советует очищать и зарегистрированный домен, и точное имя с устаревшим ответом) и очистку кеша 1.1.1.1 у Cloudflare, где выбирают домен и тип записи. Резолверы интернет-провайдеров очистить нельзя: придётся ждать истечения их копий.

Частые ошибки

• Снижать TTL в момент переключения. Это поздно: резолверы хранят копию, сделанную со старым TTL.
• Проверять имя до создания записи. Негативный кеш может затянуть ошибку.
• Менять серверы имён до воссоздания всей зоны. Забытые записи почты или поддоменов перестают работать у резолверов, которые уже обращаются к новому провайдеру.
• Слишком рано отключать старый сервер. Посетители с неистёкшим кешем попадают на сервер, который уже не отвечает.
• Считать распространение завершённым по своему компьютеру. Ваш локальный кеш не отражает остальные резолверы.
• Оставлять очень низкий TTL навсегда. Это умножает число запросов к вашим серверам имён. Верните его после миграции.

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

Сколько длится распространение DNS?

При изменении записи не дольше старого TTL: час при TTL 3600 секунд, 24 часа при 86 400. При смене серверов имён от нескольких часов до 48 часов. Большинство резолверов обновляется заметно раньше предельного срока. Остаются лишь несколько запоздавших кешей.

Можно ли ускорить распространение DNS?

Во всём интернете нет: чужие кеши принудительно не обновить. Можно снизить TTL до изменения, очистить публичные резолверы Google и Cloudflare и свои собственные кеши. Резолверы интернет-провайдеров очистить нельзя.

Какой TTL выбрать перед миграцией?

Короткий, например 300 секунд (5 минут), выставленный минимум на срок старого TTL до переключения. Когда миграция стабилизируется, верните 3600 секунд и больше: постоянно очень низкий TTL умножает количество запросов. Проверьте минимум, который принимает ваш DNS-провайдер.

Почему коллега видит новый сайт, а я нет?

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

Что происходит с моей почтой во время распространения?

Изменение записи MX подчиняется тем же правилам: в период задержки часть отправителей по-прежнему пишет на старый почтовый сервер. Оставьте его включённым до конца перехода. Если сервер недоступен, отправляющие серверы обычно хранят письма и повторяют попытки несколько дней.

Нужно ли очищать кеш компьютера?

Да, чтобы проверить, что видите вы, но для других посетителей ничего не изменится. Используйте команду вашей системы и полностью закройте браузер. Если значение всё ещё старое, копию хранит резолвер вашего интернет-провайдера.

Почему онлайн-проверки распространения показывают разные результаты?

Каждая опрашивает резолверы в разных странах, а они закешировали ответ в разное время. Смешанный результат нормален, пока TTL не истёк везде. Если отвечают по-разному сами авторитетные серверы имён, сравните их серийные номера SOA: тогда проблема в зоне, а не в распространении.