Рекурсивный DNS-резолвер: как ищет ответ по цепочке серверов

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

Этот же сервер часто называют резолвером, кэширующим DNS-сервером или просто DNS-сервером провайдера. Обычное устройство получает его адрес автоматически при подключении к сети по DHCP, поэтому большинство людей никогда не выбирает его сознательно.

Допустим, резолвер впервые видит имя host.example.com. Сначала он обращается к одному из корневых серверов и узнаёт, кто отвечает за зону com. Затем спрашивает сервер зоны com, кто отвечает за example.com. Наконец обращается к авторитетному серверу этого домена и получает искомую запись. Три перехода: корень, зона верхнего уровня, сервер домена. Подробнее о каждом звене читайте на страницах про kornevye-dns-servery и avtoritetnyy-dns-server.

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

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

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

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

Если резолвер недоступен, страницы «не открываются», хотя соединение с интернетом есть: по IP-адресу узлы отвечают, а имена не разрешаются. Это классический признак проблем именно с DNS.

В Windows команда ipconfig /all показывает строку DNS-серверов для каждого адаптера. В Linux с systemd-resolved помогает resolvectl status, в macOS раздел DNS в сетевых настройках или команда scutil --dns. Утилиты nslookup и dig при выводе тоже сообщают, какой сервер ответил. Если адрес выглядит как адрес вашего роутера, чаще всего роутер лишь пересылает запросы вышестоящему резолверу.

Различать полезно и настройки на уровне браузера: при включённом DNS через HTTPS браузер может использовать собственный резолвер, отличающийся от системного.

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

Независимо от выбора, стоит знать, что резолвер способен ограничивать ответы: например, блокировать известные вредоносные домены по спискам. Это полезная функция, когда она задумана как защита, и повод для внимания, когда меняет ответы без вашего ведома. Сравнивайте результаты нескольких резолверов, если сайт открывается не так, как ожидается.

Проверить, что именно ваш резолвер кэширует, можно сравнением времени двух подряд идущих запросов одного и того же имени: второй обычно заметно быстрее. Различие особенно хорошо видно в выводе dig в строке Query time, где значения измеряются миллисекундами.