Когда вы меняете DNS-записи (NS-серверы, A-запись, MX), изменения не применяются мгновенно. DNS-серверы по всему миру хранят кэшированные записи в течение времени, указанного в TTL.
Типичное время распространения DNS
| Тип изменения | Минимум | Обычно | Максимум |
|---|---|---|---|
| Смена NS-серверов | 30 мин | 4–8 часов | 48–72 часа |
| Изменение A-записи | 5 мин | 1–4 часа | 24 часа |
| Изменение MX-записи | 5 мин | 1–4 часа | 24 часа |
| Новая CNAME/TXT | 5 мин | 15–60 мин | 4 часа |
Почему DNS распространяется не мгновенно
Каждый DNS-сервер кэширует записи на время TTL (Time-To-Live). Пока TTL не истёк, сервер отдаёт старое значение из кэша, не запрашивая обновление у авторитетного DNS.
Проверка DNS Propagation
dig (Linux/Mac)
# Проверить A-запись
dig example.com A
# Через конкретный DNS-сервер (Google)
dig @8.8.8.8 example.com A
# Через Cloudflare DNS
dig @1.1.1.1 example.com A
# Проверить NS-серверы
dig example.com NSnslookup (Windows/Linux)
nslookup example.com 8.8.8.8Онлайн-сервисы
- dnschecker.org — проверка из 100+ точек мира
- whatsmydns.net — карта распространения
- mxtoolbox.com — проверка MX-записей
Ускорение DNS propagation
# Сбросить DNS-кэш на Windows
ipconfig /flushdns
# На macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# На Ubuntu/Debian
sudo systemd-resolve --flush-cachesЧастые сообщения об ошибках при проверке DNS
| Ответ dig/nslookup | Что означает | Что делать |
|---|---|---|
;; connection timed out; no servers could be reached | Указанный DNS-сервер недоступен или заблокирован файрволом сети | Проверить другой публичный резолвер (1.1.1.1, 8.8.8.8), убедиться что UDP/53 не заблокирован |
NXDOMAIN | Домен не существует в этой зоне — либо не зарегистрирован, либо опечатка в имени | Проверить точное написание домена, статус регистрации через whois |
SERVFAIL | Авторитетный DNS-сервер домена не отвечает корректно — ошибка в зоне или сервер недоступен | Проверить NS-серверы домена, конфигурацию зоны на стороне DNS-провайдера |
| NOERROR, но ANSWER SECTION пуст | Зона существует и отвечает, но запрошенного типа записи для этого имени нет | Проверить, что запись создана именно с нужным типом (например, ищете AAAA, а создана только A) |
Что означает NOERROR с пустым ANSWER SECTION
Это не ошибка распространения — резолвер успешно связался с авторитетным сервером домена и получил ответ «записи такого типа нет». Ждать в этом случае бесполезно: нужно создать запись, а не ждать TTL.
Когда DNS не обновится вовремя, даже если всё сделано правильно
- Резолвер интернет-провайдера кэширует записи дольше объявленного TTL — встречается у части мобильных операторов, которые округляют TTL до собственных внутренних значений
- NS-серверы старого хостинга уже отключены до истечения TTL — резолверы, которые ещё не обновили кэш, получат ошибку вместо нового значения
- Корпоративный DNS-сервер настроен с собственным принудительным TTL независимо от авторитетного ответа
- Часть публичных Wi-Fi и провайдерских DNS годами не сбрасывает кэш для «прогретых» популярных доменов — единственный обходной путь для пользователя — сменить DNS-сервер вручную на 1.1.1.1 или 8.8.8.8
Уровни DNS-кэша и их типичное время жизни
| Уровень кэша | Типичное время жизни | Как сбросить |
|---|---|---|
| Кэш браузера | Около 60 секунд у большинства современных браузеров | Перезапустить браузер или очистить кэш DNS в настройках |
| Кэш операционной системы | Равен TTL записи, но не менее нескольких секунд | ipconfig /flushdns (Windows), systemd-resolve --flush-caches (Linux) |
| Кэш резолвера интернет-провайдера | Равен TTL записи, иногда больше у крупных провайдеров | Не сбрасывается пользователем — только смена резолвера на другой (1.1.1.1, 8.8.8.8) |
| Кэш вторичных (secondary) DNS-серверов | Определяется полем Refresh в SOA-записи зоны, обычно 3600–86400 секунд | Настраивается только владельцем зоны через SOA-запись |
Полное распространение изменения завершается только когда истекли все уровни кэша одновременно — поэтому реальное время часто больше, чем один TTL, указанный в записи.
На практике удобно ориентироваться на правило: если после истечения удвоенного значения старого TTL хотя бы часть резолверов всё ещё отдаёт старую запись — проблема не в распространении, а в конфигурации (например, забыли удалить старую A-запись или NS-серверы старого хостинга уже недоступны). Такой запас в два TTL покрывает почти все случаи округления и повторной проверки на стороне резолверов, и именно его стоит закладывать в план миграции, а не единственное значение TTL из документации.