Процесс разрешения DNS

В предыдущих уроках мы узнали, что DNS — распределённая система, и доменные имена образуют иерархию. Теперь разберём главное: как именно DNS-резолвер находит IP-адрес по имени. Этот процесс называется разрешением (resolution), и он проходит через несколько серверов за доли секунды.

Кто участвует в разрешении

В процессе участвуют четыре стороны:

Клиент (stub resolver). Твой компьютер или телефон. Он сам не умеет искать — он только спрашивает.
Рекурсивный резолвер (recursive resolver). Сервер, который выполняет всю работу по поиску. Обычно это DNS-сервер провайдера или публичный (Google 8.8.8.8, Cloudflare 1.1.1.1).
Корневые серверы (root). 13 кластеров, знающих адреса TLD-серверов.
Авторитативные серверы (authoritative). Серверы, которые хранят окончательную информацию о домене.

Шаг за шагом: как резолвер находит google.com

Допустим, кэши пусты, и резолвер ничего не знает о google.com. Процесс выглядит так:

Шаг 1: Запрос к корневым серверам. Резолвер спрашивает: «Кто отвечает за зону .com?». Корневой сервер отвечает списком TLD-серверов для .com и их IP-адресами. Сам он про google.com не знает.

Шаг 2: Запрос к TLD-серверам. Резолвер выбирает один из .com-серверов и спрашивает: «Кто отвечает за google.com?». Сервер .com отвечает списком авторитативных DNS-серверов (name servers) для google.com — обычно это ns1.google.com, ns2.google.com и т.д. — и их IP-адресами.

Шаг 3: Запрос к авторитативным серверам. Резолвер спрашивает у ns1.google.com: «Какой IP-адрес у google.com?». Авторитативный сервер отвечает: «A-запись для google.com: 142.250.185.206».

Шаг 4: Ответ клиенту. Резолвер возвращает IP-адрес операционной системе, та — браузеру.

Клиент                     Резолвер                Корень          .com TLD      ns1.google.com
  │─── www.google.com? ───→│                         │               │               │
  │                         │─── кто за .com? ──────→│               │               │
  │                         │←─── .com на X.X.X.X ──│               │               │
  │                         │─── кто за google.com? ────────────────→│               │
  │                         │←─── ns1.google.com ──────────────────│               │
  │                         │─── IP google.com? ──────────────────────────────────→│
  │                         │←─── 142.250.185.206 ─────────────────────────────────│
  │←─── 142.250.185.206 ──│                         │               │               │

Рекурсивный vs итеративный запрос

Различают два типа DNS-запросов:

Рекурсивный. «Сделай всю работу за меня и верни готовый ответ». Клиент просит резолвер: «найди мне IP-адрес google.com, не говори "спроси у того-то"». Так клиент общается с резолвером.
Итеративный. «Вот что я знаю, дальше спрашивай сам». Резолвер общается с корневыми, TLD и авторитативными серверами итеративно — каждый говорит: «я не знаю ответа, но знаю, кто знает».

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

Делегирование: как работает распределение

DNS работает через делегирование (delegation). Корень делегирует ответственность за .com TLD-серверам. .com делегирует google.com серверам Google. Google может делегировать mail.google.com другому серверу.

Каждый уровень иерархии отвечает только за свою часть и знает, кому делегированы подуровни. Это как в большой организации: генеральный директор не знает, кто отвечает за конкретный проект в отделе — он знает только руководителей отделов. Руководитель отдела знает руководителей команд. Руководитель команды — конкретных исполнителей.

Что ускоряет процесс

На практике разрешение редко проходит все шаги — работает несколько механизмов ускорения:

Кэш резолвера. Если кто-то недавно уже спрашивал про google.com, ответ сохранён в кэше. Шаги 1–3 пропускаются.
Кэш TLD. Резолвер кэширует адреса TLD-серверов. Запрос к корню нужен только при холодном старте или истечении TTL.
Glue records. Если авторитативные серверы домена находятся внутри самого домена (ns1.google.com для google.com — это петля), TLD-сервер возвращает их IP-адреса в дополнительной секции ответа, экономя один запрос.

Проверь себя

Сколько запросов делает резолвер при «холодном» разрешении нового доменного имени?
Чем рекурсивный запрос отличается от итеративного?
Почему нельзя просто спросить корневой сервер про IP-адрес google.com?

<details> <summary>Ответы</summary>

Минимум три: к корневому серверу (за TLD), к TLD-серверу (за авторитативным), к авторитативному (за ответом). С glue records — может быть два.
Рекурсивный: «сделай всё за меня, верни готовый ответ». Итеративный: «я не знаю, но вот кто может знать — спроси у него». Клиент → резолвер — рекурсивно. Резолвер → DNS-серверы — итеративно.
Корневой сервер не хранит записи конкретных доменов. Он знает только TLD-серверы. Это как спросить у справочной «какой номер у булочной на Тверской» — она не знает, но знает справочную Тверского района (аналогия по аналогии, не точная).

</details>

Что унести с урока

Разрешение DNS проходит цепочку: корень → TLD → авторитативный сервер → ответ.
Рекурсивные запросы — «сделай работу за меня». Итеративные — «вот кто может знать».
Делегирование — ключевой принцип DNS: каждый уровень отвечает за свою зону и знает, кому передал подзоны.
Кэширование на всех уровнях ускоряет повторные запросы.

Мы знаем, как найти IP-адрес. Но какие именно данные хранятся в DNS? В следующем уроке разберём типы DNS-записей — A, AAAA, CNAME, MX, TXT и другие.

Процесс разрешения DNS