Почему не обновляются DNS-записи домена: разбор TTL, отрицательного кэширования SOA и диагностика через dig, nslookup и онлайн-чекеры

Типичная ситуация из практики любого сисадмина и вебмастера: вы развернули новый VDS, настроили Nginx, перенесли базу данных и изменили A-запись домена в панели управления DNS. Однако проходит час, два, а сайт у вас или у клиентов по-прежнему открывается со старого сервера либо выдает ошибку недоступности. Поддержка хостинга привычно отвечает дежурной фразой: «Ожидайте от 24 до 72 часов, пока разойдутся DNS».

Но в 2026 году формулировка «распространение DNS» (DNS propagation) — это устаревший миф, скрывающий непонимание базовых принципов работы распределенного кэширования. Записи DNS никуда не «расползаются» по проводам и не рассылаются широковещательными пакетами. Вся архитектура DNS построена на строгом механизме pull-запросов и независимого кэширования.

1. Миф о «распространении DNS» и реальная архитектура резолвинга

Когда в профессиональных кругах говорят о «распространении DNS», многие новички представляют это как активную синхронизацию: будто бы ваш регистратор или DNS-хостинг после нажатия кнопки «Сохранить» начинает обзванивать миллионы маршрутизаторов и провайдеров по всему миру, передавая новый IP-адрес.

В действительности DNS работает строго в режиме запросов по требованию:

• Сервер зоны пассивен: Авторитетный сервер (Authoritative Name Server), на котором вы отредактировали файл зоны, никого ни о чем не уведомляет (за исключением своих вторичных slave/secondary серверов по протоколу AXFR/IXFR).
• Резолвер запрашивает запись только при обращении клиента: Если пользователь из Москвы зашел на ваш сайт, его локальный интернет-провайдер обращается к авторитетному серверу и сохраняет ответ в свой локальный кэш.
• Кэш живет строго по таймеру: Пока не истечет счетчик времени жизни записи (TTL), провайдер вообще не обращается к вашему DNS-серверу повторно. Он мгновенно отдает старый IP из оперативной памяти.

2. Авторитетные NS-серверы против публичных резолверов

Чтобы безошибочно диагностировать проблемы с обновлением домена, важно четко разделять участников цепочки разрешения имен (DNS Resolution Chain):

Когда вы меняете запись в личном кабинете хостинга, авторитетные серверы обновляют свои данные практически мгновенно. Проверить это можно прямым опросом авторитетного сервера в терминале — он сразу отдаст ваш новый IP-адрес. Вся задержка возникает на уровне промежуточных рекурсивных резолверов.

3. Механика TTL: почему значение 86400 замораживает старый сервер

Ключевой параметр, управляющий временем жизни DNS-записи — это TTL (Time To Live), выраженный в секундах. Это число передается авторитетным сервером в каждом DNS-ответе и указывает резолверу: «Ты обязан кэшировать эту запись и не переспрашивать меня повторно в течение X секунд».

По умолчанию многие DNS-провайдеры и регистраторы выставляют следующие стандартные значения:

• 86400 секунд = 24 часа (1 сутки)
• 43200 секунд = 12 часов
• 14400 секунд = 4 часа
• 3600 секунд = 1 час
• 300 секунд = 5 минут

Если у вашей A-записи был установлен TTL 86400, а вы внезапно решили поменять IP сервера в 14:00, то любой клиент, открывавший ваш сайт в 13:59, не сможет увидеть новый сервер до 13:59 следующих суток. Даже если вы измените TTL на 300 одновременно со сменой IP, резолверы не узнают о новом TTL, так как они уже сохранили старый таймер отсчета на сутки.

4. Ловушка отрицательного кэширования: поле Minimum TTL в записи SOA

Бывает куда более коварная проблема, с которой сталкиваются разработчики при добавлении новых поддоменов (например, api.domain.ru или staging.domain.ru). Вы только что создали запись, а браузер упорно пишет: «DNS_PROBE_FINISHED_NXDOMAIN» (домен не существует). И эта ошибка не уходит часами, хотя запись в панели DNS уже активна.

Это классический эффект отрицательного кэширования (Negative Caching), регламентированный стандартом RFC 2308.

Если вы или кто-то из ваших скриптов/коллег обратились к api.domain.ru до того, как вы сохранили A-запись в панели DNS, публичный резолвер (например, 8.8.8.8) обратился к авторитетному серверу и получил ответ NXDOMAIN («Имя не существует»).

Чтобы резолверы не перегружали DNS-серверы миллионами повторных запросов к несуществующим именам, RFC 2308 обязывает резолвер кэшировать сам факт отсутствия записи.

По стандарту RFC 2308 (раздел 5), итоговое время жизни отрицательного кэша вычисляется строго как минимум из двух величин:

Negative_Cache_TTL = min(SOA.MINIMUM, TTL самой записи SOA)

В большинстве конфигураций TTL самой записи SOA устанавливается равным или большим, чем поле MINIMUM, поэтому на практике тайм-аут определяет именно последнее поле записи SOA (Start of Authority). Кроме того, современные резолверы (Unbound, BIND 9, публичные DNS) часто устанавливают верхний потолок (clamp) на отрицательный кэш — по умолчанию от 1 до 3 часов (согласно рекомендациям RFC 2308), игнорируя слишком большие значения хостинга.

Давайте посмотрим, как устроена типичная запись SOA:

domain.ru. IN SOA ns1.provider.ru. hostmaster.domain.ru. (
    2026100601 ; Serial: номер версии зоны (YYYYMMDDNN)
    14400      ; Refresh: интервал проверки обновлений вторичными NS (4 часа)
    3600       ; Retry: повтор при неудачной синхронизации (1 час)
    1209600    ; Expire: срок годности зоны, если первичный NS недоступен (14 дней)
    86400      ; Minimum / Negative Caching TTL: кэширование NXDOMAIN (24 часа!)
)

Обратите внимание на последнее число — 86400 (24 часа) или 10800 (3 часа). Это и есть тайм-аут отрицательного кэширования! Если вы случайно сделали пинг или открыли новый поддомен за минуту до создания записи, публичный резолвер запомнил, что «домена нет», и будет возвращать NXDOMAIN вплоть до истечения этого тайм-аута.

5. Инструментальная диагностика: пошаговая проверка через dig и nslookup

Не доверяйте браузеру при отладке DNS — он использует многослойное внутреннее кэширование сокетов. Используйте консольные утилиты dig (доступна в Linux/macOS и в пакете bind-utils) и nslookup (штатная утилита в Windows и Linux).

1. Проверка ответа текущего DNS-резолвера системы

Узнайте, какой IP-адрес и какой остаточный TTL видит ваш компьютер прямо сейчас:

dig domain.ru +noall +answer

Пример вывода:

domain.ru.    1842    IN    A    194.58.112.34

Вторая колонка (1842) показывает оставшееся время жизни в кэше вашего резолвера в секундах (~30 минут).

2. Прямой опрос авторитетного NS-сервера хостинга

Чтобы исключить промежуточные кэши и проверить, действительно ли применились изменения в панели управления, опросите авторитетный NS-сервер напрямую (через символ @):

dig @ns1.timeweb.ru domain.ru A +noall +answer

Если авторитетный сервер сразу отдает новый IP — проблема исключительно в кэше промежуточных провайдеров. Если он отдает старый IP — изменения не сохранились в панели либо домен делегирован на другие NS!

3. Полная трассировка цепочки делегирования (+trace)

Команда +trace эмулирует работу корневого резолвера с самого верха иерархии (от корневых серверов интернета . к серверам зоны .ru и вашим NS):

dig domain.ru +trace

Этот вывод моментально покажет, если в реестре зоны верхнего уровня прописаны устаревшие NS-серверы старого провайдера.

4. Проверка записи SOA и времени отрицательного кэша

Запросите запись SOA, чтобы узнать текущий серийный номер зоны и параметр Negative Caching:

dig domain.ru SOA +noall +answer

6. Проверка глобального резолвинга через онлайн-инструменты SysKit

Консольный опрос с локальной машины показывает ситуацию только с одного провайдера. Но как узнать, как домен виден из других городов, стран и мобильных сетей?

Для комплексного аудита используйте бесплатные сетевые инструменты SysKit:

• DNS Lookup онлайн — мгновенная проверка всех ресурсных записей домена (A, AAAA, MX, TXT, CNAME, NS, SOA) с отображением точного значения TTL и авторитетных серверов.
• Проверка хостинга домена — позволяет в один клик определить текущего провайдера, ASN сети и реальный IP-адрес, на который сейчас ссылается домен.
• WHOIS проверка домена — проверка текущего статуса делегирования домена у регистратора и списка активных NS-серверов в реестре TLD.
• Ping чекер онлайн — проверка доступности нового VDS и сетевой задержки из различных географических точек.

7. Сброс кэша DNS в Windows, Linux, macOS и браузере

Если вы уверены, что публичные резолверы уже отдают новый IP-адрес, но ваш локальный компьютер или браузер упорно открывают старый сервер, необходимо принудительно очистить локальные кэши.

Очистка в Windows

Запустите командную строку (cmd) или PowerShell и выполните:

ipconfig /flushdns

Очистка в Linux (Ubuntu / Debian c systemd-resolved)

В современных дистрибутивах Linux с демоном systemd-resolved выполните:

sudo resolvectl flush-caches
# Для старых версий (Ubuntu 20.04 и ниже):
# sudo systemd-resolve --flush-caches

Проверить текущее состояние статистики кэша можно командой: resolvectl statistics.

Очистка в macOS

В терминале macOS выполните сброс через системные демоны:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Очистка внутреннего кэша Google Chrome и Яндекс Браузера

Браузеры на базе Chromium имеют собственный независимый кэш DNS и пул открытых сокетов Keep-Alive. Даже после ipconfig /flushdns браузер может продолжать слать запросы в уже открытое TCP-соединение со старым сервером.

1. Откройте в адресной строке: chrome://net-internals/#dns и нажмите кнопку «Clear host cache».
2. Затем перейдите на вкладку chrome://net-internals/#sockets и нажмите «Flush socket pools» (это принудительно разорвет открытые сессии со старым IP-адресом).
3. Перезагрузите вкладку сайта комбинацией Ctrl + F5 (или Cmd + Shift + R на Mac).

8. Инженерный регламент бесшовного переноса домена на новый VDS

Чтобы миграция любого веб-проекта на новый сервер прошла без простоя (Zero Downtime) и без ожидания «расползания DNS», строго следуйте 4-этапному регламенту: