Как работает DNS-разрешение: пошаговое руководство

Как работает DNS-разрешение: пошагово

Когда вы вводите www.example.com в браузере, он не может подключиться непосредственно к этому имени. Сначала ему нужен сетевой адрес — обычно IPv4- или IPv6-адрес, — по которому можно связаться с сервером назначения. DNS-разрешение — это процесс получения DNS-данных, связанных с доменным именем.

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

Краткий ответ

DNS-разрешение преобразует запрос доменного имени в DNS-записи, необходимые приложению. Обычно устройство отправляет запрос рекурсивному резолверу. Если у него уже есть актуальный ответ в кэше, он может вернуть его сразу. В противном случае резолвер обращается к DNS-иерархии — как правило, начиная с информации о корневой зоне, затем переходя к соответствующему домену верхнего уровня и в итоге к авторитетному DNS-серверу, — получает ответ и сохраняет его в кэше для последующего использования. (rfc-editor.org)

Ключевые факты

Компонент	Роль
Stub resolver	Отправляет DNS-запросы от имени приложения или операционной системы
Recursive resolver	Находит окончательный ответ для клиента
Root server	Направляет резолвер к соответствующему домену верхнего уровня
TLD server	Направляет его к авторитетным серверам домена
Authoritative server	Предоставляет авторитетные DNS-данные для соответствующей зоны
TTL	Определяет, как долго DNS-запись обычно может храниться в кэше

Современная DNS-терминология различает stub resolver, который полагается на другой резолвер для выполнения полного процесса разрешения, и recursive resolver, который выполняет рекурсивное разрешение от имени клиента. (rfc-editor.org)

Что такое DNS-разрешение?

Domain Name System — это распределённая система имён. Разные DNS-серверы хранят авторитетную информацию для разных частей пространства доменных имён. Резолвер скрывает большую часть этой распределённой структуры от приложений: приложение задаёт вопрос, а резолвер выполняет работу, необходимую для поиска нужных DNS-записей. (rfc-editor.org)

Например, браузеру могут понадобиться адреса для:

www.example.com

Он может запросить запись A для IPv4, запись AAAA для IPv6 или обе сразу. Запись AAAA содержит один IPv6-адрес. (rfc-editor.org)

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

Как работает разрешение DNS

Предположим, пользователь хочет открыть:

www.example.com

и подходящего ответа ещё нет в кэше.

1. Приложение запрашивает разрешение имени

Браузер или другое приложение просит системный резолвер получить DNS-информацию о www.example.com.

Во многих системах этот локальный компонент работает как stub resolver. Он не проходит самостоятельно всю DNS-иерархию. Вместо этого он отправляет запрос рекурсивному резолверу, настроенному операционной системой, интернет-провайдером, корпоративной сетью, VPN или DNS-сервисом. (rfc-editor.org)

2. Рекурсивный резолвер проверяет кэш

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

Если такой ответ есть, разрешение может завершиться на этом этапе.

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

3. Резолвер обращается к корневой зоне

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

Root-сервер обычно не возвращает окончательный IP-адрес для www.example.com. Вместо этого он направляет резолвер к серверам, отвечающим за нужный домен верхнего уровня — в данном случае .com.

Такая модель перенаправлений — фундаментальная часть DNS-разрешения. RFC 1035 описывает, что резолвер может получить либо запрошенную информацию, либо referral — указание обратиться к другому серверу имён. (rfc-editor.org)

4. Резолвер запрашивает TLD

Затем резолвер обращается к соответствующему серверу .com с запросом об example.com.

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

Теперь резолвер знает, куда отправить запрос, относящийся непосредственно к этому домену.

5. Авторитетный сервер возвращает ответ

Резолвер обращается к авторитетному серверу соответствующей DNS-зоны.

Если у сервера есть запрошенные данные, он может вернуть нужную запись. Например:

www.example.com.  3600  IN  A  192.0.2.10

Фактические значения зависят от конфигурации домена.

Ответ также может содержать CNAME. В DNS записи CNAME используются для указания, что одно имя является алиасом другого канонического имени. В таком случае резолверу может потребоваться продолжить разрешение уже для этого целевого имени. (rfc-editor.org)

6. Ответ сохраняется в кэше

DNS resource records содержат TTL — time to live, который определяет, как долго кэшированные данные могут использоваться повторно до того, как потребуется снова обратиться к их источнику. (rfc-editor.org)

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

После этого результат возвращается клиенту, и приложение может перейти к следующему сетевому этапу, например установить TCP- или QUIC-соединение.

Почему TTL важен

TTL объясняет значительную часть того, что обычно называют DNS propagation.

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

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

INTERNAL LINK: Как работает распространение DNS

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

Отрицательные ответы тоже кэшируются

DNS-кэширование применяется не только к успешным ответам.

Авторитетный сервер может сообщить, что имя не существует, обычно с помощью ответа NXDOMAIN. Стандарты DNS определяют negative caching, чтобы резолверы могли временно сохранять такие ответы и не обращаться повторно к авторитетной инфраструктуре по поводу одного и того же отсутствующего имени. (rfc-editor.org)

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

DNS и производительность

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

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

При анализе web performance важно различать:

кэш браузера или операционной системы;
кэш рекурсивного резолвера;
время ответа авторитетного DNS-сервера;
сетевую задержку до выбранного резолвера;
незакэшированное разрешение через DNS-иерархию.

Один DNS-бенчмарк не обязательно отражает опыт всех реальных пользователей.

INTERNAL LINK: DNS и производительность сайта

Как проверить процесс разрешения

Утилита dig полезна для анализа DNS-ответов.

Обычный запрос:

dig example.com A

Запрос IPv6:

dig example.com AAAA

Чтобы проследить путь делегирования:

dig +trace example.com A

В документации BIND указано, что +trace начинает с корневой зоны и следует по referrals с помощью итеративных запросов, показывая серверы, задействованные в разрешении имени. (bind9.readthedocs.io)

Это полезно при диагностике, например, таких ситуаций:

Root works
→ TLD delegation works
→ authoritative server fails

или:

Authoritative server returns the correct record
→ recursive resolver still has an older cached answer

Есть важное ограничение: dig +trace не обязательно воспроизводит именно тот путь, который использует браузер. Браузеры, операционные системы, VPN, корпоративные сети или настройки encrypted DNS могут использовать другие резолверы.

Распространённые заблуждения

«DNS всегда сначала обращается к root-серверу». Нет. Кэш может содержать окончательный ответ или достаточно информации о делегировании, чтобы начать разрешение с более низкого уровня иерархии.

«Root-сервер хранит IP-адрес каждого сайта». Нет. DNS — распределённая система. Root-серверы в первую очередь помогают направить разрешение к соответствующей TLD-инфраструктуре.

«После изменения DNS все сразу увидят новое значение». Не обязательно. Уже закэшированные ответы могут использоваться до истечения соответствующего TTL.

«DNS обычно возвращает только IP-адрес». Нет. DNS поддерживает множество типов resource records. Даже разрешение адреса может включать CNAME-записи до того, как будет получен окончательный ответ A или AAAA.

Безопасность и приватность DNS

DNSSEC и encrypted DNS решают разные задачи.

DNSSEC предоставляет механизмы аутентификации DNS-данных и проверки их целостности. Он не обеспечивает конфиденциальность; спецификация DNSSEC явно разделяет аутентификацию и целостность с одной стороны и секретность — с другой. (rfc-editor.org)

DNS over TLS (DoT) использует TLS для обеспечения приватности DNS-трафика, а DNS over HTTPS (DoH) передаёт DNS-запросы и ответы через HTTPS. (rfc-editor.org)

Поэтому эти технологии нельзя считать взаимозаменяемыми.

INTERNAL LINK: DNSSEC vs DoH vs DoT

Реализации DNS также должны поддерживать как UDP, так и TCP. RFC 7766 обновил базовые требования: универсальные DNS-реализации должны поддерживать оба транспорта. (rfc-editor.org)

FAQ

Что делает DNS-разрешение?

Оно получает DNS-информацию, связанную с доменным именем. Для веб-трафика это обычно включает поиск IPv4- или IPv6-адреса, который браузер может использовать для подключения к хосту.

Каждый DNS-запрос доходит до авторитетного сервера?

Нет. Актуальный ответ из кэша может полностью удовлетворить запрос без нового обращения к авторитетному серверу.

Что такое рекурсивный DNS-резолвер?

Это резолвер, который выполняет рекурсивное разрешение для клиента, находя окончательный ответ вместо простого возврата referrals, если рекурсия доступна. (rfc-editor.org)

Чем рекурсивный DNS отличается от авторитетного?

Рекурсивный резолвер находит ответы для клиентов. Авторитетный сервер предоставляет авторитетные DNS-данные для зон, за которые он отвечает.

Почему могут продолжать появляться старые DNS-записи?

У резолвера может всё ещё храниться предыдущий ответ в кэше. TTL определяет, как долго resource record обычно может оставаться в кэше до того, как потребуется снова обратиться к его источнику. (rfc-editor.org)

Шифрует ли DNSSEC DNS-запросы?

Нет. DNSSEC обеспечивает механизмы аутентификации источника DNS-данных и проверки их целостности, но не конфиденциальность. За приватность DNS-транспорта отвечают зашифрованные протоколы, такие как DoT и DoH. (rfc-editor.org)

Итог

DNS-разрешение правильнее воспринимать как распределённый процесс поиска, а не как простое преобразование домена в IP-адрес одной центральной системой.

Клиент обычно обращается к рекурсивному резолверу. Кэш может сразу предоставить ответ. Если требуется дополнительная информация, резолвер следует по DNS-иерархии и её referrals, пока не получит авторитетные данные, после чего сохраняет результат в кэше согласно правилам DNS-кэширования.

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

Источники

Paul Mockapetris — RFC 1034: Domain Names — Concepts and Facilities, November 1987. RFC Editor. RFC 1034
Paul Mockapetris — RFC 1035: Domain Names — Implementation and Specification, November 1987. RFC Editor. RFC 1035
Paul Hoffman, Kazunori Fujiwara — RFC 9499: DNS Terminology, March 2024. IETF / RFC Editor. RFC 9499
Mark Andrews — RFC 2308: Negative Caching of DNS Queries, March 1998. RFC Editor. RFC 2308
Roy Arends et al. — RFC 4033: DNS Security Introduction and Requirements, March 2005. IETF / RFC Editor. RFC 4033
Susan Thomson et al. — RFC 3596: DNS Extensions to Support IP Version 6, October 2003. RFC Editor. RFC 3596
John Dickinson et al. — RFC 7766: DNS Transport over TCP — Implementation Requirements, March 2016. IETF / RFC Editor. RFC 7766
Z. Hu et al. — RFC 7858: Specification for DNS over Transport Layer Security (TLS), May 2016. IETF / RFC Editor. RFC 7858
Paul Hoffman, Patrick McManus — RFC 8484: DNS Queries over HTTPS (DoH), October 2018. IETF / RFC Editor. RFC 8484
Internet Systems Consortium — BIND 9 dig documentation, BIND 9.20 documentation. BIND 9 Manual Pages

Как работает DNS-разрешение: пошаговое руководство