Разрешение DNS: путь от запроса до ответа

Разрешение DNS — это процесс превращения доменного имени в данные, которые нужны приложению, чаще всего в IP-адрес. Когда браузеру нужно подключиться к www.example.com, он запрашивает результат у локального сетевого стека. Stub-резолвер обычно передаёт вопрос рекурсивному резолверу. У того уже может быть закешированный ответ; если нет, он следует по DNS-перенаправлениям, пока не доберётся до сервера, авторитативного для нужной зоны. Итоговый ответ возвращается по цепочке и может кешироваться на ограниченное время. Процесс распределённый: ни один глобальный сервер не хранит полный набор записей каждого домена.

Запрос начинается с конкретного имени и типа

DNS-вопрос — это не просто «найди этот сайт». Он включает имя и тип записи. Запрос A спрашивает про IPv4; AAAA — про IPv6; MX — про почтовые обменники; NS — про серверы имён. Рекурсивный резолвер по типу решает, какие данные получить и вернуть. Если браузеру нужен веб-адрес, он может запросить и A, и AAAA, тогда как почтовая система запрашивает MX. Запрос не того типа может дать пустой ответ, даже если другие записи для этого имени существуют. Результаты DNS осмысленны лишь тогда, когда сам вопрос ясен.

1. Клиент проверяет свой локальный кеш и настроенный резолвер.
2. Рекурсивный резолвер проверяет свой кеш; при необходимости обращается к корневому серверу.
3. Перенаправление от корневого сервера указывает на серверы нужного домена верхнего уровня.
4. Перенаправление от TLD определяет авторитативные серверы имён домена.
5. Авторитативный ответ возвращается и кешируется на допустимый для него срок.

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

Псевдонимы, кеширование и отрицательные ответы

Если у имени есть CNAME, разрешение может включать ещё одно имя хоста до того, как будет найден адрес. У каждого соответствующего ответа своё поведение кеша, поэтому цепочка может включать записи с разными TTL. Резолвер также может кешировать отрицательные результаты, например факт, что запрошенное имя не существует, на ограниченное время. Это может объяснять, почему новое имя не появляется сразу после создания. Очистка локального кеша затрагивает лишь это устройство или этот уровень; она не стирает закешированные ответы независимых рекурсивных резолверов по всему интернету.

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

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

Разрешение — это процесс, а не однократное чтение базы

Поскольку в разрешении участвуют несколько независимо управляемых серверов, на ответ DNS может влиять не только итоговая запись A или AAAA. Устаревшее делегирование может направить резолвер не к тому авторитету; недоступный авторитативный сервер может вызвать тайм-аут; нарушенная цепочка DNSSEC может заставить валидирующий резолвер отклонить данные; а закешированный отрицательный ответ может задержать появление только что созданного имени. Каждый уровень оставляет разные следы. Сузить причину помогают код ответа, раздел authority, TTL и опрошенный сервер. Собирая диагностику, не пересказывайте тайм-аут как «домена не существует»: это меняет смысл. Сохраняйте точный ответ об ошибке и сравнивайте его с авторитативным запросом. Такой многоуровневый метод ведёт к конкретному исправлению, а не к слепому изменению адресной записи.