Почему изменения DNS не сразу: TTL и распространение

Что на самом деле значит «распространение DNS»

«Распространение» — неудачное слово, и именно из него растёт почти вся путаница. Ничто не расходится по интернету. Когда вы меняете запись у своего DNS-провайдера, изменение действует на ваших авторитативных серверах имён сразу, обычно за считанные секунды.

Время уходит на обратное: резолверы по всему миру продолжают отдавать старый ответ, потому что вы сами им это разрешили. У каждой записи есть TTL — время жизни, и любой резолвер, который однажды её получил, вправе отдавать сохранённую копию до истечения срока. Раньше он переспрашивать не будет: вы сказали, что это не нужно.

Поэтому правильный вопрос — не «распространилось ли изменение?», а «чей кэш ещё держит старый ответ и когда он истечёт?». У этого вопроса есть точный ответ, и его можно посмотреть.

Как TTL работает на самом деле

TTL — это число секунд, прикреплённое к каждой записи. Это не подсказка и не пожелание, а договор. Запись с TTL 3600 говорит каждому резолверу: ответ действителен час, раньше не возвращайся.

Три детали сбивают с толку почти всех:

• Отсчёт начинается, когда резолвер положил запись в кэш, а не когда вы внесли правку. Если резолвер получил вашу запись 50 минут назад с TTL 3600, он обновится через 10 минут. Тот, кто получил её 5 минут назад, подождёт 55. Поэтому одни видят изменение намного раньше других.
• Значение имеет старый TTL. Понизить TTL в тот же момент, когда вы меняете значение, ничего не ускорит: резолверы всё ещё подчиняются TTL из предыдущего запроса. Новый, короткий, начнёт действовать только с их следующего обновления.
• TTL задаётся для записи, а не для домена. Ваши A- и MX-записи могут истекать с разницей в часы.

Какие кэши хранят старый ответ

Между посетителем и вашими серверами имён редко стоит только один кэш. Когда изменение словно застряло, стоит понять, какой слой виноват.

• Рекурсивный резолвер — провайдерский или публичный вроде Cloudflare и Google. Именно этим кэшем управляет TTL, и обычно он и есть настоящий ответ на вопрос «почему коллега видит, а я нет».
• Операционная система держит собственный небольшой кэш. Сбросить его — это единственный шаг, который действительно в ваших руках.
• Браузер кэширует отдельно, и Chrome в частности хранит записи заметно дольше короткого TTL. Другой браузер или приватное окно отсекают этот вариант за секунды.
• Ваш собственный роутер может работать как перенаправляющий резолвер и добавлять ещё один слой кэша.

Проверка с одной машины поэтому почти ничего не говорит. Опросите несколько публичных резолверов напрямую и сравните ответы — ровно для этого и существует инструмент DNS-запросов.

Сколько это занимает в действительности

Честный ответ: для огромного большинства — не дольше предыдущего TTL. Повторяемые везде «24–48 часов» родом из времён куда более длинных значений по умолчанию и сегодня ошибочны намного чаще, чем верны.

• TTL 300 (5 минут) — практически мгновенно. Обычно у записей, которые часто меняются.
• TTL 3600 (1 час) — очень распространённое значение по умолчанию. Большинство увидит изменение в течение часа.
• TTL 86400 (24 часа) — до сих пор стоит по умолчанию у части регистраторов и есть настоящий источник совета «подождите сутки».

Две вещи действительно занимают больше. Смена серверов имён у регистратора затрагивает записи самого домена верхнего уровня, у которых свой TTL, часто 48 часов. И отдельные резолверы игнорируют короткие TTL и ставят собственный минимум — отсюда упорное меньшинство, которое отстаёт.

Как сменить запись без простоя

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

Сначала понизьте TTL и подождите

Минимум за один полный период старого TTL до правки поставьте TTL 300. Затем дайте старому TTL истечь. Этот шаг пропускают все, и только он имеет значение: вы тратите ожидание заранее, пока старое значение ещё верно и никому не мешает.

Внесите изменение

Теперь меняйте значение. Поскольку каждый резолвер обновляется раз в пять минут, новый ответ доходит до мира примерно за это время.

Проверяйте не со своей машины

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

Верните TTL

Когда изменение подтверждено, поднимите TTL до здорового значения — 3600 или выше. Оставить везде 300 навсегда значит получить больше запросов, чуть более медленную первую загрузку и никакого кэша, который прикроет вас, если у ваших серверов имён случится плохой день.

Как честно проверить прогресс

Три проверки рассказывают почти всё:

• Сравните резолверы. Спросите одну и ту же запись у Cloudflare, Google и Quad9. Разные ответы означают, что изменение идёт, а не сломалось.
• Прочитайте TTL в ответе. Резолвер возвращает остаток секунд своей копии, в обратном отсчёте. Это число буквально показывает, сколько ещё данный резолвер будет отдавать старый ответ.
• Запрашивайте именно тот тип, который меняли. Устаревшая MX-запись не появится в запросе типа A.

Все три укладываются в браузер с инструментом DNS-поиска: меняйте резолвер между запросами и смотрите TTL в каждой строке.

Верно ли это для MX, TXT и CNAME?

Да — механизм одинаков для любого типа записи, но последствия различаются, и об этом полезно знать до того, как их трогать.

• MX-записи требуют осторожности. Пока старая MX лежит в кэше, почта доставляется на старый сервер. Это письмо не стоит в очереди, ожидая вас: оно попадает туда, куда вы, возможно, больше не заглядываете. Понижайте TTL заранее, задолго до переноса почты, и держите старый ящик доступным, пока TTL не истечёт полностью.
• TXT-записи — SPF, DKIM, подтверждение домена — обычно самые безобидные: не прошедшая проверка просто повторится позже. Исключение — SPF: устаревшая SPF-запись способна помечать настоящие письма как сбой в этот промежуток.
• CNAME-записи приносят второй TTL. Резолвер кэширует ваш CNAME и отдельно запись цели, у каждой свой отсчёт. Ваше реальное ожидание — большее из двух; поэтому CNAME на провайдера с длинным TTL может отставать от вашей собственной настройки.
• NS-записи — тот самый медленный случай, описанный выше, потому что делегирование живёт на уровень выше, в зоне домена верхнего уровня.

Что бы вы ни меняли, запрашивайте именно этот тип, а не догадывайтесь. Устаревшая MX невидима в A-запросе, а значение имеет TTL той строки, которую вы действительно правили.

Частые ошибки

• Понизить TTL и сменить значение одним заходом. Самая частая ошибка, и она ничего не даёт.
• Судить по одному браузеру. Четыре кэша в глубину — худшее место для проверки.
• Сменить серверы имён, когда речь была о записи. Намного медленнее и легко сделать случайно, следуя общим инструкциям.
• Оставить TTL 300 навсегда после переноса.
• Решить, что нужны сутки, и не проверять. При TTL в час вы обычно закончили через час.

Коротко

Ваше изменение заработало в тот момент, когда вы нажали «сохранить». Вы ждёте истечения чужих кэшей, и старый TTL точно говорит, сколько это займёт. Понижайте TTL перед запланированной правкой, проверяйте по публичным резолверам, а не в своём браузере, и возвращайте TTL после. Посмотрите текущие записи домена и остаток TTL бесплатным инструментом DNS-поиска или убедитесь, что сертификат добрался до нового хоста, с помощью проверки SSL-сертификата.

Связанные инструменты и руководства:

• Поиск DNS — Запрашивайте записи A, AAAA, MX, TXT, NS и другие со значениями и TTL, а также обратный DNS.
• Проверка SSL-сертификатов — Проверьте SSL-сертификат любого домена: издатель, срок действия и оставшиеся дни.
• DNS-запрос: полное руководство по запросу записей домена — Узнайте

Частые вопросы