Сколько обновляются DNS-записи: TTL, 24–48 часов и как ускорить
Вы поменяли DNS-запись: перенесли сайт на новый сервер, сменили почтовый сервис или подключили домен к Cloudflare. Теперь одни пользователи открывают новую версию, а другие по-прежнему видят старую. Хостинг в такой ситуации обычно отвечает одной и той же фразой: «обновление DNS занимает 24–48 часов». На практике всё зависит от того, что именно вы меняли, и от одного числа, которым вы управляете сами, — TTL. Если подготовиться заранее, обычная смена записи занимает минуты, а не сутки. Разберёмся, как устроено обновление dns и где именно проходят узкие места.
Что на самом деле называют обновлением 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, а не новый. Допустим, у записи был TTL 86400, и вы снизили его до 300 секунд одновременно со сменой IP-адреса. Резолвер, который получил запись вчера, будет держать старое значение со старым сроком в сутки, пока оно не истечёт. О новом TTL он узнает только при следующем обращении, то есть когда старая копия уже перестала быть актуальной. Из этого следует простой вывод: сокращать TTL нужно заранее, а не в момент переключения.
Откуда берутся 24–48 часов и что реально влияет на задержку
Цифра «24–48 часов» — не норма стандарта, а эмпирическое правило, которое удобно озвучивать клиентам. Это худший случай, когда сошлись несколько факторов. Делегирование серверов имён в популярных зонах, например в .com, публикуется с длинным TTL, порядка двух суток. Записи с TTL в сутки и больше держатся в кэшах дольше, чем кажется. К этому добавляются резолверы, которые навязывают собственный минимальный срок кэширования и отдают просроченный ответ, если не могут связаться с вашими серверами.
Крупные публичные резолверы и провайдеры связи нередко игнорируют слишком короткий TTL. Это делается ради снижения нагрузки на собственную инфраструктуру. Поэтому при очень маленьких значениях, например 60 секунд, часть пользователей может всё равно получать старый ответ дольше ожидаемого. Практическое правило: TTL 300–3600 секунд даёт предсказуемый результат, а более короткие значения выигрывают мало и добавляют нагрузку.
Отдельная категория — отрицательное кэширование. Если кто-то запросил имя new.example.com до того, как вы создали для него запись, резолверы закэшировали ответ «такого имени не существует», то есть NXDOMAIN. Срок хранения такого ответа определяет запись SOA зоны: берётся меньшее из TTL самой SOA и её поля minimum. Поэтому не стоит проверять, заработала ли новая запись, запросами к имени, которого ещё нет: вы рискуете закэшировать «пустоту» и растянуть ожидание.
Правило, которое стоит запомнить: длительность ожидания задаёт не провайдер и не «интернет в целом», а TTL, действовавший на записи в момент, когда резолвер в последний раз её получил.
Смена записи и смена серверов имён: это разные операции
Изменение отдельной записи, например A, AAAA, CNAME или MX, в зоне, которой вы уже пользуетесь, ограничено старым TTL именно этой записи. Этот срок полностью под вашим контролем: его можно снизить заранее и быстро выйти на новое значение. Здесь всё предсказуемо.
Смена серверов имён, то есть перенос DNS к другому провайдеру или подключение домена к Cloudflare, устроена иначе. Вы меняете NS-записи у регистратора, регистратор передаёт их в реестр зоны, а резолверы, которые уже знают старое делегирование, держат его до истечения TTL записей NS в родительской зоне. Для .com это до двух суток, и этот TTL вы не контролируете. Поэтому миграция серверов имён всегда занимает больше времени, чем правка одной записи.
Безопасная схема выглядит так: до переключения сделайте зону одинаковой у обоих провайдеров. Перенесите все записи A, AAAA, CNAME, MX и TXT, включая SPF, DKIM и строки подтверждения домена для сторонних сервисов. Затем смените NS у регистратора и не удаляйте старую зону как минимум двое суток. Тогда неважно, к какому серверу обратится резолвер, потому что ответ будет правильным при любом варианте. Если на домене включён DNSSEC, запись DS нужно менять по инструкциям обоих провайдеров. DS, не совпадающая с ключами нового провайдера, ломает домен для валидирующих резолверов, и сайт пропадает целиком.
Как ускорить: план смены с заранее сниженным TTL
Самый надёжный способ сократить простой — подготовиться за сутки или раньше. Ниже порядок действий, который работает для большинства переездов.
- Зафиксируйте текущие значения TTL у всех записей, которые будете менять. Выпишите их в таблицу-памятку рядом с новыми значениями.
- За время, равное старому TTL, снизьте TTL записей A и AAAA (и других изменяемых) до 300 секунд.
- Подождите, пока публичные резолверы перестанут показывать старое значение TTL. Проверяйте это тем же способом, что и результат, — через внешние инструменты.
- Внесите изменение. Большинство резолверов подхватит новое значение в течение примерно пяти минут.
- Не выключайте старый сервер минимум сутки. Часть корпоративных сетей и провайдеров игнорирует короткий TTL и ещё некоторое время направляет посетителей на прежний адрес.
- Когда всё стабилизировалось, верните TTL к 3600 или выше. Так снижается нагрузка на DNS и повышается устойчивость к сбоям.
Для почты есть отдельное требование: старый сервер должен принимать письма как минимум в течение старого TTL записи MX. Иначе входящие сообщения, отправленные отправителями с закэшированным адресом, уйдут в никуда. Новые записи MX стоит проверить сразу после изменения, прежде чем удалять старые.
Ещё один практический совет: не путайте скорость изменения с долговечностью. Сверхкороткий TTL в стабильной зоне даёт нагрузку и не даёт выигрыша. Он оправдан только на период миграции.
Очистка локальных кэшей: проверьте себя, прежде чем паниковать
Частая ситуация: интернет уже обновился, а отстаёт только ваш компьютер или телефон. Прежде чем разбираться с провайдером, очистите кэши на своей стороне. Сначала проверьте файл hosts: C:\Windows\System32\drivers\etc\hosts в Windows или /etc/hosts в Linux и macOS. Забытая строка в нём перекрывает любой DNS-ответ, и никакая очистка кэша тут не поможет. Чтобы понять, сколько именно займёт обновление dns для конкретной записи, полезно проверять TTL в самой зоне: именно это значение задаёт, как долго каждый резолвер имеет право хранить ответ без повторного запроса к авторитетному серверу.
Далее очистите кэш DNS в операционной системе. В Windows это команда ipconfig /flushdns в командной строке от администратора. В macOS используется отдельная команда для сброса кэша mDNSResponder, а в Linux зависит от того, работает ли systemd-resolved или nscd. Браузеры хранят собственный кэш DNS, поэтому перезапустите его или очистите данные сокета. Если в браузере включён «безопасный DNS», браузер и командная строка могут показывать разные результаты, и это стоит учитывать при диагностике. Роутер тоже может держать кэш, его перезагрузка сбрасывает память.
Очистить кэш провайдера или публичного резолвера со своей стороны почти невозможно. Google Public DNS и Cloudflare 1.1.1.1 предоставляют веб-страницы, где можно запросить обновление кэша для конкретного имени, но это работает не всегда. Вместо этого разумно временно переключить устройство на публичный резолвер, если провайдер задерживает обновление. Это обходной путь, а не лечение, и после переключения обратно нужно проверить настройки.
Как проверить обновление DNS и читать результат
Самый быстрый способ понять картину целиком — проверка распространения DNS. Инструмент параллельно опрашивает набор публичных резолверов по DNS-over-HTTPS и авторитетные серверы имён вашей зоны. Так можно увидеть, какие резолверы уже отдают новое значение, а какие ещё держат старое. Для всех записей домена сразу удобно смотреть DNS Lookup, а определить, на какой IP-адрес сейчас указывает сайт, поможет проверка IP по домену.
Результаты стоит читать по сценариям. Если авторитетные серверы отдают новое значение, а часть публичных резолверов — старое, всё настроено правильно: эти резолверы дожидаются конца TTL. Оставшийся TTL в каждой строке подсказывает, сколько ещё ждать. Если даже авторитетные серверы отдают старое значение, изменение не сохранилось, внесено не в ту зону или вы правите DNS у провайдера, которым домен уже не пользуется. Тогда проверьте записи NS и данные регистратора в WHOIS. Если авторитетные серверы отвечают по-разному, зона рассинхронизирована между ними, и исправлять это придётся на стороне провайдера.
Из командной строки удобно сравнивать ответы напрямую. Команда dig example.com @8.8.8.8 спрашивает один публичный резолвер, а dig example.com @ns1.your-dns-provider.com — ваш авторитетный сервер. Если ответы расходятся, а авторитетный отдаёт правильный адрес, задержка на стороне кэша. Если совпадают и неправильные, ошибка в записи. Типы записей и их назначение подробно разобраны в материале о проверке DNS-записей домена, а практические способы узнать адрес сайта описаны в статье о том, как узнать IP-адрес сайта.
Типичные ошибки при смене DNS и как их избежать
Самая дорогая ошибка — сменить NS-серверы до переноса всех записей. В результате пропадают почта, поддомены и подтверждения доменов для сторонних сервисов, таких как рекламные кабинеты или сервисы сертификатов. Перед сменой NS сравните полный список записей в старой и новой зоне. Особенно внимательно проверьте MX, SPF, DKIM, DMARC и CAA: их забывают чаще всего, а последствия проявляются не сразу.
Вторая ошибка — ожидать мгновенного эффекта и делать выводы слишком рано. Пользователь, который открыл сайт через пять минут после изменения, может увидеть старую версию, и это не означает, что изменение не сработало. Оценивайте результат по нескольким резолверам и через время, равное TTL, а не по одной попытке. Третья распространённая проблема — правка записей у неправильного провайдера. Если регистратор и DNS-хостинг разделены, нужно понимать, какой из них сейчас отвечает за зону: это видно по NS-записям, а не по тому, где вы привыкли работать.
Наконец, не путайте проблему с TTL и проблему в конфигурации. Если после правильно выполненного переключения одни пользователи не видят сайт вовсе, а не просто видят старую версию, причина скорее в ошибке записи, в неверном SSL-сертификате на новом сервере или в незакрытом порте. TTL в таком случае ни при чём, и ожидание ничего не исправит.
Что важно подготовить до смены и что проверить после
Хорошая миграция начинается с инвентаризации. Составьте полный список записей зоны, зафиксируйте текущие TTL и подготовьте новые значения. Убедитесь, что новый сервер уже отвечает на нужные имена, даже если пользователи пока его не видят: можно проверить это напрямую по IP, минуя DNS. Заранее согласуйте окно работ, если есть почта и интеграции, которые чувствительны к задержке.
После изменения действуйте по контрольному списку. Проверьте ответы авторитетных серверов и нескольких публичных резолверов. Убедитесь, что почта принимается и отправляется, что работают поддомены и что сайт открывается по HTTPS без ошибок сертификата. Через сутки верните TTL к рабочим значениям и удалите старую зону только после того, как все проверки прошли и прошло достаточно времени на кэши.
Главный вывод простой: длительность сколько обновляется dns определяется тремя вещами — значением TTL, типом изменённой записи и тем, сменились ли серверы имён. Цифры «24–48 часов» не являются законом, это худший сценарий. Если снизить TTL заранее, перенести все записи до смены NS и не выключать старый сервер раньше времени, переход пройдёт почти незаметно для пользователей. Остальное — дисциплина проверки: сравнивайте ответы разных резолверов, очищайте локальные кэши до того, как винить провайдера, и помните, что ожидание определяет не магия DNS, а число, которое вы задали в записи.