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

Откуда берется ожидание

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

Поэтому когда вы меняете A-запись, новое значение существует с той секунды, как его сохранил ваш DNS-провайдер. Каждый резолвер, у которого еще есть старый ответ, продолжает отдавать его, пока не истечет срок его собственной копии. TTL, time to live, - это число в секундах, привязанное к записи и говорящее резолверам, сколько ее можно кэшировать. Запись с TTL 3600 может отдаваться из кэша в течение часа после того, как ее получили, поэтому час - это худший случай для резолвера, который получил ее прямо перед вашей правкой.

Именно поэтому два человека в одном офисе могут видеть разные результаты, и именно поэтому очистка собственного кэша никому больше не помогает. Никакого глобального распространения, которого нужно дождаться, не существует - есть только множество независимых таймеров, истекающих в разные моменты.

Как проверить по нескольким резолверам

Ручной способ - задать один и тот же вопрос нескольким резолверам и сравнить их ответы:

dig +short example.com @8.8.8.8      # Google Public DNS
dig +short example.com @1.1.1.1      # Cloudflare
dig +short example.com @9.9.9.9      # Quad9
dig +short example.com               # your own resolver
dig +short example.com @ns1.yourdns.example  # authoritative: the source of truth

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

Чтобы увидеть не просто значение, а оставшееся время кэша, уберите +short и посмотрите на колонку TTL:

dig example.com @8.8.8.8 | grep -A1 "ANSWER SECTION"

Число перед типом записи отсчитывается вниз по мере старения закэшированной копии, показывая ровно, сколько еще этот резолвер будет отдавать старый ответ. В Windows такое же сравнение без дополнительных инструментов делает nslookup example.com 8.8.8.8. Веб-инструмент DNS-запросов, опрашивающий сразу много локаций, справляется с той же задачей быстрее и заодно охватывает резолверы, недоступные с вашей машины.

Почему это может занять часы

• Действует старый TTL, а не новый. Если у записи был TTL 86400 и вы понижаете его прямо во время изменения, резолверы, закэшировавшие старую запись, все равно имеют право хранить ее целые сутки. Понижение TTL помогает только следующему изменению.
• Некоторые резолверы игнорируют короткие TTL. Ряд провайдеров навязывает собственный минимум, обычно час и более, независимо от того, что говорит ваша запись.
• Смена серверов имен идет медленнее. NS-записи на уровне реестра часто несут TTL, измеряемый днями, поэтому смена DNS-провайдера действительно может занять от одного до двух дней, пока все не устаканится.
• Негативное кэширование тоже считается. Если при поиске имя еще не существовало, ответ "не существует" тоже кэшируется - на срок, заданный полем SOA minimum зоны.
• Цепочки кэшей. Браузер кэширует DNS, операционная система кэширует DNS, а перед публичным резолвером может стоять еще и корпоративный. Каждый слой добавляет собственную задержку.
• Долгоживущие соединения. Приложения, разрешившие имя хоста один раз при запуске, продолжают использовать этот адрес до перезапуска, что бы DNS ни говорил сейчас.

Как ускорить следующее изменение

1. Сначала понизьте TTL, затем подождите. Понизьте TTL записи до 300 секунд и оставьте так минимум на срок старого TTL, прежде чем вносить настоящее изменение. К этому моменту у каждой закэшированной копии будет короткое значение.
2. Внесите изменение. При TTL в 300 секунд большинство резолверов подхватят его в течение пяти минут.
3. Держите старый сервер отвечающим на время перекрытия. Не выключайте его в момент обновления DNS. Оставьте его отвечать, пока трафик на него не иссякнет, и миграция пройдет незаметно.
4. Сверьтесь с авторитетными серверами имен и несколькими публичными резолверами, прежде чем объявлять изменение завершенным.
5. Верните TTL обратно, когда изменение устоялось, чтобы обычный трафик снова выигрывал от кэширования.

Для смены серверов имен обходного пути нет, потому что TTL на уровне реестра задаете не вы. Закладывайте день-два и все это время держите оба DNS-провайдера отдающими идентичные записи, чтобы не имело значения, к которому из них обратится резолвер.

После того как изменение устоялось

Проверка нескольких резолверов вручную показывает, насколько далеко разошлось изменение в момент проверки - это полезно во время миграции и бесполезно все остальное время. Ловить стоит более поздние сбои: запись, изменившаяся незаметно для всех, сервер имен, переставший отвечать, истекшую зону. Непрерывный мониторинг DNS опрашивает много локаций по расписанию и оповещает, когда ответ перестает соответствовать ожидаемому, а заодно ловит случай "отсюда работает, оттуда - нет", который не увидеть одним запросом. Выполните запрос прямо сейчас с помощью инструмента DNS-запросов. Если сайт недоступен именно вам, а в других местах работает, дальше поможет руководство "не работает для всех или только у меня".