Коротко. Ничего никуда не «распространяется»: на вашем авторитетном сервере запись меняется мгновенно. Ждать приходится, пока у чужих резолверов истечёт кэш старого ответа. Срок задаёт TTL, который стоял в записи в момент правки, а не «24–72 часа» из письма регистратора. Снизили TTL до 300 секунд заранее — ждёте пять минут.
Дальше по порядку: почему у вас сайт открывается со старого сервера, а у коллеги — уже с нового; откуда в письмах регистраторов взялись «двое суток»; как одной командой посмотреть, сколько ещё осталось жить старому ответу в чужом кэше; и что реально ускоряет обновление, а что — миф, который стоит вам простоя.
Почему не работает сайт после смены DNS
Симптом всегда одинаковый: вы поменяли A-запись у регистратора или в панели DNS-хостинга, открыли сайт — и видите старый сервер. Иногда старую версию видит только часть пользователей, иногда — только вы, а у всех остальных всё в порядке.
Причина не в том, что изменение «ещё не дошло». Оно уже применено: на вашем авторитетном DNS-сервере лежит новое значение, и любой, кто спросит этот сервер напрямую, получит новый адрес прямо сейчас. Проблема в посредниках.
Браузер почти никогда не спрашивает ваш авторитетный сервер. Он спрашивает резолвер — DNS-сервер провайдера, корпоративной сети или публичный вроде 8.8.8.8. Резолвер несколько минут или часов назад уже спрашивал ваш домен, получил старый ответ и положил его в кэш. Пока этот кэш не истёк, резолвер отдаёт старое значение и к вам не обращается вовсе.
Слово «пропагация» вводит в заблуждение. Никакой рассылки изменений по интернету не существует — ни один сервер не получает уведомление о том, что вы поменяли A-запись. Происходит обратное: старые копии просто протухают по таймеру, каждая в своё время. Правильнее говорить не «изменения распространяются», а «кэши истекают».
Почему у вас старый сайт, а у коллеги — новый
Вы и коллега почти наверняка ходите через разные резолверы: разные провайдеры, разные корпоративные сети, разные настройки на роутере. Каждый резолвер запросил вашу запись в свой момент времени, и его таймер истечёт в свой момент.
Даже если вы оба указали 1.1.1.1 или 8.8.8.8 — это не один сервер. Публичные резолверы работают через anycast: один и тот же IP-адрес объявлен из десятков дата-центров по миру, и запрос уходит в ближайший. Ваш запрос обслуживает узел в одном городе, запрос коллеги — в другом, и кэши у них независимые.
Это легко увидеть: два одинаковых запроса к 1.1.1.1 с интервалом в несколько секунд могут вернуть разный остаток TTL, потому что попали в разные узлы сети.
$ dig +nocmd +noall +answer @1.1.1.1 enterno.io A
enterno.io. 3600 IN A 81.163.20.249
$ sleep 3; dig +nocmd +noall +answer @1.1.1.1 enterno.io A
enterno.io. 1771 IN A 81.163.20.249Первый ответ пришёл с полным TTL 3600 — узел сходил за записью заново. Второй пришёл с остатком 1771 секунды — другой узел держал её в кэше почти полчаса. Один и тот же адрес резолвера, две разные истории кэширования.
У Cloudflare и Quad9 можно спросить, какой именно узел ответил:
$ dig +short CH TXT id.server @1.1.1.1
"ams15"
$ dig +short CH TXT id.server @9.9.9.9
"res721.qams5"Google по адресу 8.8.8.8 на этот запрос не отвечает, но принцип тот же. Вывод практический: «проверил через 8.8.8.8, всё обновилось» — не доказательство того, что обновилось у всех.
Сколько ждать обновления DNS
Верхняя граница ожидания считается так: TTL, который стоял в записи в момент, когда резолвер её закэшировал, плюс время, за которое правка доехала до всех ваших авторитетных серверов. Второе слагаемое обычно секунды или минуты; первое и определяет всё.
Худший случай — резолвер запросил запись за секунду до вашей правки. Тогда он будет отдавать старое значение ровно столько, сколько указано в TTL. Если там стояло 86400, ждать сутки. Если 300 — пять минут.
«24–72 часа» — это не стандарт и не свойство DNS. Это осторожная формулировка из шаблонных писем регистраторов: она покрывает и высокий TTL по умолчанию, и задержку публикации в зоне TLD при смене NS, и корпоративные кэши с нестандартными настройками. Как оценка сверху для самого неудачного сценария — годится. Как прогноз для вашей ситуации — бесполезна.
Ниже — что на самом деле определяет срок для каждого типа записи.
| Запись | Что задаёт срок ожидания | Типичный TTL по умолчанию | Цена ошибки |
|---|---|---|---|
| A / AAAA | TTL самой записи | 1–4 часа | Часть трафика уходит на старый сервер |
| CNAME | TTL алиаса и TTL целевой записи — истекают независимо | 1–4 часа | Ждать приходится дважды |
| MX | TTL записи; почта повторяет попытки часами | 4–24 часа | Письма уходят на выключенный сервер |
| TXT (SPF, DKIM, DMARC) | TTL записи; кэш принимающей стороны | 1–24 часа | Письма попадают в спам или отклоняются |
| NS | TTL делегирования в зоне TLD — вы им не управляете | 1–2 суток | SERVFAIL, домен недоступен целиком |
| SOA / отрицательные ответы | Поле minimum в SOA | 15 минут – 3 часа | NXDOMAIN «залипает» после создания записи |
Единственная строка, где вы не хозяин положения, — NS. TTL делегирования назначает зона верхнего уровня, а не вы. Поэтому смена NS-серверов действительно бывает долгой, и о ней ниже отдельный раздел.
Как работает DNS: цепочка от браузера до авторитетного сервера
Чтобы понимать, где именно застревает старое значение, нужно видеть весь путь запроса. Подробный разбор устройства системы — в статье что такое DNS и как он работает, здесь только то, что влияет на сроки.
- Кэш браузера — собственный короткий кэш, обычно минуты.
- Кэш операционной системы — служба резолвинга на вашей машине.
- Рекурсивный резолвер — DNS провайдера, корпоративный сервер или публичный (8.8.8.8, 1.1.1.1, 9.9.9.9). Главный источник задержки.
- Корневые серверы — 13 групп адресов, подсказывают, кто отвечает за зону
.ru,.com,.io. - Серверы зоны TLD — хранят делегирование: какие NS-серверы обслуживают ваш домен.
- Авторитетные серверы домена — здесь лежат реальные записи. Здесь ваша правка появляется сразу.
Кэшировать может каждый уровень. Именно поэтому изменение выглядит «постепенным»: оно не движется по сети, просто разные кэши освобождаются в разное время.
Как отличить кэшированный ответ от авторитетного
В ответе авторитетного сервера стоит флаг aa (authoritative answer). У резолвера его нет. Это самая надёжная проверка «изменилось ли на самом деле»:
$ dig +norecurse @dns1.yandex.net enterno.io A
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1Флаг aa на месте — сервер отвечает как хозяин зоны, а не пересказывает чужой кэш. Если здесь новое значение, а у резолверов старое, значит с вашей стороны всё сделано и остаётся ждать.
TTL: что это и как он определяет срок ожидания
TTL (time to live) — число секунд, которое резолверу разрешено хранить ответ. Оно едет вместе с записью в каждом ответе. Пока счётчик не дошёл до нуля, резолвер к вам не обратится.
example.com. 3600 IN A 203.0.113.10
; ^^^^
; TTL = 3600 секунд = 1 часПолный справочник по значению каждого поля — в разборе TTL в DNS-записях. Ниже — рабочая шпаргалка, какое значение когда ставить.
| TTL | Время | Когда ставить | Обратная сторона |
|---|---|---|---|
| 60 | 1 минута | Активная авария, ручной failover | Многие резолверы всё равно поднимут до своего минимума |
| 300 | 5 минут | Окно миграции, балансировка | Больше запросов к авторитетным серверам |
| 3600 | 1 час | Рабочее значение по умолчанию | Час простоя при незапланированной правке |
| 14400 | 4 часа | Стабильные записи, которые не трогают | Полдня на откат |
| 86400 | 24 часа | Записи, которые меняются раз в год | Сутки простоя при ошибке |
| 604800 | 7 дней | Практически не нужен | Неделя без возможности откатиться |
TTL — это не «как быстро обновится», а «как долго вы не сможете откатиться». Высокий TTL наказывает не за изменение, а за ошибку в изменении. Ставьте его исходя из того, сколько простоя вы готовы терпеть, если новая запись окажется неверной.
Как посмотреть, сколько осталось до истечения кэша
TTL в ответе резолвера — это не то значение, которое вы прописали в зоне, а остаток. Он считается вниз. Запросите домен дважды с паузой: если число уменьшается — вы смотрите в кэш и видите, сколько ещё ждать.
# Остаток кэша у конкретного резолвера
dig +nocmd +noall +answer @8.8.8.8 example.com A
# Через 10 секунд — число должно уменьшиться на 10
sleep 10; dig +nocmd +noall +answer @8.8.8.8 example.com AЕсли во втором ответе TTL снова полный и равен значению из зоны — кэш только что истёк и был перезаполнен. Значит, этот резолвер уже отдаёт актуальные данные.
Как заглянуть в кэш, не наполняя его
Обычный запрос к резолверу, у которого записи нет, заставит его сходить за ней и закэшировать. Иногда это мешает: вы хотите узнать, что у него лежит сейчас, ничего не меняя. Для этого есть +norecurse:
# Отдай, что есть в кэше, но не ходи никуда за ответом
dig +norecurse +nocmd +noall +answer @8.8.8.8 example.com AПустой ответ означает, что в кэше этого узла записи нет — следующий обычный запрос пользователя приведёт к свежему обращению к вашему авторитетному серверу.
Почему кэш живёт дольше TTL: пять слоёв
Резолвер провайдера — не единственный, кто хранит ответ. Даже когда он обновился, старое значение может лежать ближе к пользователю.
| Слой | Кто им управляет | Как сбросить | Влияет на посетителей |
|---|---|---|---|
| Кэш браузера | Пользователь | Перезапуск браузера, служебная страница настроек сети | Только у него самого |
| Кэш ОС | Пользователь | Команда сброса кэша | Только у него самого |
| Роутер, корпоративный прокси, VPN | Админ сети | Перезагрузка устройства | Вся сеть офиса |
| Рекурсивный резолвер | Провайдер или публичный сервис | Только истечение TTL | Все клиенты этого резолвера |
| Делегирование в зоне TLD | Реестр домена | Только истечение TTL зоны | Все |
Строка «только истечение TTL» — ключевая. Ниже разберём, почему её нельзя обойти.
Отрицательное кэширование: NXDOMAIN залипает
Отдельный класс проблем: вы создали запись, но она «не появляется», хотя TTL маленький. Так бывает, когда кто-то запросил имя до создания записи. Резолвер получил NXDOMAIN и закэшировал сам факт отсутствия. Время хранения такого ответа задаётся не TTL записи (её ведь не было), а полем minimum в SOA-записи зоны — последним числом.
$ dig +nocmd +noall +authority nonexistent-xyz123.enterno.io A @8.8.8.8
enterno.io. 900 IN SOA dns1.yandex.net. dns-hosting.yandex.ru. 36 900 90 86400 900
; ^^ ^^^ ^^ ^^^^^ ^^^
; serial refresh retry expire minimumЗдесь minimum = 900 секунд, значит «этого имени нет» будет кэшироваться до пятнадцати минут. Правило описано в RFC 2308: срок отрицательного кэша — меньшее из minimum и собственного TTL SOA-записи.
Практический вывод: создавайте запись до того, как о ней кто-то узнает. Разослали ссылку на новый поддомен раньше, чем добавили для него A-запись, — и первые же переходы отравят кэши отрицательным ответом на четверть часа, хотя запись уже на месте.
Типы DNS-записей и их особенности при обновлении
Общий разбор синтаксиса и назначения — в справочнике по типам DNS-записей. Здесь — только то, что важно при переезде.
A и AAAA
Самый частый случай: смена хостинга. Простое правило — обе записи меняются вместе. Забытая AAAA-запись даёт классический симптом «у половины пользователей старый сайт»: у кого включён IPv6, тот идёт на старый адрес, остальные — на новый.
Проверять надо оба семейства адресов явно:
dig +short A example.com @8.8.8.8
dig +short AAAA example.com @8.8.8.8
# И то же самое для www — это отдельная запись
dig +short A www.example.com @8.8.8.8CNAME
CNAME — это алиас: он говорит «спроси другое имя». Резолвер кэширует две вещи независимо — сам алиас и результат разрешения цели. Поэтому обновление за CNAME может тянуться дольше суммы ожиданий: сначала должен истечь кэш цели, потом кэш алиаса, а порядок непредсказуем.
Второе следствие: CNAME нельзя ставить на вершину домена (сам example.com без поддомена) — там уже есть SOA и NS. Провайдеры обходят это нестандартными типами вроде ALIAS или CNAME flattening, и ведут они себя по-разному, включая TTL.
MX и почта
Ошибка в MX стоит дороже ошибки в A: непринятое письмо не «перезагрузишь». При этом почта устроена милосерднее веба — отправляющий сервер при неудаче повторяет попытки часами, а не сдаётся сразу. Это даёт запас, но не отменяет подготовку.
Совет «ставьте на MX высокий TTL» — вредный, если вы собираетесь их менять. Высокий TTL не защищает почту, он лишь удлиняет окно, в котором часть отправителей шлёт на старый сервер, и делает откат невозможным. Высокий TTL уместен для записей, которые вы не трогаете, — а перед миграцией его снижают, как и любой другой.
TXT: SPF, DKIM, DMARC
Записи проверки подлинности почты кэшируются на стороне получателя, и вы на этот кэш повлиять не можете вообще. Пока у принимающего сервера лежит старый SPF, письма с нового адреса он будет считать неавторизованными.
Отсюда правило перехода: сначала добавьте новое значение рядом со старым, дайте кэшам обновиться, и только потом удаляйте старое. Для SPF это означает временно перечислить оба источника отправки, для DKIM — держать два селектора одновременно. Проверить, что видно снаружи, можно через проверку почтовых записей домена и MX-lookup.
NS: самый долгий случай
Смена NS-серверов отличается тем, что кэшируется не только у резолверов, но и на уровне зоны TLD. TTL делегирования назначает реестр домена, обычно это сутки или двое, и уменьшить его вы не можете.
Добавьте к этому задержку между регистратором и реестром: изменение NS в панели регистратора не публикуется в зоне мгновенно. Плюс сама зона TLD распространяется по своим серверам.
Полностью настройте зону на новых NS-серверах до того, как менять делегирование. Если резолвер придёт к серверу, который не считает себя авторитетным для домена, вы получите SERVFAIL — а это не «старый сайт», это домен, недоступный целиком, причём кэшируемый.
Если на домене включён DNSSEC, порядок ещё жёстче: перед сменой NS-серверов подпись нужно снять и дождаться истечения кэшей, иначе резолверы с валидацией начнут отбрасывать ответы новых серверов как поддельные. Кто обслуживает домен сейчас и какие NS у него указаны — видно через WHOIS домена.
Как проверить, обновился ли DNS
Проверка «открыл сайт в браузере» ничего не доказывает: вы видите ровно один резолвер и три слоя кэша поверх него. Нужен взгляд с нескольких точек.
Через enterno.io
Быстрее всего — проверка распространения DNS: она опрашивает домен с двух десятков независимых резолверов в разных сетях и странах и показывает, где какое значение. Расхождение в списке и есть незавершённое обновление; когда все строки совпали — ждать больше нечего.
Если нужно посмотреть весь набор записей домена с их TTL, а не одну, — это DNS Lookup. Обзор подходов и инструментов для такой проверки собран в статье о способах проверить распространение DNS.
Через dig
Сравнение нескольких публичных резолверов одной строкой:
for ns in 8.8.8.8 1.1.1.1 9.9.9.9 77.88.8.8; do
printf "%-16s %s\n" "$ns" "$(dig +short @$ns example.com A | tr '\n' ' ')"
doneИ то же самое по авторитетным серверам домена — они обязаны отвечать одинаково:
# Узнать авторитетные серверы
dig +short NS example.com @8.8.8.8
# Спросить каждый напрямую, без рекурсии
for ns in $(dig +short NS example.com @8.8.8.8); do
printf "%-24s %s\n" "$ns" "$(dig +short +norecurse @$ns example.com A)"
doneРасхождение между авторитетными серверами — это уже не ожидание кэша, а рассинхронизация зоны: правку приняла одна копия, а вторая ещё живёт по старому serial. Ждать бесполезно, надо идти к DNS-хостеру.
На Windows
nslookup -type=a example.com 8.8.8.8
nslookup -type=a example.com 1.1.1.1
REM Показать TTL в ответе
nslookup -type=a -debug example.com 8.8.8.8
REM Посмотреть, что закэшировала сама Windows
ipconfig /displaydns | findstr /i example.comБез установки утилит — через HTTPS
Если под рукой нет ни dig, ни nslookup, публичные резолверы отвечают по HTTP. Это же удобно для скриптов и мониторинга:
# Cloudflare
curl -s -H 'accept: application/dns-json' \
'https://1.1.1.1/dns-query?name=example.com&type=A'
# Google — в ответе видно и TTL, и какой сервер отвечал
curl -s 'https://dns.google/resolve?name=example.com&type=A'В поле TTL вы увидите тот же остаток кэша, что и в dig. Полный TTL означает свежий ответ, уменьшающийся — кэш.
Как ускорить обновление DNS
Честный ответ: после того как вы внесли изменение, ускорить его почти невозможно. Всё, что реально работает, делается заранее.
Снизить TTL до изменения — единственный надёжный приём
Порядок действий:
- За время, превышающее текущий TTL (обычно за сутки-двое), поставьте TTL 300 секунд. Само значение записи не трогайте.
- Дождитесь, пока во всех кэшах истечёт старый TTL. Именно этот шаг чаще всего пропускают: если TTL был 86400, менять запись через час после его понижения бессмысленно — резолверы всё ещё держат старую копию с прежним сроком.
- Внесите изменение. Теперь окно расхождения — пять минут.
- Убедитесь, что всё работает, и верните TTL к рабочему значению.
; Шаг 1 — за сутки до миграции: меняем ТОЛЬКО TTL
example.com. 300 IN A 203.0.113.10
www.example.com. 300 IN A 203.0.113.10
; Шаг 3 — окно миграции: меняем адрес
example.com. 300 IN A 198.51.100.25
www.example.com. 300 IN A 198.51.100.25
; Шаг 4 — через несколько дней: возвращаем TTL
example.com. 3600 IN A 198.51.100.25Сбросить локальные кэши
Помогает вам и вашим коллегам убедиться, что всё в порядке. На посетителей не влияет никак.
# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux с systemd-resolved
resolvectl flush-caches
# Linux, старые системы (systemd до 239)
sudo systemd-resolve --flush-cachesОтдельно про браузер: у него собственный короткий кэш и, если включён DNS-over-HTTPS, собственный резолвер, который не совпадает с системным. Проще всего проверять в приватном окне после полного перезапуска браузера.
Что НЕ ускоряет обновление
- Сброс кэша на своей машине. Меняет картину только для вас. Пользователь на другом конце страны как видел старый адрес, так и видит.
- Повторное сохранение записи в панели. Не сбрасывает чужие кэши. Зато меняет serial зоны и иногда провоцирует лишнюю рассинхронизацию.
- Понижение TTL в момент правки. Новый TTL начнёт действовать только для тех, кто запросит запись после истечения старого. Опоздали — придётся отсидеть полный старый срок.
- Формы «очистить кэш» у публичных резолверов. Они существуют у некоторых сервисов, но действуют на один узел из многих, а провайдерских резолверов не касаются вовсе.
- Перезагрузка сайта или сервера. К DNS отношения не имеет.
Заставить чужой резолвер забыть ответ вы не можете. Ни один механизм в DNS не позволяет отозвать уже отданную запись досрочно. Всё управление сроком происходит до изменения, а не после.
Про Cloudflare и другие проксирующие сервисы
Часто пишут, что «через Cloudflare изменения применяются мгновенно». Формулировка неточная и ведёт к ошибкам. Мгновенно применяется смена origin-адреса в настройках прокси: публичная A-запись домена при этом указывает на аникастовый адрес самого сервиса и не меняется вовсе — менять нечего, кэшировать нечего.
Но как только вы трогаете то, что видно снаружи, — выключаете проксирование, меняете NS-серверы или сам публичный адрес — работают обычные правила TTL. Сервис-посредник переносит точку кэширования, а не отменяет её.
DNS и почта: как не потерять письма при смене MX
Во время расхождения кэшей часть отправителей шлёт на старый сервер, часть — на новый. Потери возникают не от самого расхождения, а от того, что старый сервер выключили раньше времени.
- Не выключайте старый почтовый сервер, пока не убедились, что трафик на него прекратился. Ориентир — минимум прежний TTL плюс запас на повторные попытки отправителей.
- Настройте пересылку со старого сервера на новый на весь переходный период — тогда даже «опоздавшее» письмо дойдёт.
- Снизьте TTL MX-записей заранее, вместе с остальными.
- Не удаляйте старый SPF и старые DKIM-селекторы одновременно с переключением: держите старое и новое рядом, пока не истекут кэши получателей.
- Отправьте тестовые письма с нескольких внешних адресов на разных провайдерах и проверьте заголовки — по ним видно, какой сервер принял письмо.
Разбор ошибок: симптом, причина, проверка, фикс
| Симптом | Вероятная причина | Чем проверить | Что делать |
|---|---|---|---|
| У меня старый сайт, у всех новый | Локальный кэш ОС или браузера | dig +short @1.1.1.1 против того, что открывается | Сбросить кэш ОС, проверить в приватном окне |
| У половины пользователей старый сайт | Забыта AAAA-запись или www | dig +short AAAA и запрос для www отдельно | Обновить все записи семейства |
| Прошли сутки, ничего не изменилось | Правка не доехала до авторитетных серверов | Запрос к каждому NS с +norecurse, флаг aa | Проверить зону у DNS-хостера, а не ждать |
| Ответ разный при каждом запросе | Round Robin, разные узлы anycast или рассинхронизация зоны | Опросить все авторитетные серверы подряд | Если расходятся авторитетные — обращаться к хостеру |
| SERVFAIL после смены NS | Новые серверы не обслуживают зону или сломан DNSSEC | Прямой запрос к новым NS, проверка DS-записи | Настроить зону до смены делегирования; снять DNSSEC заранее |
| Новая запись «не появляется» | Отрицательное кэширование NXDOMAIN | Поле minimum в SOA | Дождаться срока из SOA, не пересоздавать запись |
| Почта уходит на старый сервер | Кэш MX у отправителей | MX-lookup с нескольких точек | Держать старый сервер и пересылку включёнными |
| Письма попали в спам после переезда | Старый SPF или DKIM в кэше получателя | Проверка почтовых записей | Держать старое и новое значение одновременно |
Чек-лист миграции DNS
За несколько дней.
- Выпишите все записи домена и их текущие TTL — через DNS Lookup.
- Снизьте TTL до 300 секунд у всех записей, которые будете менять, включая www, AAAA и MX.
- Убедитесь, что новый сервер полностью готов: сайт открывается по IP, сертификат выпущен, почта принимается.
- Если меняете NS — поднимите и наполните зону на новых серверах заранее, при DNSSEC снимите подпись.
Перед самым переключением.
- Дождитесь истечения старого TTL — не путайте с моментом, когда вы его понизили.
- Проверьте, что резолверы уже отдают запись с новым коротким TTL.
- Назначьте окно на время низкого трафика и предупредите тех, кого это касается.
После переключения.
- Проверьте распространение DNS по резолверам разных стран.
- Убедитесь, что все авторитетные серверы отвечают одинаково.
- Смотрите логи обоих серверов: пока на старый идёт трафик, выключать его нельзя.
- Поставьте мониторинг доступности на новый адрес, чтобы узнать о проблеме раньше пользователей.
- Через несколько дней тишины на старом сервере верните TTL к рабочему значению.
- Ещё через неделю выключайте старый сервер.
Частые вопросы
Сколько ждать обновления DNS?
Столько, сколько указано в TTL записи на момент правки, плюс минуты на публикацию у авторитетных серверов. При TTL 300 — пять минут, при TTL 86400 — до суток. Смена NS-серверов может занять дольше, потому что там срок задаёт зона TLD, а не вы.
Откуда взялись «24–72 часа»?
Это шаблонная формулировка регистраторов, покрывающая худший из возможных случаев. Стандартом она не является: DNS не знает такого понятия, все сроки в нём заданы значениями TTL и полем minimum в SOA.
Почему у меня работает, а у клиента — нет?
Вы ходите через разные резолверы с независимыми кэшами, и таймеры у них истекают в разное время. Даже один и тот же публичный адрес вроде 1.1.1.1 — это множество узлов anycast, у каждого свой кэш. Проверяйте через несколько резолверов сразу, а не в браузере.
Можно ли заставить резолвер провайдера сбросить кэш?
Нет. Механизма досрочного отзыва записи в DNS не существует. Сброс кэша на вашей машине меняет картину только для вас. Управлять сроком можно только заранее — через TTL.
Прошло три дня, а сайт всё ещё старый. Что делать?
Это уже не кэш, а ошибка конфигурации. Спросите каждый авторитетный сервер домена напрямую с флагом +norecurse: если там старое значение — правка не применилась; если разное — зона рассинхронизирована. И то и другое решается у DNS-хостера, ожидание не поможет.
Влияет ли смена DNS на позиции в поиске?
Сама по себе — нет, поисковые роботы работают через те же резолверы и TTL. Навредить может простой: если во время переключения часть роботов попадает на неотвечающий сервер, страницы могут временно выпасть из индекса. Поэтому старый сервер и держат включённым до конца.
Нужно ли возвращать TTL обратно после миграции?
Желательно. Низкий TTL — это постоянный поток запросов к вашим авторитетным серверам и чуть более медленное первое подключение у пользователей. Верните рабочее значение через несколько дней, когда убедитесь, что откат не понадобится.
Главное
- Изменение применяется мгновенно — ждут истечения чужие кэши, а не «распространения».
- Срок ожидания задаёт TTL, который стоял в записи в момент правки.
- «24–72 часа» — оценка сверху из писем регистраторов, а не свойство DNS.
- Единственный надёжный способ ускориться — снизить TTL заранее и дождаться истечения старого.
- После правки заставить чужой резолвер обновиться невозможно.
- Меняйте A и AAAA вместе и не забывайте про www — иначе старый сайт увидит половина пользователей.
- Смена NS — самый долгий случай: TTL делегирования назначает зона TLD.
- Новая запись «не появляется» — ищите отрицательный кэш, срок в поле minimum записи SOA.
- Старый сервер и старый SPF держите включёнными, пока трафик на них не прекратится.
- Проверка через браузер ничего не доказывает: смотрите разброс по резолверам и флаг
aaу авторитетных серверов.