Сколько длится распространение DNS и как его проверить

Когда браузеру нужен example.com, он запрашивает рекурсивный резолвер: вашего интернет-провайдера, вашей компании или публичный, например Google или Cloudflare. Резолвер запрашивает авторитетные NS-серверы домена и кеширует ответ на столько, сколько позволяет TTL (time to live, время жизни) записи. Пока эта закешированная копия не устареет, он будет отдавать старый ответ, как бы недавно вы ни изменили запись.

Так что «распространение» — это просто тысячи кешей, которые устаревают в разное время. Резолвер, запросивший ваш домен за секунду до изменения, держит старый ответ целый TTL. Тот, что никогда его не запрашивал, сразу получает новый ответ. Вот почему друг видит новый сайт, а вы ещё видите старый.

Цифра «от 24 до 48 часов», которую вы видите повсюду, происходит от смены NS-серверов и из времён, когда длинные TTL были нормой. После изменения A-записи с TTL 300 секунд почти все видят новый сервер в течение нескольких минут.

• Вы понизили TTL слишком поздно. Понижение TTL помогает только после того, как старый, длинный TTL истечёт в кешах. Понижайте его за сутки: см. Понизьте TTL перед переносом.
• Локальные кеши. Операционная система и браузер тоже кешируют DNS. Очистите их, прежде чем решать, что распространение застряло.
• Забытая запись. www по-прежнему указывает на старый сервер, или старая AAAA-запись (IPv6) продолжает отправлять туда посетителей с IPv6.
• CDN или прокси перед сайтом. Если перед сайтом стоит Cloudflare или другой прокси, ответ DNS — это адрес CDN, и он не меняется. Менять нужно настройку origin в CDN, и Cloudflare применяет её за секунды, так что распространяться нечему: вместо этого проверьте новый сервер с помощью ссылки-превью.
• Резолверы, которые держат ответы дольше TTL. Такие встречаются. Их меньшинство, поэтому старый сервер и держат включённым ещё день-два после переключения.

1. 1

   Шаг 1: Убедитесь, что изменение есть на авторитетных NS-серверах

   Запросите собственные NS-серверы домена. Если они по-прежнему возвращают старое значение, запись не сохранена, и ожидание не поможет.

2. 2

   Шаг 2: Опросите публичные резолверы по всему миру

   Введите домен и ожидаемое значение в проверку распространения DNS, чтобы увидеть, какие резолверы уже его возвращают.

3. 3

   Шаг 3: Проверьте каждое имя хоста и тип записи

   Повторите для www, других поддоменов и AAAA-записей. Забытая запись — самая частая причина, по которой изменение кажется застрявшим.

4. 4

   Шаг 4: Очистите собственные кеши

   Очистите кеш DNS операционной системы и перезапустите браузер, прежде чем проверять сайт самостоятельно.

5. 5

   Шаг 5: Убедитесь, что сайт отвечает с нового сервера

   Воспользуйтесь инструментом Переключился ли мой домен?, чтобы проверить, что домен резолвится в новый IP и сайт там отвечает.

6. 6

   Шаг 6: Получайте уведомление вместо обновления страницы

   Включите уведомления о распространении DNS для ссылки-превью, и DNSPeek будет проверять каждые несколько минут и отправит вам email, когда изменение завершится.

Запросите конкретные публичные резолверы напрямую. Число в разделе ответа — это оставшийся TTL закешированного ответа в секундах:

dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +short
dig @9.9.9.9 example.com A +noall +answer

Resolve-DnsName -Name example.com -Type A -Server 8.8.8.8
Resolve-DnsName -Name example.com -Type A -Server 1.1.1.1

Чтобы увидеть, что говорят авторитетные NS-серверы без всякого кеша, запросите их напрямую. Найдите их командой dig NS example.com +short или с помощью проверки NS-серверов, а затем выполните dig @ns1.your-dns-host.com example.com A. Если даже авторитетный ответ старый, изменение не сохранено.

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Глобального переключателя, который срабатывает в один момент, нет, так что выберите правило. DNSPeek использует такое: распространение завершено, когда не менее 90 % ответивших публичных резолверов возвращают новое значение и ответила как минимум половина всех резолверов. Резолверы, не ответившие вовремя, не учитываются, поэтому один недоступный резолвер вас не задержит. Самый большой TTL, который ещё встречается, показывает, сколько может продержаться устаревший кеш. Когда новое значение — адрес Cloudflare, засчитывается любой адрес Cloudflare, потому что Cloudflare выдаёт каждому региону собственный edge-IP.

Бесплатная проверка распространения DNS применяет это правило к 20 публичным резолверам, которые опрашивает сервер DNSPeek. В кабинете ссылка-превью может по запросу проверить 16 резолверов, а на платных тарифах DNSPeek может отправить вам уведомление по email или через вебхук, когда распространение для домена завершится, а затем повторно запустить ваш QA-отчёт на рабочем домене.

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

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

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