Кто на самом деле отвечает на ваш DNS-запрос и почему это редко ваш сервер

MAATRIX

Когда сайт открывается за долю секунды, кажется, что браузер пользователя напрямую спросил ваш сервер: «где искать example.com?» — и тот ответил. На самом деле в подавляющем большинстве случаев ваш авторитативный DNS-сервер вообще не участвует в этом конкретном запросе. Отвечает кеш чужого резолвера — провайдера пользователя или публичного DNS вроде 1.1.1.1 или 8.8.8.8. Разберёмся, кто в этой цепочке кто, зачем нужен каждый узел и что из этого следует для скорости и надёжности вашего сайта.

Три роли, которые легко перепутать

В DNS-резолвинге участвуют минимум три разные сущности, и путаница между ними — источник половины непониманий вокруг DNS.

Stub-резолвер — это тонкий клиент внутри операционной системы пользователя (или в библиотеке, которую использует браузер). Он не умеет ходить по интернету и опрашивать серверы сам. Всё, что он делает — берёт адрес из настроек сети (DHCP от провайдера, вручную заданный 8.8.8.8, или системный DNS в macOS/Windows) и отправляет туда один-единственный запрос с флагом «рекурсия разрешена». Дальше вся работа не его.

Рекурсивный резолвер — вот кто реально выполняет работу. Это отдельный сервер (или кластер серверов), который берёт запрос от stub-резолвера и обязуется вернуть готовый ответ, даже если для этого придётся самому сходить в несколько мест по иерархии DNS. Именно рекурсивный резолвер хранит кеш и именно он в 9 случаях из 10 «отвечает» пользователю — просто потому что нужная запись у него уже есть с прошлого раза, когда кто-то другой (сосед по провайдеру, другой клиент того же публичного DNS) запрашивал тот же домен.

Авторитативный сервер — это тот сервер, который вы, как владелец домена, настроили и на котором лежат ваши A/AAAA/MX/TXT-записи. Он ничего не кеширует и не ходит никуда сам — он просто честно отвечает на вопрос «что у тебя записано про example.com», если этот вопрос до него вообще долетел. Долетает он туда далеко не при каждом обращении пользователя к сайту — только когда ни у одного рекурсивного резолвера на пути нет свежей записи в кеше.

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

Кто такой рекурсивный резолвер на практике

Когда пользователь настраивает сеть, у него почти всегда указан один из вариантов:

• DNS-сервер провайдера — назначается автоматически по DHCP, физически стоит в сети провайдера или у его аплинка;
• публичный резолвер — 1.1.1.1 (Cloudflare), 8.8.8.8 (Google), 9.9.9.9 (Quad9) и десятки менее известных;
• корпоративный DNS-сервер — в офисе, часто с собственными политиками фильтрации;
• локальный кеширующий резолвер на самой машине — например systemd-resolved в Linux или DNS-over-HTTPS клиент в браузере, который сам держит небольшой кеш перед тем как пойти к вышестоящему резолверу.

Важно: во всех этих случаях сервер, к которому реально идёт запрос, физически принадлежит не вам, а кому-то другому — провайдеру пользователя, Cloudflare, Google. Он обслуживает не только вашего посетителя, а тысячи или миллионы других клиентов одновременно. И у него есть кеш, общий для всех этих клиентов (если только это не DNS-over-HTTPS с приватностью на уровне отдельного устройства — но кеш на самом резолвере всё равно общий).

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

Путь запроса, если кеша нигде нет

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

1. Stub-резолвер пользователя отправляет запрос своему рекурсивному резолверу с флагом RD (recursion desired) — «сходи и разберись, мне нужен готовый ответ».
2. Рекурсивный резолвер проверяет собственный кеш. Записи нет — начинает рекурсию. Первым делом он идёт к одному из корневых серверов (root servers, их адреса зашиты в него как root hints — 13 логических адресов, за которыми на деле стоят сотни физических машин через anycast).
3. Корневой сервер не знает, где лежит example.com, но знает, кто отвечает за зону .com — и возвращает не ответ, а делегирование: список NS-серверов для .com (referral, без рекурсии — корневой сервер сам никогда никуда не ходит за вас).
4. Резолвер идёт к одному из TLD-серверов .com, спрашивает про example.com. TLD-сервер тоже не знает финальный IP — он знает, кто авторитативен именно для домена example.com, и возвращает делегирование дальше: список NS-записей, которые вы прописали при регистрации домена (например ns1.yourhoster.net, ns2.yourhoster.net).
5. Резолвер наконец идёт к одному из этих авторитативных серверов — и вот только на этом шаге впервые задействуется инфраструктура, которую контролируете вы. Авторитативный сервер отвечает без всякой рекурсии: «A-запись example.com — вот такой IP, TTL — вот столько секунд».
6. Резолвер складывает ответ в свой кеш на время TTL и возвращает его вашему пользователю.

Весь этот путь — от рекурсивного резолвера до корня, до TLD, до вашего NS — происходит один раз на каждую уникальную комбинацию «имя + тип записи», а не на каждого пользователя. Всё, что случится с этой записью после — это уже раздача из кеша, минуя вас полностью, пока не истечёт TTL.

Почему кеш — это и есть реальный ответчик

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

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

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

Обратная сторона: раз реальный «источник ответа» для конкретного пользователя — чужой кеш, вы не видите напрямую, сколько людей резолвят ваш домен и как часто. Логи авторитативного сервера показывают только те запросы, которые дошли до вас — то есть промахи чужих кешей, а не полную картину обращений пользователей к сайту.

TTL — единственный рычаг, которым вы управляете чужим кешем

Раз вы не можете напрямую заставить резолвер провайдера сбросить кеш вашей записи, единственный инструмент влияния — TTL (time to live), который вы сами прописываете в зоне рядом с каждой записью. Это число секунд, на которое любой резолвер имеет право хранить и раздавать ответ, не спрашивая вас повторно.

Практический компромисс здесь простой и без него никуда:

• Большой TTL (например, сутки) снижает нагрузку на ваш авторитативный сервер и ускоряет резолвинг для пользователей — потому что чаще запрос обслуживается локальным кешем без похода к вам. Цена — если вы меняете IP (переезд на новый сервер, смена дата-центра), часть пользователей ещё долго будет ходить по старому адресу, пока их резолвер не решит, что кеш устарел.
• Маленький TTL (минуты) даёт вам возможность быстро переключить трафик — полезно перед миграцией, при отказоустойчивом DNS-переключении на резервный сервер. Цена — резолверам приходится чаще ходить к вашему авторитативному серверу заново, то есть больше трафика и чуть больше задержки для части пользователей, у которых кеш как раз протух.

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

Что это значит на практике для скорости и надёжности

Из всей этой механики вытекает несколько практических выводов, которые стоит держать в голове при эксплуатации сайта или сервиса.

Скорость первого визита отличается от скорости повторного. Первый пользователь с конкретного резолвера получает ответ медленнее — резолверу приходится пройти всю цепочку от корня до вашего NS. Все следующие пользователи того же резолвера получают мгновенный ответ из кеша, пока TTL не истёк. Это одна из причин, почему синтетические замеры «время до первого байта» так сильно скачут в зависимости от того, тёплый кеш у измеряющего узла или холодный.

Надёжность вашего авторитативного DNS важна непропорционально его нагрузке. Даже если по факту к вашему серверу приходит небольшая доля от общего числа резолвов в мире (основную массу гасят чужие кеши), в момент, когда TTL по всему миру одновременно истекает или резолверы массово идут за свежей записью, ваш авторитативный сервер обязан ответить. Если он недоступен именно в этот момент — эффект будет куда шире, чем «немного пользователей не достучались», потому что от него зависят десятки и сотни разных резолверов сразу, каждый со своей аудиторией.

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

Публичные резолверы у пользователей — фактор, который вы не контролируете, но можете учитывать. Разные резолверы по-разному относятся к TTL (некоторые ограничивают его сверху, некоторые снизу), по-разному кешируют ошибочные ответы, по-разному ведут себя при недоступности вашего NS. На это нельзя повлиять напрямую, но можно проверять поведение вашей зоны через несколько разных публичных резолверов, а не только через локальный, чтобы не делать выводы по одной точке наблюдения.

Как увидеть всю цепочку своими глазами

Разница между «спросить резолвер» и «спросить авторитативный сервер напрямую» видна прямо в командной строке.

Обычный запрос — идёт к системному резолверу (тому самому, который скорее всего просто отдаст готовый кеш):

dig example.com A

Тот же запрос, но явно к конкретному резолверу — полезно, чтобы сравнить, что отдаёт кеш разных резолверов:

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

Запрос напрямую к вашему авторитативному серверу, в обход всех кешей — обратите внимание на флаг +norecurse, который явно говорит «не пытайся резолвить рекурсивно, просто ответь тем, что у тебя есть в зоне»:

dig @ns1.yourhoster.net example.com A +norecurse

Самое наглядное — полная трассировка всей иерархии от корня до вашего NS, ровно тот путь, который проходит резолвер при холодном кеше:

dig +trace example.com A

Вывод +trace покажет по шагам: сначала ответ одного из корневых серверов с делегированием на .com, затем ответ TLD-сервера .com с делегированием на ваши NS-записи, и, наконец, ответ вашего авторитативного сервера с самой A-записью. Полезно смотреть на поле TTL в каждой строке ответа — именно оно объясняет, как долго конкретно эта запись будет раздаваться из кеша резолверов без повторного похода к вам.

Ещё один полезный трюк — посмотреть, кто у домена вообще прописан авторитативным:

dig example.com NS

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

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

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