Как DNS-запрос обходит полмира за 40 миллисекунд

MAATRIX

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

Из чего состоит «резолвинг» домена

Когда вы открываете example.com, браузеру нужен IP-адрес — DNS существует именно для перевода имени в адрес. Но браузер сам ничего не резолвит: он идёт к операционной системе, та — к настроенному резолверу (обычно это либо резолвер вашего провайдера, либо публичный сервис вроде 1.1.1.1 или 8.8.8.8, либо локальный кеширующий резолвер вроде systemd-resolved на Linux).

Резолвер — это первое звено, с которым имеет дело ваше устройство, и одновременно первый уровень кеша. Если кто-то до вас (в том числе вы сами минуту назад) уже спрашивал про этот домен, резолвер отдаст готовый ответ из памяти, не обращаясь никуда дальше. Именно это и создаёт ощущение мгновенности: в подавляющем большинстве случаев ответ уже лежит в кеше на одном из промежуточных уровней, и полная цепочка запросов не нужна.

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

Путь запроса к серверу, который видит домен впервые

Если ответа в кеше нет, резолвер должен пройти иерархию DNS сверху вниз:

1. Корневые серверы (root servers). Их 13 логических адресов (a.root-servers.net — m.root-servers.net), но физически за каждым стоит десятки anycast-узлов по всему миру — запрос уходит на ближайший географически. Корневой сервер не знает IP домена, зато знает, какие серверы отвечают за зону .com, .ru, .io и так далее, и отправляет резолвер туда.
2. TLD-серверы (top-level domain). Для .com это, например, инфраструктура Verisign, для .ru — координационный центр доменов .RU/.РФ. Они тоже не знают конечный IP, но знают, какие NS-серверы обслуживают конкретно ваш домен — эта информация приходит из delegation-записей, которые выставляет регистратор при регистрации домена.
3. Авторитативный NS-сервер домена. Вот это уже сервер, который знает всё: A-запись, MX, TXT, CNAME — всё, что вы прописали в зоне. Именно он и отдаёт финальный ответ: IP-адрес.

Каждый из этих трёх переходов может физически означать запрос на другой континент — резолвер обычно выбирает географически ближайший узел на каждом уровне, но авторитативный сервер вашего домена может стоять там, где его разместил хостинг-провайдер. Если вы арендуете VPS и держите свой сайт и NS-сервер (например, PowerDNS) в одном дата-центре, то последний прыжок будет коротким. Если авторитативные серверы разбросаны по разным регионам — резолвер выберет тот, что ответит быстрее, но гарантий тут нет.

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

Рекурсивный запрос vs итеративный: кто кому должен

Тут часто путают роли, а разница принципиальная:

• Рекурсивный запрос — это то, что делаете вы (точнее, ваше устройство) в сторону резолвера. Вы говорите: «дай мне финальный IP, а как ты его получишь — не моё дело». Резолвер обязан вернуть готовый ответ или ошибку.
• Итеративные запросы — это то, что резолвер делает дальше, ко всем остальным серверам (корневым, TLD, авторитативным). Каждый из них отвечает по принципу «я не знаю финальный ответ, но вот кто знает больше» — и передаёт эстафету. Ни корневой, ни TLD-сервер не обязаны и не будут ходить дальше сами.

Разница важна практически: корневые и TLD-серверы физически не выдержали бы нагрузку, если бы каждый рекурсивный запрос от каждого клиента в мире долбил их напрямую. Поэтому вся «тяжёлая» рекурсия сосредоточена на резолверах провайдеров и публичных DNS-сервисах — а корневая и TLD-инфраструктура отвечает короткими итеративными подсказками и держит нагрузку за счёт anycast и огромного количества edge-узлов.

TTL и кеш на каждом уровне: почему это обычно быстро

TTL (Time To Live) — это число секунд, которое администратор зоны прописывает у каждой записи. Оно говорит любому резолверу: «можешь хранить этот ответ у себя столько-то секунд, не спрашивай меня снова раньше времени». Типичные значения TTL для A-записей — от 300 секунд (5 минут) до 86400 (сутки), но конкретное число — решение того, кто администрирует зону, единого стандарта нет.

Кеш работает многослойно:

• в браузере (у некоторых браузеров есть свой короткий DNS-кеш);
• в операционной системе (тот же systemd-resolved или nscd);
• у локального резолвера дома или в офисе (роутер часто тоже кеширует);
• у резолвера провайдера или у публичного сервиса (1.1.1.1, 8.8.8.8, Quad9) — это самый нагруженный и самый «выгодный» с точки зрения экономии запросов уровень, потому что за одним резолвером сидят тысячи пользователей одновременно.

Из-за этого многослойного кеширования до корневых и TLD-серверов реальный трафик доходит на порядки реже, чем количество DNS-запросов, которые совершают конечные пользователи. Первый человек, спросивший про домен, «прогревает» кеш резолвера — а все остальные в его сети получают ответ мгновенно, не уходя дальше локального резолвера.

Обратная сторона TTL — при смене IP-адреса домена (например, при переезде на новый VPS) старые записи будут жить в чужих кешах ровно столько, сколько было прописано в TTL до изменения. Если вы планируете миграцию, разумно заранее — за сутки-двое — снизить TTL записи до 300 секунд, дождаться, пока старое значение вытеснится из кешей, поменять IP, и только потом вернуть TTL к обычному значению. Подробнее о типичных граблях при переезде — в статье про проблемы с DNS после переезда.

dig +trace: смотрим всю цепочку своими глазами

Проще всего понять всю механику — не по картинкам, а вживую пройти цепочку той же командой, которой пользуется резолвер:

dig +trace example.com

Утилита dig (часть пакета dnsutils на Debian/Ubuntu или bind-utils на RHEL/AlmaLinux) в режиме +trace начинает с корневых серверов и последовательно показывает каждый переход: сначала ответ от корня со списком NS для .com, затем ответ от TLD-сервера со списком NS для example.com, и наконец — ответ от авторитативного сервера с финальной A-записью. Каждая строка вывода — это отдельный итеративный запрос, и вы буквально видите ту иерархию, которую мы разобрали выше.

Полезные варианты команды:

# Обычный запрос через ваш резолвер (использует кеш)
dig example.com

# Запрос конкретно у авторитативного сервера, минуя кеш
dig @ns1.example.com example.com

# Проверка, какие NS-серверы делегированы для зоны
dig example.com NS +short

# Проверка TTL текущей записи прямо сейчас
dig example.com A

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

Если под рукой нет dig, похожую (хоть и менее подробную) информацию покажет nslookup example.com или host example.com — они есть почти в любом дистрибутиве по умолчанию.

Домен не резолвится: диагностика по шагам

Когда сайт не открывается и подозрение падает на DNS, идите по шагам, а не наугад:

1. Проверьте, действительно ли это DNS, а не сеть или сервер. ping example.com — если IP резолвится, но пинг не идёт, проблема не в DNS, а в сети или в фаерволе. Полезно сравнить с диагностикой тормозящего сайта на VPS — там разбор для случая, когда DNS отработал, а дальше не так.
2. Проверьте делегирование NS у регистратора. dig example.com NS +short должен вернуть те же NS-серверы, что указаны в панели регистратора домена. Если список не совпадает или пустой — делегирование либо не настроено, либо ещё не применилось после смены.
3. Спросите напрямую у авторитативного сервера, а не через кеш. dig @ns1.example.com example.com A покажет, отдаёт ли сам авторитативный сервер верный ответ. Если да — проблема в промежуточном кеше (см. следующий пункт), если нет — проблема в зоне на самом NS-сервере.
4. Проверьте, не залип ли локальный кеш. На Linux с systemd-resolved: resolvectl flush-caches. На роутере иногда достаточно перезагрузки. На Windows — ipconfig /flushdns. Если после сброса кеша всё заработало — дело было в устаревшей записи, которая ещё не истекла по TTL.
5. Проверьте сам резолвер, которым вы пользуетесь. Временный сбой у резолвера провайдера — не редкость. Быстрый способ исключить эту причину — попробовать резолвить через другой резолвер: dig @1.1.1.1 example.com и dig @8.8.8.8 example.com. Если оба отвечают верно, а ваш обычный резолвер — нет, дело в нём, а не в вашем домене.
6. Если сайт открывается по IP, но не по домену — это отдельный частый случай, разобранный в статье «сайт открывается по IP, но не по домену»: обычно дело либо в самой A-записи, либо в конфигурации веб-сервера, который не узнаёт заголовок Host.

Если вы только настраиваете домен с нуля на новом VPS, весь путь — от регистрации NS у регистратора до первой рабочей A-записи — по шагам расписан в статье про настройку домена и DNS с нуля на Ubuntu 24.04.

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