Если после изменения DNS-записей домен по-прежнему открывает старый сайт или не резолвится вовсе, чаще всего виноват не сбой регистратора, а кэширование на промежуточных резолверах — записи живут столько, сколько указано в параметре TTL, и ни один провайдер не обязан обновлять их раньше срока. Прежде чем паниковать, проверьте зону напрямую через авторитетный сервер командой dig @ns1.ваш-регистратор.ru example.com: если там данные уже новые — зона обновилась, а проблема только в кэше.
В этой статье разберём основные причины, по которым DNS-зона не обновляется или обновляется слишком медленно: от завышенного TTL и ошибок в зонном файле до неподтверждённой смены NS-серверов. Для каждой причины приведём способ проверки и безопасное решение.
Как вообще работает обновление DNS-зоны
Когда вы меняете A-запись, MX или CNAME в панели управления, изменение сначала попадает на первичный (master) DNS-сервер провайдера. Затем вторичные серверы забирают новую версию зоны по механизму zone transfer, ориентируясь на serial number в SOA-записи: если серийный номер не вырос, вторичные серверы считают зону неизменной.
Дальше в игру вступают кэширующие резолверы — серверы вашего интернет-провайдера, публичные DNS вроде 8.8.8.8 или 1.1.1.1. Они запоминают ответ на время TTL и отдают его всем клиентам, не обращаясь к авторитетному серверу повторно. Именно поэтому разные пользователи в одно и то же время могут видеть разные версии сайта.
Отдельный случай — смена NS-серверов домена. Здесь обновление идёт через родительскую зону (регистратора и реестр), и оно почти всегда занимает заметно больше времени, чем правка записей внутри уже делегированной зоны.
Причина 1: не истёк TTL записей
Самая частая причина «застрявшей» зоны — высокий TTL (Time To Live). Если у записи стоит TTL 86400 секунд, резолверы вправе хранить старое значение до суток, и никакие действия с вашей стороны не заставят чужие кэши обновиться раньше.
Проверить текущий TTL можно командой:
dig example.com A +noall +answerВо втором столбце ответа будет число — оставшееся время жизни записи в кэше того резолвера, через который вы запрашиваете. Если оно большое, остаётся ждать либо использовать обходные пути (о них ниже).
Причина 2: локальный кэш на вашем устройстве
Иногда зона давно обновилась везде, кроме вашего компьютера. Операционная система и браузер хранят собственные DNS-кэши, и они могут отдавать устаревший ответ даже после того, как резолвер провайдера получил свежие данные.
- 🔄 Windows: выполните в командной строке от администратора
ipconfig /flushdnsи перезапустите браузер. - 🍏 macOS: команда очистки кэша зависит от версии системы — сверьтесь с официальной документацией Apple для вашей версии.
- 🐧 Linux: если используется systemd-resolved, помогает
resolvectl flush-caches; при других кэширующих службах порядок иной. - 🌐 Браузер: проверьте домен в режиме инкогнито или другом браузере — это быстро отсекает влияние внутреннего кэша обозревателя.
Если после очистки кэша сайт открылся с нового адреса — зона в порядке, проблема была локальной. Если нет, идём дальше по цепочке.
Причина 3: ошибки в зонном файле и SOA-записи
Если новые данные не видны даже при прямом запросе к авторитетному серверу, вероятная причина — ошибка в самой зоне. Сервис проверки синтаксиса (например, named-checkzone для BIND или встроенные валидаторы в панелях хостеров) покажет, принял ли сервер вашу правку.
Типичные проблемы, из-за которых зона не загружается или не реплицируется:
- ⚠️ Синтаксическая ошибка — пропущенная точка в конце FQDN, неверный тип записи, конфликт CNAME с другими записями того же имени.
- 🔢 Serial не увеличился — вторичные серверы не видят причин забирать зону заново.
- 🚫 Запрещён трансфер зоны — настройки allow-transfer на первичном сервере не включают адреса вторичных.
- 🧩 Конфликт записей — например, CNAME на корне домена, что недопустимо по стандартам DNS.
⚠️ Внимание: неправильная правка зонного файла может сделать домен полностью недоступным — перестанут работать и сайт, и почта. Перед изменениями сохраните резервную копию текущей зоны, а после правки проверяйте её валидатором до применения в боевом режиме.
Причина 4: смена NS-серверов ещё не завершилась
При переносе домена на другой DNS-хостинг обновление идёт через реестр и родительскую зону. Пока glue-записи и данные о делегировании не разошлись, часть резолверов продолжает опрашивать старые NS — и получать оттуда старую версию зоны.
Проверить, какие NS видит родительская зона, можно так:
dig example.com NS +traceОбратите внимание на важный нюанс: в период смены NS записи нужно держать одинаковыми на старом и новом DNS-хостинге. Иначе часть пользователей попадёт на старую конфигурацию, а часть — на новую, и диагностика превратится в хаос.
| Симптом | Вероятная причина | Что проверить |
|---|---|---|
| Старый сайт только у вас | Локальный кэш ОС/браузера | Очистка кэша, другой браузер |
| Старые данные у части провайдеров | Не истёк TTL на резолверах | Ожидание, dig с разных резолверов |
| Новых записей нет даже на авторитетном сервере | Ошибка в зоне, правка не применилась | Валидатор зоны, serial в SOA |
| Разные NS у разных резолверов | Идёт смена делегирования | dig NS +trace, данные у регистратора |
| Домен не резолвится совсем | Критическая ошибка зоны или делегирования | Статус домена, доступность NS |
Пошаговая диагностика: что проверять и в каком порядке
Действуйте от источника к клиенту — так вы быстрее локализуете звено, где застряло обновление.
☑️ Диагностика обновления DNS-зоны
Если на первом шаге данные старые — проблема на стороне DNS-хостинга: правка не применилась или зона содержит ошибку. Если авторитетный сервер отдаёт новое, а публичные резолверы — старое, это кэш с учётом TTL, и здесь остаётся только ждать. Если публичные резолверы уже обновились, а у вас нет — чистите локальный кэш.
⚠️ Внимание: не меняйте записи повторно «для надёжности», пока не разобрались в причине. Каждая новая правка при живом кэше только запутывает картину и растягивает диагностику во времени.
Как ускорить проверку без ожидания TTL
Пропишите на своём устройстве нужное соответствие домена и IP в файле hosts — это локальный обход DNS, который не влияет на других пользователей. Не забудьте удалить запись после завершения миграции, иначе позже получите труднодиагностируемую проблему. Путь к файлу hosts различается в Windows, macOS и Linux — сверьтесь с документацией вашей ОС.
Что делать, чтобы зона обновлялась быстрее в будущем
Полностью мгновенного обновления DNS не существует — это распределённая система, построенная на кэшировании. Но влиять на скорость можно.
- ⏱️ Заранее снижайте TTL перед плановыми изменениями, затем возвращайте разумное значение.
- 🧭 Держите записи синхронными на старом и новом DNS-хостинге в период миграции.
- 🧪 Проверяйте зону валидатором после каждой правки, особенно при ручном редактировании.
- 📋 Следите за serial в SOA, если администрируете собственные DNS-серверы.
Если же сроки критичны и простой недопустим, используйте стратегию с перекрытием: поднимите сайт на новом адресе заранее, убедитесь в его работоспособности, и только потом переключайте DNS. Тогда даже медленное обновление кэшей не приведёт к простою — оба адреса будут отдавать рабочий контент.
Частые вопросы
Сколько времени обновляется DNS-зона?
Зависит от TTL записей и типа изменения. Правки внутри зоны обычно видны после истечения TTL — от нескольких минут до суток и более. Смена NS-серверов через реестр может занимать до 24–48 часов, иногда дольше.
Почему у меня сайт новый, а у коллеги — старый?
Вы используете разные резолверы с разным состоянием кэша. У одного провайдера TTL уже истёк, у другого — ещё нет. Это нормальное поведение DNS в период обновления.
Можно ли принудительно сбросить кэш у провайдера?
Нет, чужие резолверы вы не контролируете. Некоторые публичные DNS (например, Google Public DNS) имеют форму очистки кэша для конкретного домена, но на провайдерские серверы это не влияет.
Зона не обновляется даже на авторитетном сервере — что делать?
Проверьте зону валидатором на синтаксические ошибки, убедитесь, что правка сохранена и применена в панели управления, а serial в SOA увеличился. Если всё корректно, но данных нет — обращайтесь в поддержку DNS-хостинга с результатами ваших проверок.
Влияет ли смена A-записи на работу почты?
Напрямую — нет, почта зависит от MX-записей. Но если MX указывает на имя внутри того же домена (например, mail.example.com), изменение A-записи этого имени косвенно изменит и точку доставки почты. Проверяйте всю цепочку записей перед правкой.