Автор: Александр Петров

Вы поменяли DNS-запись: перенесли сайт на новый сервер, подключили домен к Cloudflare или сменили почтовый сервис. Теперь у одних пользователей открывается новая версия, у других старая, а хостинг в ответ повторяет: «обновление DNS занимает 24–48 часов». Эта фраза кажется исчерпывающей, но на деле она скрывает механику, которой можно управлять. Ответ на вопрос сколько обновляется dns зависит от того, что именно вы меняете и какое значение TTL стояло у записи до изменения. При подготовке обычная смена записи занимает минуты, а не сутки, и разница между «ждать сутки» и «переключиться за час» почти полностью определяется тем, что было сделано заранее.

Под термином «обновление DNS» обычно понимают не рассылку изменений по интернету, а процесс устаревания кэшей. Когда вы сохраняете запись в панели управления, авторитетные серверы имён вашего провайдера начинают отдавать новое значение практически сразу. Задержка возникает потому, что каждый резолвер, который уже обращался к вашему домену, хранит старый ответ. Это может быть DNS провайдера интернет-доступа, Google Public DNS, Cloudflare 1.1.1.1, роутер в офисе, операционная система или браузер. Каждый из них держит копию до истечения срока и только после этого спрашивает заново. По-английски явление называют DNS propagation, и все «ожидания» на самом деле являются ожиданием того, пока все эти копии перестанут быть актуальными.

TTL как главный регулятор скорости

У каждой DNS-записи есть TTL (time to live, время жизни) в секундах. Это число говорит резолверам, сколько времени можно отдавать ответ из кэша, не обращаясь к авторитетному серверу. Запись с TTL 3600 может храниться до часа, запись с TTL 86400 до суток, а запись с TTL 300 обновляется за пять минут. TTL задаётся в самой записи зоны, а не в общих настройках регистратора, поэтому менять его нужно именно там, где лежат записи A, AAAA, CNAME, MX или TXT.

Ключевой нюанс в том, что резолверы хранят старый TTL, а не новый. Допустим, у записи был TTL 86400, и вы одновременно со сменой IP-адреса снизили его до 300. Резолвер, который получил запись вчера, будет держать старое значение с его сроком в сутки. Он узнает о новом TTL только тогда, когда старый срок истечёт и он сделает следующий запрос. Поэтому снижать TTL непосредственно в момент переключения бесполезно: эффект наступит не раньше, чем через прежний срок жизни. Именно отсюда рекомендация снижать TTL заранее, и именно поэтому план переключения начинается не с изменения записи, а с её подготовки.

Резолверы, которые получают ответ, уменьшают отдаваемый TTL на время, прошедшее с момента кэширования. Поэтому клиент, спрашивающий домен, видит не полное значение, а остаток. Если вы запросите запись и увидите TTL 1200 при исходных 3600, это означает, что ответ лежит в кэше уже 40 минут. Такое наблюдение полезно при диагностике: по остатку TTL можно понять, когда конкретный резолвер получит новое значение.

Откуда взялись «24–48 часов» и почему это худший случай

Цифра из технической поддержки хостингов не является стандартом протокола. Она появилась как безопасная оценка для худшего сценария. Регистраторы и хостинги долгое время выставляли типовые значения TTL 86400 секунд (сутки) и 172800 секунд (двое суток), и при таких значениях кэш действительно может держаться почти два дня. К этому добавляются резолверы, которые навязывают собственный минимальный срок кэширования, и резолверы, которые при недоступности вашего сервера отдают просроченный ответ. В сумме получается, что для поддержки «до 48 часов» оказывается самой надёжной формулировкой.

Для обычной смены записи A с TTL 300–3600 секунд ситуация выглядит совсем иначе. Большая часть публичных резолверов увидит новое значение в течение нескольких минут или около часа. Оставшаяся часть интернета — это провайдеры и корпоративные сети, которые соблюдают TTL нестрого, и они могут отставать сильнее. Гарантировать точное время для каждой сети не может никто, но закономерность прозрачна: чем меньше был TTL до изменения, тем короче хвост задержки.

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

Смена записи и смена серверов имён: два разных процесса

Важно разделять два сценария, потому что контролировать их можно по-разному. Первый сценарий — изменение записи (A, AAAA, CNAME, MX, TXT) в зоне, которой вы уже пользуетесь. Здесь вы ждёте старый TTL этой конкретной записи, и он полностью находится под вашим управлением. Второй сценарий — смена серверов имён (NS), то есть перенос 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 (это описано в RFC 2308). Поэтому сначала создавайте записи, а потом проверяйте их. Если несколько раз проверять имя до его создания, вы рискуете получить негативный кэш, который будет держаться дольше, чем вам кажется.

Как снизить TTL и переключиться без простоя

Эффективная последовательность строится на заранее снижении TTL. Примерно за сутки до изменения, а лучше за время, равное исходному TTL записи, переведите записи, которые будете менять (например, A и AAAA), на значение 300 секунд. Это важно: если снизить TTL за несколько часов до переключения, старые значения с прежним сроком уже успеют закэшироваться, и их придётся ждать. Затем дождитесь истечения старого TTL, проверьте, что публичные резолверы больше не показывают для этих записей срок выше 300, и только после этого внесите изменение. Большинство резолверов подхватит новое значение примерно за пять минут. Чтобы понять, сколько обновляется dns в конкретном случае, полезно проверить текущий TTL записи через команду dig или онлайн-инструменты и сравнить его со значением, которое вы ожидаете увидеть после изменения.

• Снизьте TTL записей, которые будете менять, до 300 секунд минимум за исходный TTL до переключения.
• Убедитесь, что публичные резолверы показывают короткий TTL, а не старое длинное значение.
• Внесите изменение записи и проверьте результат через авторитетные серверы.
• Не выключайте старый сервер хотя бы сутки: часть провайдеров и корпоративных сетей игнорирует короткие TTL.
• Для почты старый сервер должен принимать письма не меньше старого TTL записи MX.
• Верните TTL к 3600 или выше, когда всё стабилизируется, чтобы снизить нагрузку на DNS и повысить устойчивость.

При смене IP-адреса стоит учесть ещё одну деталь. Если на сайте есть записи AAAA для IPv6, их нельзя оставить со старым адресом, иначе часть пользователей будет попадать на прежний сервер через IPv6, даже если IPv4 уже переключён. То же относится к CNAME-цепочкам: если основное имя указывает на промежуточное, менять нужно оба звена, а не только то, которое видно в панели.

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

Очистка локальных кэшей, прежде чем паниковать

Нередко интернет уже обновился, а отстаёт только ваш компьютер или браузер. Очистка кэшей помогает быстро понять, где именно застрял старый ответ. На Windows используйте команду ipconfig /flushdns, на macOS sudo dscacheutil -flushcache с последующим перезапуском mDNSResponder, в Linux зависит от службы (systemd-resolve --flush-caches или перезапуск systemd-resolved). Очистка локального кэша влияет только на ваше устройство и не затрагивает провайдерский резолвер, поэтому не стоит считать её решением для всех пользователей.

Отдельно проверьте файл hosts (C:\Windows\System32\drivers\etc\hosts в Windows или /etc/hosts в Linux и macOS). Забытая строка в нём перекрывает любой DNS и создаёт впечатление, что записи «не обновляются», хотя проблема в локальной конфигурации. Если браузер использует собственный «безопасный DNS» через DNS-over-HTTPS, браузер и командная строка могут показывать разные адреса. У Google Public DNS и Cloudflare 1.1.1.1 есть веб-страницы для очистки кэша конкретного имени, а кэш провайдера очистить извне нельзя, но можно временно переключить устройство на публичный резолвер и сравнить ответы.

Как проверить результат: инструменты и интерпретация

Надёжная проверка включает два уровня. Первый уровень — авторитетные серверы вашей зоны. Команда dig example.com @ns1.your-dns-provider.com спрашивает именно их, и если они отдают новое значение, изменение сохранено правильно. Второй уровень — публичные резолверы, которые показывают, что видит реальный пользователь. Команда dig example.com @8.8.8.8 опрашивает Google Public DNS, а nslookup позволяет сделать то же на Windows, явно указав сервер. Всегда указывайте сервер явно, иначе вы проверите собственный кэш, а не состояние зоны.

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

Полную картину записей домена удобно собрать одним запросом, а затем проверить, на какой адрес указывает сайт. Так вы видите не только A-запись, но и почту, верификацию и остальные данные. Типам записей и практическим способам узнать адрес сайта посвящены отдельные материалы, но в контексте переключения достаточно понимать принцип: проверяйте источник, а не последствия.

Типичные ошибки при смене DNS

Первая ошибка — снижение TTL в день переключения. Старые значения уже закэшированы с прежним сроком, и ускорение не происходит. Вторая — забытые записи почты и верификации. Если при смене NS не перенесены MX, SPF или TXT-записи для сервисов, письма перестают приходить, а сервисы отключают функции из-за неподтверждённого домена. Третья — удаление старой зоны до полного распространения делегирования: резолверы, которые ещё помнят старые NS, получают пустой ответ, и сайт отваливается для части пользователей. Четвёртая — уверенность, что очистка кэша на одном устройстве даёт глобальное обновление. Она не даёт, и это проверяется только через публичные резолверы. Пятая — игнорирование IPv6-записей и CNAME-цепочек, из-за которых переключение выглядит выполненным, а часть трафика продолжает идти на старый сервер.

Общий вывод простой. Срок обновления DNS определяется не настроением провайдера и не магической цифрой «48 часов», а конкретным TTL и порядком действий. Снизьте TTL заранее, переносите зону целиком, не выключайте старый сервер раньше времени и проверяйте результат через авторитетные серверы и публичные резолверы. При такой дисциплине смена записи укладывается в минуты, а смена NS проходит без потери почты и доступности сайта. Именно подготовка, а не ожидание, определяет, сколько времени займёт переход и насколько незаметным он будет для ваших пользователей.