Сколько обновляются DNS и как ускорить обновление
Вы поменяли DNS-запись — перенесли сайт на новый сервер, сменили почтовый сервис, подключили домен к Cloudflare, — и теперь у одних открывается новый сайт, а у других старый. Хостинги обычно отвечают: «обновление DNS занимает 24–48 часов». На деле всё зависит от того, что именно вы меняли, и от одного числа, которым вы управляете сами, — TTL. При небольшой подготовке обычная смена записи занимает минуты, а не сутки.
Что на самом деле называют «обновлением DNS»
По интернету ничего не рассылается. Когда вы сохраняете запись, авторитетные серверы имён вашего DNS-провайдера начинают отдавать новое значение почти сразу. Задержка возникает из-за кэшей. Каждый резолвер, который уже обращался к вашему домену, — DNS провайдера, Google Public DNS, Cloudflare 1.1.1.1, роутер в офисе, операционная система, браузер — хранит старый ответ, пока не истечёт срок его копии, и только потом спрашивает снова. «Ждать обновления DNS» на деле значит ждать, пока эти кэши устареют. По-английски это называют DNS propagation — «распространение».
TTL — число, которое задаёт ожидание
У каждой DNS-записи есть TTL (time to live, время жизни) в секундах. Он говорит резолверам, сколько можно хранить ответ. Запись с TTL 3600 может отдаваться из кэша до часа после получения, с TTL 86400 — до суток.
| TTL | Сколько может жить старый ответ | Где встречается |
|---|---|---|
| 60–300 | 1–5 минут | Записи, подготовленные к переезду, балансировка, проксируемые записи Cloudflare |
| 3600 | До часа | Частое значение по умолчанию у регистраторов и хостингов |
| 14400–86400 | 4–24 часа | MX, TXT и старые зоны, которые давно никто не трогал |
| 172800 | До 2 суток | Делегирование NS в зонах .com, .net и многих других |
Подвох в том, что резолверы держат старый TTL, а не новый. Если у записи был TTL 86400 и вы снизили его до 300 одновременно со сменой IP, резолвер, получивший запись вчера, будет хранить старое значение — со старым сроком в сутки, — пока тот не истечёт. О новом TTL он узнает только при следующем запросе.
Почему «24–48 часов» — лишь эмпирическое правило
Эта цифра — худший случай. Делегирование серверов имён в популярных зонах вроде .com публикуется с TTL в двое суток, а записи с длинным TTL держатся в кэше сутки. Добавьте резолверы, которые навязывают свой минимальный срок кэширования или отдают просроченный ответ, когда не могут достучаться до ваших серверов, — и «до 48 часов» стало безопасной формулировкой для поддержки. При обычной смене записи A с TTL 300–3600 секунд большая часть интернета, как правило, видит новое значение в пределах от нескольких минут до часа. Точное время для каждой сети не пообещает никто: часть резолверов соблюдает TTL нестрого.
Смена записи и смена серверов имён — разные вещи
Это две разные операции, и обновляются они по-разному.
- Смена записи (A, AAAA, CNAME, MX, TXT) в зоне, которой вы уже пользуетесь: ждать нужно старый TTL этой записи. Его вы полностью контролируете.
- Смена серверов имён (перенос DNS к другому провайдеру, подключение домена к Cloudflare): вы меняете NS у регистратора, регистратор передаёт их в реестр доменной зоны, а резолверы, уже знающие старое делегирование, держат его до истечения TTL записей NS в родительской зоне — для .com это до двух суток. Этот TTL вы не контролируете.
Безопасный способ сменить серверы имён — сделать зону одинаковой у обоих провайдеров до переключения: перенести все записи A, AAAA, CNAME, MX и TXT (включая SPF, DKIM и строки подтверждения сайта), сменить NS у регистратора и не удалять старую зону хотя бы двое суток. Тогда неважно, к какому провайдеру обратится резолвер, — ответ будет правильным. Если включён DNSSEC, планируйте смену записи DS по инструкциям обоих провайдеров: DS, не совпадающая с ключами нового провайдера, ломает домен для валидирующих резолверов.
Негативное кэширование: «не найдено» тоже кэшируется
Если кто-то запросил new.example.com до того, как вы создали запись, резолверы закэшировали ответ «не существует» (NXDOMAIN). Сколько его хранить, определяет запись SOA зоны — берётся меньшее из TTL самой SOA и её поля minimum. Поэтому сначала создавайте записи, а потом проверяйте: запрос имени «посмотреть, заработало ли» до его создания может заставить ждать дольше.
Как ускорить: заранее снизить TTL
- За сутки или раньше до смены снизьте TTL записей, которые собираетесь менять (например, A и AAAA), до 300 секунд.
- Переждите старый TTL. Убедитесь, что публичные резолверы больше не показывают для этих записей TTL выше 300.
- Внесите изменение. Большинство резолверов подхватит новое значение примерно за пять минут.
- Не выключайте старый сервер хотя бы сутки. Часть провайдеров и корпоративных сетей игнорирует короткие TTL и ещё какое-то время будет отправлять посетителей туда. Для почты старый сервер должен принимать письма как минимум в течение старого TTL записи MX — новые записи проверьте в проверке MX.
- Верните TTL обратно к 3600 или выше, когда всё стабилизируется: так меньше нагрузка на DNS и выше устойчивость.
Локальные кэши: очистите их, прежде чем паниковать
Часто интернет уже обновился, а отстаёт только ваш компьютер. Очистите кэши между вами и резолвером:
| Где | Команда или действие |
|---|---|
| Windows | ipconfig /flushdns в командной строке от имени администратора |
| macOS | sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder |
| Linux с systemd-resolved | resolvectl flush-caches |
| Chrome, Edge | chrome://net-internals/#dns → «Clear host cache»; затем #sockets → «Flush socket pools» |
| Firefox | about:networking#dns → «Clear DNS Cache» |
| Роутер | Перезагрузите: многие домашние роутеры держат собственный DNS-кэш |
Проверьте и файл hosts (C:\Windows\System32\drivers\etc\hosts или /etc/hosts): забытая строка в нём перекрывает любой DNS. А если браузер использует собственный «безопасный DNS», браузер и командная строка могут показывать разное. У Google Public DNS и Cloudflare 1.1.1.1 есть веб-страницы, где можно запросить обновление кэша для конкретного имени; кэш провайдера так не очистить, но можно временно переключить устройство на публичный резолвер.
Как проверить обновление DNS
Воспользуйтесь проверкой распространения DNS. Она параллельно опрашивает набор публичных резолверов DNS-over-HTTPS и авторитетные серверы имён вашей зоны. Читать результат так:
- Авторитетные серверы отдают новое значение, часть публичных резолверов — старое — всё настроено правильно, эти резолверы дожидаются конца TTL. Оставшийся TTL в каждой строке примерно показывает, сколько ещё.
- Авторитетные серверы ещё отдают старое значение — изменение не сохранилось, внесено не в ту зону или вы правите DNS у провайдера, которым домен не пользуется. Проверьте записи NS и данные регистратора в WHOIS.
- Авторитетные серверы отвечают по-разному — зона рассинхронизирована между ними, это проблема на стороне провайдера.
Из командной строки dig example.com @8.8.8.8 спрашивает один публичный резолвер, а dig example.com @ns1.your-dns-provider.com — напрямую ваш авторитетный сервер. Все записи домена разом покажет DNS Lookup, а на какой IP смотрит сайт — проверка IP по домену. Типы записей разобраны в статье проверка DNS-записей домена, а практические способы узнать адрес сайта — в статье как узнать IP-адрес сайта.