Почему DNS не обновился: TTL, кеш и DNS propagation

После изменения A, AAAA, MX, CNAME или другой DNS-записи результат не всегда становится одинаковым для всех пользователей мгновенно. Один DNS-сервер уже может возвращать новое значение, а другой продолжает отвечать старым.

Это часто называют DNS propagation — «распространением DNS». Однако технически новая запись обычно не путешествует последовательно по всему интернету. Главную роль играют авторитетные DNS-серверы, TTL и кеши рекурсивных резолверов.

Разберём, почему DNS может казаться «не обновившимся», сколько реально ждать после изменения записи и как отличить обычный кеш от ошибки конфигурации.

Что такое DNS propagation

Под DNS propagation обычно понимают период после изменения DNS, когда разные пользователи и резолверы ещё могут получать разные ответы.

Упрощённо:

Старая запись:
example.com → 192.0.2.10

Изменяем:
example.com → 203.0.113.20

Часть резолверов:
203.0.113.20

Часть старых кешей:
192.0.2.10

Почему слово propagation не совсем точное

Авторитетная DNS-зона не обязана «разослать» изменение каждому DNS-серверу мира.

Обычно происходит другое:

1. владелец изменяет запись у DNS-провайдера;
2. авторитетные NS начинают отдавать новое значение;
3. рекурсивные резолверы с истёкшим кешем запрашивают его заново;
4. резолверы со старым кешем продолжают использовать прежний ответ до окончания TTL.

Что такое TTL

TTL — Time To Live — время, в течение которого DNS-ответ может храниться в кеше.

Например:

example.com.  3600  IN  A  203.0.113.20

Значение 3600 означает 3600 секунд, то есть один час.

Что происходит во время TTL

Если DNS-резолвер уже получил старый IP с TTL 3600, он может не спрашивать авторитетный сервер повторно в течение оставшегося времени кеша.

TTL начинается не в момент изменения записи

Это важный нюанс.

Разные resolver могли закешировать старую запись в разное время.

Поэтому после изменения:

Resolver A: старый кеш закончится через 2 минуты
Resolver B: через 18 минут
Resolver C: через 47 минут

Как посмотреть TTL

dig example.com A

В секции ANSWER будет видно текущее значение.

Как посмотреть только ответ

dig +noall +answer example.com A

Почему TTL в ответе уменьшается

При запросе кеширующего DNS вы можете видеть оставшееся время жизни кеша, а не исходный TTL авторитетной записи.

Как проверить авторитетный DNS

Сначала узнаём NS:

dig +short example.com NS

Затем обращаемся напрямую:

dig @ns1.example.net example.com A

Почему это важная проверка

Если авторитетный NS уже возвращает новый IP, а публичный resolver старый — проблема, вероятнее всего, связана с кешем.

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

Как сравнить несколько резолверов

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

Можно также сравнить DNS вашего провайдера и локальной системы.

Почему разные DNS дают разные ответы

Причины:

• разный остаточный TTL;
• географически распределённый DNS;
• CDN;
• split DNS;
• ошибка синхронизации NS;
• разная конфигурация зон;
• DNSSEC;
• кеширование провайдера.

Сколько ждать после изменения DNS

Правильный ответ зависит от предыдущего TTL.

Если старый TTL был 300 секунд, значительная часть обычных кешей должна обновиться намного быстрее, чем при TTL 86400 секунд.

Почему совет «жди 24–48 часов» слишком общий

Такой совет иногда помогает пользователю не паниковать, но технически он не объясняет источник задержки.

Вместо этого нужно узнать:

• старый TTL;
• новый TTL;
• что отвечает авторитетный сервер;
• что отвечают конкретные resolver.

Снижение TTL перед миграцией

Перед плановой сменой IP полезно заранее уменьшить TTL.

Например:

За сутки до миграции:
TTL 3600 → 300

После истечения старого TTL:
меняем IP

Так большинство новых запросов сможет быстрее получать новое значение.

Почему снизить TTL непосредственно перед миграцией недостаточно

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

Нужно ли оставлять очень маленький TTL навсегда

Не обязательно.

Маленький TTL увеличивает частоту DNS-запросов к авторитетной инфраструктуре. После завершения миграции значение можно вернуть к нормальному рабочему уровню.

Что такое negative caching

Кешироваться могут не только существующие ответы, но и отрицательные результаты.

Например, пользователь запросил:

new.example.com

когда записи ещё не существовало и получил NXDOMAIN.

После создания записи resolver некоторое время может продолжать помнить отрицательный ответ.

Почему новый поддомен иногда не появляется сразу

Именно negative caching способен объяснить ситуацию, когда запись уже создана на авторитетных NS, но конкретный resolver всё ещё возвращает NXDOMAIN.

DNS-кеш операционной системы

Помимо внешнего resolver кеш может существовать локально.

Поэтому два компьютера в одной сети иногда ведут себя по-разному.

Кеш браузера

Некоторые браузеры имеют собственные механизмы DNS-кеширования и могут использовать DNS over HTTPS.

Из-за этого системные команды и браузер иногда получают разные результаты.

DNS over HTTPS и propagation

Браузер с DoH может использовать другой resolver.

Например:

Система → DNS провайдера → старый IP
Браузер → DoH resolver → новый IP

VPN и DNS

VPN часто меняет DNS resolver вместе с маршрутом.

Поэтому сайт, который внезапно заработал через VPN, не обязательно был заблокирован или недоступен по сети — VPN мог просто получить другой DNS-ответ.

Проверьте файл hosts

cat /etc/hosts

Локальная запись hosts может создать впечатление, что DNS «не обновляется», хотя DNS вообще не используется.

A обновилась, а AAAA нет

Одна из самых неприятных ошибок миграции:

A    → новый сервер
AAAA → старый сервер

Пользователи IPv4 увидят новый сайт, а пользователи IPv6 могут продолжать попадать на старый.

Проверяйте A и AAAA отдельно

dig +short example.com A
dig +short example.com AAAA

Несогласованные авторитетные NS

Если домен использует несколько nameserver, они должны предоставлять согласованную зону.

dig @ns1.example.net example.com A
dig @ns2.example.net example.com A

Если один возвращает старое значение, а другой новое, проблема уже не похожа на обычный TTL.

Почему это опаснее кеша

Resolver может обратиться к разным авторитетным NS и получить разные данные. В результате проблема будет воспроизводиться хаотично даже после истечения обычных кешей.

Когда виноват CDN

DNS уже может указывать на правильную CDN-инфраструктуру, но пользователь всё ещё видит старое содержимое из HTTP-кеша CDN.

Это уже не DNS propagation.

DNS-кеш и HTTP-кеш — разные вещи

DNS cache:
домен → IP

HTTP/CDN cache:
URL → содержимое страницы

Как понять, на какой IP реально подключился curl

curl -v https://example.com/ 2>&1 | grep -i connected

Так можно сравнить фактическое соединение с DNS-ответом.

Проверка конкретного IP без изменения DNS

curl -I \
  --resolve example.com:443:203.0.113.20 \
  https://example.com/

Это особенно удобно во время миграции.

Что делать, если старый сервер уже выключен

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

При критичной миграции разумно некоторое время держать старую инфраструктуру доступной.

Почему изменение NS может занять больше времени

Смена делегирования отличается от обычного изменения A-записи.

В цепочке участвуют данные родительской зоны, NS и кеши resolver.

После смены NS проверяйте делегирование

dig example.com NS
dig +trace example.com

Что показывает dig +trace

Команда проходит цепочку DNS от корневых серверов к зоне верхнего уровня и далее к авторитетным NS домена.

Она полезна для поиска проблем делегирования.

Когда ждать бессмысленно

Не нужно ждать «48 часов», если:

• авторитетный сервер отдаёт неправильную запись;
• NS делегированы неправильно;
• один NS содержит старую зону;
• AAAA забыта;
• DNSSEC сломан;
• в hosts указан старый IP.

Как проверить propagation через NexIP

NexIP может использоваться как внешняя точка диагностики DNS.

Сравнивайте:

• A;
• AAAA;
• NS;
• CNAME;
• TTL;
• конечный IP;
• ошибки DNS.

Практический алгоритм после смены IP

1. Проверить авторитетные NS.
2. Проверить A.
3. Проверить AAAA.
4. Сравнить несколько публичных resolver.
5. Посмотреть TTL.
6. Проверить hosts.
7. Проверить DoH/VPN.
8. Проверить фактический IP соединения.
9. Отделить DNS-кеш от CDN/HTTP-кеша.

Связь с диагностикой домена

Если проблема шире обычного кеша, используйте руководство «Почему домен не открывается: пошаговая диагностика DNS».

Основы DNS

Типы записей разобраны в статье «Что такое DNS-записи».

A и AAAA

IPv4 и IPv6 в DNS подробно разобраны в статье «Чем A-запись отличается от AAAA».

Что важно запомнить

• DNS propagation в основном связан с кешами и TTL.
• Авторитетный DNS нужно проверять отдельно от recursive resolver.
• Старый TTL важнее нового сразу после изменения.
• Negative caching может сохранять NXDOMAIN.
• DoH способен давать другой ответ, чем системный DNS.
• A и AAAA обновляются независимо.
• Несогласованные NS — это не обычный propagation.
• CDN-кеш нельзя путать с DNS-кешем.
• Перед миграцией TTL желательно уменьшать заранее.
• Ждать бессмысленно, если авторитетная зона настроена неправильно.

FAQ

Сколько обычно обновляется DNS?

Это зависит прежде всего от ранее закешированного TTL и конкретного resolver. Универсального срока для всех изменений нет.

Нужно ли всегда ждать 24–48 часов?

Нет. Сначала проверьте TTL и ответы авторитетных DNS-серверов.

Почему у меня новый IP, а у друга старый?

Ваши DNS-резолверы могли получить запись в разное время и иметь разный остаточный TTL.

Можно ли очистить DNS-кеш всего интернета?

Нет. Можно очистить локальный кеш, но чужими recursive resolver вы обычно не управляете.

Почему новый поддомен всё ещё NXDOMAIN?

Возможен negative caching либо запись ещё отсутствует на авторитетных NS.

Почему сайт работает через VPN?

VPN может использовать другой DNS resolver и другой маршрут.

Как проверить, обновилась ли запись у авторитетного DNS?

dig @ns1.example.net example.com A

Как проверить разные публичные DNS?

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A