Полный процесс DNS-резолвинга — сколько шагов от браузера до корневого сервера?

1. Полная схема из 8 шагов

┌─────────────────────────────────────────────────────────────┐
│  Браузер (Chrome / Firefox) — вводим google.com              │
└────────────────┬────────────────────────────────────────────┘
                 │ ① DNS-кэш браузера (Chrome ~60 с)
                 ↓ промах
┌─────────────────────────────────────────────────────────────┐
│  Stub-резолвер ОС + системный DNS-кэш                        │
└────────────────┬────────────────────────────────────────────┘
                 │ ② Промах системного кэша → UDP-запрос на роутер
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  DNS-форвардинг домашнего роутера + кэш роутера              │
└────────────────┬────────────────────────────────────────────┘
                 │ ③ Промах кэша роутера → пересылка рекурсивному резолверу провайдера
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  Рекурсивный резолвер провайдера / публичный (1.1.1.1 / 8.8.8.8 / 223.5.5.5) │
│  Попадание в кэш: ответ сразу, весь процесс занимает 1-5 мс  │
│  Промах кэша: переход к «полному поиску» ниже                │
└────────────────┬────────────────────────────────────────────┘
                 │ ④ Спрашивает корневой NS: «где google.com?»
                 ↓
        13 кластеров корневых DNS-серверов (a~m.root-servers.net)
                 │ ⑤ Ответ: «Не знаю, спросите NS зоны .com: a.gtld-servers.net»
                 ↓
        Авторитетные серверы TLD .com (Verisign)
                 │ ⑥ Ответ: «У меня тоже не всё, спросите NS google.com: ns1.google.com»
                 ↓
        Авторитетные серверы google.com (их обслуживает сама Google)
                 │ ⑦ Ответ: «A-запись google.com = 142.250.x.x»
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  ⑧ Рекурсивный резолвер кэширует ответ (на время TTL) и      │
│     возвращает его клиенту — каждый уровень по пути          │
│     тоже сохраняет свою копию                                │
└─────────────────────────────────────────────────────────────┘

Главное: в реальной жизни полные 8 шагов почти никогда не выполняются. IP-адреса крупных сайтов почти всегда уже лежат в кэше рекурсивного резолвера, поэтому обычный пользователь получает ответ уже на шаге ④. Полный путь запускают только редкие домены, давно не посещавшиеся сайты, истёкший TTL или недавно зарегистрированные домены.

2. 5 уровней DNS-кэширования

Уже при проектировании DNS в 1983 году учитывался один факт: запросов в 100 000 раз больше, чем изменений. Поэтому кэш есть везде, и каждый уровень хранит данные в течение TTL (Time To Live).

3. Рекурсивные и итеративные запросы — ключевые понятия

3.1 Рекурсивный запрос

Клиент (браузер / stub ОС) говорит рекурсивному резолверу провайдера: «Найди мне IP google.com — как именно, меня не волнует». Рекурсивный резолвер обязан выполнить весь поиск и вернуть итоговый результат.

3.2 Итеративный запрос

Когда рекурсивный резолвер общается с корневыми, TLD- и авторитетными серверами, этот обмен итеративный: он спрашивает корень, корень отвечает «спроси .com», он идёт к .com, .com отвечает «спроси google», он идёт к google. Каждый шаг проходит только один уровень — корень вовсе не делает всю работу за него.

4. Проверьте сами — dig +trace

dig +trace принудительно выполняет полный итеративный поиск и показывает каждый шаг:

$ dig +trace cleanip.io

; <<>> DiG 9.10.6 <<>> +trace cleanip.io
;; global options: +cmd

; ① Шаг 1 — запрос к корню (.)
.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
... (13 корневых NS-записей)
;; Received 525 bytes from 127.0.0.53#53 in 5 ms

; ② Шаг 2 — запрос к TLD .io
io.                     172800  IN      NS      a0.nic.io.
io.                     172800  IN      NS      b0.nic.io.
... (4 NS зоны .io)
;; Received 822 bytes from 198.41.0.4#53(a.root-servers.net) in 121 ms

; ③ Шаг 3 — запрос к авторитетным серверам cleanip.io
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 109 bytes from 156.154.150.6#53(a0.nic.io) in 53 ms

; ④ Наконец получаем ответ
cleanip.io.             300     IN      A       104.21.x.x
cleanip.io.             300     IN      A       172.67.x.x
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 154 bytes from 173.245.59.108#53(nolan.ns.cloudflare.com) in 12 ms

Разбор:

• Весь процесс занял 5 + 121 + 53 + 12 = 191 мс — первый «холодный» запрос действительно медленный
• Но повторный запрос того же домена секундой позже занимает всего 1-2 мс, потому что ответ уже есть в рекурсивном кэше провайдера (TTL 300 секунд)
• 104.21.x.x / 172.67.x.x — адреса CDN Cloudflare: реальный IP origin-сервера нашего сайта скрыт за CDN

5. TTL — сколько на самом деле живёт кэш

TTL (Time To Live) — это поле, в котором авторитетный сервер сообщает всем рекурсивным резолверам: «кэшируйте это не дольше указанного времени»; значение задаётся в секундах.

Важно: TTL — это «максимальное время кэширования»: отдельные резолверы могут очистить кэш раньше, но продлить его не могут. Поэтому даже при TTL 1 час на авторитетном сервере некоторые резолверы могут повторить запрос уже через 10 минут.

Подвох: перед сменой IP сначала уменьшите TTL (1-5 минут) и переключайтесь только после того, как старый TTL полностью истечёт, — иначе часть пользователей ещё больше часа будет попадать на старый IP.

6. Шпаргалка по типам DNS-записей

7. Оптимизация DNS — как ускорить разрешение имён

7.1 Выберите ближайший рекурсивный резолвер

Материковый Китай: 223.5.5.5 (Alibaba) / 119.29.29.29 (DNSPod) быстрее всего разрешают китайские сайты. В других странах: 1.1.1.1 (Cloudflare, самое широкое покрытие anycast) / 8.8.8.8 (Google). Подробнее см.каталог публичных DNS-резолверов.

7.2 Включите DoH (DNS-over-HTTPS)

Шифрование DNS-запросов через HTTPS не даёт провайдеру видеть или подменять их (защищает от перехвата NXDOMAIN). Chrome, Firefox и Edge поддерживают его — достаточно включить в настройках.

7.3 Прогрев заранее (DNS Prefetch)

Добавьте <link rel="dns-prefetch" href="//api.example.com"> в <head> сайта, и браузер разрешит имя в свободное время — к моменту настоящего запроса ответ уже будет в кэше.

7.4 Используйте CDN + Anycast NS

Разместите авторитетные NS на Anycast (Cloudflare / Route 53), чтобы пользователи по всему миру обращались к ближайшему узлу, — задержка шага ③ сократится со 100ms до 10ms.

7.5 Задайте разумный TTL

Для записей, которые меняются редко (NS / MX), ставьте длинный TTL (1-7 дней); для A-записей, которые может понадобиться переключить, — короткий (5-60 минут).

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

8.1 Я изменил DNS, но ничего не поменялось — почему?

Сначала выясните текущий TTL. После изменения DNS все рекурсивные резолверы продолжают возвращать старый IP, пока не истечёт старый TTL. «Глобальное распространение» обычно занимает около 2× TTL (с учётом того, что резолверы не синхронизированы между собой).

• Клиент: ipconfig /flushdns (Windows) / sudo killall -HUP mDNSResponder (macOS)
• Ожидание истечения кэша публичного рекурсивного резолвера: у 1.1.1.1 / 8.8.8.8 есть собственные инструменты «purge» для ручной очистки

8.2 У одних пользователей открывается, у других нет — отравление DNS

Типично при доступе к зарубежным сайтам из материкового Китая: GFW внедряет поддельные DNS-ответы, провайдеры перехватывают запросы. Переход на DoH (шифрованный DNS в браузере) позволяет обойти большую часть отравления DNS.

8.3 Через сколько после регистрации домен начинает работать?

После регистрации реестр TLD публикует ваши NS-записи на авторитетных серверах верхнего уровня для .com / .net и т. д. — обычно это занимает от 15 минут до 24 часов. Для домена .cn / .com.cn может потребоваться регистрация ICP, прежде чем он начнёт разрешаться в материковом Китае.