#Что на самом деле происходит
«Распространения DNS» как рассылки нет: изменения публикуются на авторитетных серверах сразу, а затем разные резолверы обновляют свой кеш по мере истечения TTL. Поэтому одни пользователи увидят новый адрес через минуту, а другие через сутки. Отдельный случай — смена NS-серверов: делегирование зоны хранится в родительской зоне (например, .ru), её обновляют раз в несколько часов, а кеш родительской зоны живёт до 24–48 часов. Это самая долгая часть.
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| TTL записиЗначение в секундах. | Задержка до TTL. | Снизьте TTL заранее. |
| Смена NSРодительская зона. | До 24–48 часов. | Не меняйте NS без необходимости. |
| Кеш провайдераИгнорирует низкий TTL. | Долго видят старое. | Подождите. |
| Кеш роутера и ОСЛокальный. | Только у вас. | Сбросьте. |
| Кеш браузераОтдельный DNS-кеш. | Chrome: chrome://net-internals/#dns. | Очистите. |
| Ошибка в записиНеверный IP. | Все видят неверное. | Исправьте запись. |
#Как проверить, на каком этапе вы находитесь
- Убедитесь, что запись сохранена у DNS-провайдера и опубликованаЭто действие выполняет владелец домена. Откройте панель регистратора и посмотрите раздел «Домены → DNS-серверы/NS» (названия зависят от компании); запишите опубликованные NS. Затем в терминале Linux/macOS выполните
dig NS example.com +short, а в Windows —nslookup -type=NS example.com, заменив example.com вашим доменом. Сравните список с DNS-панелью, где редактируется зона: правки в другой, неделегированной зоне не увидят посетители. Если NS отличаются, сначала уточните у регистратора, какие серверы обслуживают домен. - Проверьте ответ авторитетного сервераДля владельца домена: сначала выясните фактические NS у регистратора. На Linux/macOS откройте «Терминал» и выполните
dig @ns1.example.net example.com A +noall +answer, заменив имя NS и домен на реальные, а A — на тип изменённой записи. Данные в ответе должны совпадать с новой записью DNS-панели; запрос напрямую к NS обходит кеш публичного рекурсивного DNS. Если запись там старая или не найдена — исправляйте зону у поставщика DNS, а не ждите кеш. - Сравните ответы разных публичных резолверовОткройте терминал Linux/macOS и по очереди выполните
dig @1.1.1.1 example.com A +noall +answerиdig @8.8.8.8 example.com A +noall +answer. Замените example.com и тип A на свои. В Windows используйтеnslookup -type=A example.com 1.1.1.1, затем с 8.8.8.8. Сверьте IP и оставшийся TTL с ответом авторитетного сервера. Разные ответы при правильной авторитетной записи обычно указывают на разные состояния кеша; повторяйте проверку после окончания прежнего TTL. - Проверьте остаток TTLTTL означает срок, в течение которого рекурсивный DNS может хранить прежний ответ. В терминале Linux/macOS выполните
dig @1.1.1.1 example.com A +noall +answer, заменив example.com и тип A на свои. В первой колонке после имени показан оставшийся TTL в секундах на данном DNS-сервере; другой сервер может иметь иной срок. Если авторитетный сервер уже отдаёт новое значение, не меняйте запись повторно: дождитесь истечения прежнего TTL, затем повторите запрос. - Сбросьте локальный кешОчистка локального DNS полезна, только если запись уже изменена у авторитетного сервера, а этот компьютер продолжает находить старый адрес. В Windows нажмите «Пуск», введите
cmd, откройте «Командная строка» и выполнитеipconfig /flushdns(сообщение об успешной очистке кеша). В macOS откройте «Терминал» и выполнитеsudo dscacheutil -flushcache, затемsudo killall -HUP mDNSResponderс паролем администратора; команды не показывают подробный вывод. В Linux с systemd-resolved выполнитеresolvectl flush-caches(права зависят от настроек). Выберите только вариант своей ОС и снова откройте нужный сайт; чужие кеши этим не очищаются. - Если нужно срочно, обратитесь к ресурсу по IP или используйте файл hostsИспользуйте обходной способ только для временной диагностики своего домена, если авторитетные DNS уже отвечают новым IP, а рекурсивные серверы ещё хранят старую запись. Например, проверьте нужный виртуальный хост через
curl --resolve mysite.example:443:203.0.113.10 https://mysite.example/, заменив оба примера действительными значениями: это сохраняет доменное имя для HTTPS. Прямой заход по IP может не работать из-за виртуальных хостов и сертификата. Не меняйте/etc/hostsна общем или рабочем компьютере без согласования, а после теста удалите временную запись. - Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
#Что влияет на скорость
#Рекомендации по переезду
За 1–2 дня до переезда снизьте TTL до 300 секунд. Не удаляйте старый сервер минимум 48 часов. Настройте на старом сервере перенаправление или проксирование на новый адрес. После переезда проверьте почту: MX-записи тоже кешируются. Верните TTL на 3600 и выше, чтобы снизить нагрузку на DNS.
#Отдельные случаи, когда задержка дольше обычной
Если вы переносите домен к другому регистратору и одновременно меняете NS, возможна пауза в несколько дней: часть DNS-хостингов не публикует зону, пока домен не окажется под их управлением. Прежде чем менять NS, создайте на новом DNS-хостинге все записи (A, MX, TXT, CNAME) и сравните с текущими, иначе почта и поддомены временно перестанут работать. Экспортировать зону можно командой dig example.ru AXFR @ns1.example.net, если провайдер разрешает трансфер, либо вручную через панель.
Отдельно учтите отрицательное кеширование: если какой-то резолвер получил ответ «записи нет» (NXDOMAIN) до вашего изменения, он запомнит его на время, указанное в поле minimum записи SOA. Поэтому только что созданный поддомен может не открываться у части пользователей ещё около часа.
dig +short SOA example.ru