Распространение DNS

Что такое распространение DNS?

Распространением DNS называют время, за которое изменение записи становится видимым через разные рекурсивные резолверы и клиентские кэши. Запись не «разлетается» по интернету сама: авторитетный сервер меняется сразу, а старые копии постепенно истекают по TTL.

Почему слово «распространение» условно

Точнее говорить об истечении DNS-кэша. Резолвер, у которого есть действующая копия, продолжает отдавать её до окончания TTL; новый запрос после истечения получает данные от авторитетной зоны. Поэтому разные сети могут временно показывать разные ответы.

Как меняются DNS-записи

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

Процесс обновления

Step 1: Update DNS records
        example.com A record: 203.0.113.50 → 203.0.113.51

Step 2: Authoritative nameserver immediately serves new record

Step 3: Existing cached copies remain valid until TTL expires

Step 4: New queries after TTL expiration receive updated record

Step 5: All caches eventually expire and refresh
        → "Propagation complete"

Пример временной шкалы

При TTL 300 секунд резолверы, заполнившие кэш в разное время, истекут не одновременно. Последний старый ответ исчезнет после истечения последней действующей копии.

Time: 10:00 - DNS updated (TTL: 300s / 5 minutes)

Resolver A (cached at 09:58):
  09:58 - Cached old IP, expires 10:03
  10:03 - Cache expires, queries again, gets new IP

Resolver B (cached at 10:01):
  10:01 - Cached old IP, expires 10:06
  10:06 - Cache expires, queries again, gets new IP

Resolver C (queries at 10:05):
  10:05 - No cache, queries immediately, gets new IP

All resolvers have new IP by: 10:06
Propagation time: 6 minutes (worst case based on TTL)

Что определяет длительность

На время влияют TTL конкретной записи, кэш NS на уровне реестра, поведение ISP-резолвера, локальные кэши и география наблюдения. Ответ одного резолвера не описывает весь интернет.

Время жизни записи (TTL)

TTL задаёт, сколько секунд разрешено хранить запись в кэше. Низкое значение ускоряет управляемое изменение, но увеличивает число запросов к авторитетной инфраструктуре; высокое снижает нагрузку, но дольше сохраняет старое значение.

Изменение nameserver

Смена делегации обычно дольше изменения A или MX-записи, потому что NS могут кэшироваться на уровне TLD и реестра.

Registry Level: 24-48 hours (TLD nameserver cache)
Resolver Level: Based on NS record TTL
Total Time: Up to 48 hours worst case

Поведение ISP и резолверов

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

Географическое распределение

В разных регионах кэш заполнялся в разное время, поэтому ответы меняются постепенно.

North America: 10:05 - Updated
Europe: 10:08 - Updated
Asia: 10:12 - Updated

Кэш на стороне клиента

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

Проверка распространения DNS

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

Онлайн-сервисы проверки

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

curl "https://domscan.net/v1/health?domain=example.com"
# Shows current DNS configuration

Проверка из командной строки

Запрос к нескольким публичным резолверам помогает увидеть различия и отделить локальный кэш от ответа зоны.

Сначала найдите NS, затем запросите нужный тип непосредственно у авторитетного сервера. Такой ответ показывает состояние источника без рекурсивного кэша.

# Google DNS
dig @8.8.8.8 example.com

# Cloudflare DNS
dig @1.1.1.1 example.com

# Your ISP (no @ server specified)
dig example.com

# Compare results

# Find nameservers
dig example.com NS

# Query authoritative NS directly
dig @ns1.example.com example.com

Проверка из нескольких мест

DNS over HTTPS и независимые точки наблюдения помогают сравнивать сети, но DoH тоже может иметь собственный кэш и политику. Фиксируйте endpoint и время запроса.

# Using curl with DNS over HTTPS
curl -H 'accept: application/dns-json'   'https://cloudflare-dns.com/dns-query?name=example.com&type=A'

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

Планируйте изменение до переключения, уменьшайте TTL заранее и держите старую инфраструктуру доступной, пока новая запись не станет видимой из нужных регионов.

Подготовка до изменения

Уменьшайте TTL за 24–48 часов, чтобы старые копии успели истечь. Нельзя задним числом изменить TTL уже сохранённой кэшированной записи.

Выдержите полный прежний интервал, например 3600 секунд, прежде чем считать, что большинство резолверов увидит новый TTL.

После подготовки замените запись и проверьте её на авторитетном сервере.

Old: example.com.    3600    IN    A    203.0.113.50
New: example.com.    300     IN    A    203.0.113.50
                     ^^^
                     Reduced to 5 minutes

example.com.    300    IN    A    203.0.113.51

example.com.    3600    IN    A    203.0.113.51

Наблюдение во время переключения

Сравнивайте A, AAAA, MX и другие затронутые записи по регионам, отслеживайте ошибки и держите план отката. Не смешивайте timeout или rate limit с доказательством отсутствия домена.

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

Типовые сценарии

Разные типы изменений имеют разные риски: адрес сайта обычно меняется быстрее, чем делегация, а почта требует периода сосуществования старого и нового сервера.

Изменение A-записи

Ожидайте примерно один TTL, но проверяйте реальную картину из нескольких резолверов.

# Before
example.com → 203.0.113.50

# After
example.com → 203.0.113.51

# Propagation: 1x TTL duration

Изменение MX-записи

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

Изменение nameserver

Переключение NS может занимать 24–48 часов из-за кэша TLD. Все записи лучше подготовить на новых авторитетных серверах до изменения делегации.

Why so long?
TLD registry caches NS records
Registry TTL often 24-48 hours
No control over registry cache

Добавление поддомена

Новый поддомен может не разрешаться из-за отрицательного кэша NXDOMAIN, даже если запись уже создана.

If subdomain was queried and didn't exist:
→ NXDOMAIN cached (SOA minimum TTL)
→ New subdomain won't resolve until cache expires

Диагностика проблем

Начинайте с авторитетного ответа, затем проверяйте TTL, отрицательный кэш, локальные кэши и различия между регионами. Ошибка сети или 5xx означает unknown для этого наблюдения.

Изменение не видно

Запросите авторитетный сервер и убедитесь, что обновлён именно тот hostname и тип записи.

Посмотрите оставшийся TTL у ответа резолвера и сравните его с установленным значением.

Для NXDOMAIN проверьте SOA и его minimum TTL, определяющий срок отрицательного кэширования.

dig @ns1.example.com example.com
# Should show new value

dig example.com | grep -i ttl

dig example.com SOA
# Look at minimum TTL field

Частичное распространение

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

Распространение задержалось

Если спустя несколько дней отдельный ISP продолжает отдавать старую запись, повторно проверьте делегацию и обратитесь к оператору. Публичный DNS может помочь пользователю, но не исправляет источник.

Распространение DNS и TTL кэша

Практические рекомендации

1. Снижайте TTL за 24–48 часов до изменения.

2. Подбирайте TTL с учётом производительности и требуемой гибкости.

3. Проверяйте DNS из нескольких регионов.

4. Не выключайте старую службу до завершения перехода.

5. Записывайте, что изменилось и когда.

6. Тестируйте новые записи до переключения трафика.

7. Предупреждайте пользователей о возможном кратком сбое.

8. Используйте управляемую DNS-инфраструктуру с распределёнными узлами, если это соответствует задаче.

9. Настройте наблюдение и уведомления о смене записей.

10. Подготовьте откат с понятным владельцем и сроком действия.

Контрольный список

Распространение DNS является следствием кэширования, а не отдельной рассылкой записи. Понимание TTL, отрицательного кэша, делегации и различий между резолверами позволяет планировать изменения предсказуемо и не путать временную неизвестность с отсутствием домена.

☐ Lower TTL 24-48 hours before change
☐ Wait for old TTL to expire
☐ Make DNS change
☐ Verify on authoritative nameservers
☐ Check multiple public resolvers
☐ Test from multiple geographic locations
☐ Monitor for 2x TTL duration
☐ Verify no errors reported
☐ Restore higher TTL if desired
☐ Document change completion