DNS: что это и как находится нужный IP-адрес

Что такое DNS, как DNS находит нужный IP-адрес?

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

DNS — это распределённая иерархическая система имён, которая сопоставляет доменные имена с ресурсными записями (например, A/AAAA) и использует кэширование с TTL. Обычно stub-резолвер передаёт запрос рекурсивному резолверу, а тот при отсутствии кэша проходит цепочку: корневые серверы → серверы TLD → авторитативные серверы зоны и получает ответ, который кэшируется на ограниченное время.

DNS — это централизованный каталог, который обслуживается одним главным сервером, а остальные DNS-серверы являются его копиями и обновляются синхронно при каждом изменении. Доменные имена всегда превращаются в один-единственный IP-адрес, поэтому записи CNAME или NS не применяются. Время жизни ответов не используется, так как актуальность гарантируется центральным сервером.

DNS — это протокол шифрования доменных имён, который передаёт запросы только по HTTPS и всегда скрывает домен от сети. Любой DNS-ответ обязательно проверяется DNSSEC клиентом, иначе ответ считается недействительным. Для поиска IP используется один сервер “root”, который хранит полную таблицу соответствий домен → IP для всего интернета.

Теория: что такое DNS

DNS (Domain Name System) — это система доменных имён и набор правил/протоколов, позволяющих получать данные по имени из распределённой базы (часто это “IP по домену”, но не только).
В DNS информация хранится в виде ресурсных записей (Resource Records), у каждой записи есть тип (A, AAAA, CNAME, NS и др.), класс (обычно IN) и TTL — время, в течение которого запись допускается хранить в кэше.
DNS спроектирован как распределённая система с локальным кэшированием, потому что централизованная “единая база всего интернета” плохо масштабировалась бы и стала бы единой точкой отказа.

Основные роли в DNS

Stub-резолвер (на стороне ОС/приложения) формирует запросы и обычно пересылает их на рекурсивный резолвер.
Рекурсивный резолвер выполняет работу “найти ответ”, используя кэш и при необходимости делая серию запросов к другим серверам.
Авторитативные серверы хранят “истину” по своей зоне (zone) и отвечают данными из этой зоны.

Термины “рекурсивный” и “итеративный” описывают стиль обработки запроса: при рекурсии сервер сам продолжает поиск за клиента, при итерации сервер возвращает направление (referral), куда идти дальше.

Иерархия DNS и зоны

Именное пространство DNS — дерево, а ответственность разделена на зоны: часть дерева обслуживается конкретными авторитативными серверами, а делегирование обычно фиксируется записями NS.
Корневая зона обслуживается “root servers” и традиционно описывается как 13 именованных наборов (A–M); физически это не “13 машин”, а распределённая инфраструктура, обычно с anycast, поэтому экземпляров по миру значительно больше.
Для старта резолвинга рекурсивному резолверу обычно нужен “root hints” — список имён и IP-адресов корневых серверов для первичного “bootstrap”.

Схема: общий путь запроса

(приложение/браузер)
        |
        v
(stub-резолвер ОС)  --запрос имени-->  (рекурсивный резолвер)
        |                                  |
        |                                  | если кэша нет
        |                                  v
        |                          (корневые серверы .)
        |                                  |
        |                                  v
        |                          (серверы TLD: .com, .ru, ...)
        |                                  |
        |                                  v
        |                        (авторитативные серверы зоны)
        |                                  |
        v                                  v
   IP-адрес(а)  <-----------ответ-----------

Как DNS находит IP: пошагово

Формирование вопроса (QNAME/QTYPE/QCLASS)

DNS-запрос задаёт доменное имя (QNAME), тип данных (QTYPE, например A/AAAA) и класс (QCLASS, обычно IN).
DNS-сообщение состоит из заголовка и секций Question/Answer/Authority/Additional, при этом в ответе могут быть не только итоговые данные, но и записи, которые помогают продолжить поиск (referral) или правильно интерпретировать результат.

Проверка кэша на клиенте и у рекурсивного резолвера

Кэш обычно существует на нескольких уровнях: в ОС/приложении (по-разному) и в рекурсивном резолвере (почти всегда).
TTL определяет, сколько секунд запись можно хранить до повторной проверки у источника; короткий TTL ускоряет “раскатку” изменений, но увеличивает число запросов и нагрузку.

Кэширование — частая причина “почему у одного открывается, а у другого нет” после изменения DNS: пока TTL не истёк, часть клиентов может видеть старые данные.

Если кэша нет: обход по иерархии (root → TLD → authoritative)

Рекурсивный резолвер при отсутствии ответа начинает с корневых серверов и получает список NS для нужного домена верхнего уровня (TLD).
Затем запрашиваются серверы TLD, от них получается делегирование на авторитативные серверы домена/зоны.
После этого выполняется запрос к авторитативному серверу за нужным типом записи (например, A/AAAA), и результат возвращается клиенту.

Получение итоговой записи и возможных “цепочек”

Для IPv4 обычно запрашивается тип A, для IPv6 — AAAA; у одного имени может быть несколько A/AAAA записей, и это нормальный случай (например, для отказоустойчивости или балансировки).
Если имя является псевдонимом, запись CNAME указывает каноническое имя, и поиск продолжается уже для канонического имени, пока не будут получены A/AAAA.
Если домен не существует (NXDOMAIN) или нет нужного типа записи, возвращается код результата; многие резолверы также кэшируют отрицательные результаты на ограниченное время.

Что именно находится в DNS-сообщении

Ресурсная запись содержит поля NAME, TYPE, CLASS, TTL и RDATA (данные записи).
DNS исторически часто использовал UDP на порту 53, а TCP применяется, когда ответ не помещается или в ряде иных сценариев; это важно для понимания “почему иногда запросы выглядят по-разному” в сетевой диагностике.
Для современных сценариев распространены защищённые транспорты: DoT обычно использует TCP/853, DoH — HTTPS/443, но логика “найти запись по имени и типу” остаётся DNS-логикой.

Таблица: часто встречающиеся типы записей

Тип RR	Для чего нужен	Пример “что хранит”
A	IPv4-адрес хоста	32-битный адрес
AAAA	IPv6-адрес хоста	128-битный адрес
CNAME	Алиас на каноническое имя	Доменное имя-цель
NS	Делегирование/серверы зоны	Доменное имя NS
SOA	Параметры зоны	SERIAL/REFRESH/RETRY/EXPIRE
PTR	Обратное имя по адресу	Указатель на доменное имя

Обратное разрешение (reverse DNS) обычно устроено через отдельное пространство имён (например, для IPv4 применяется зона вида IN-ADDR.ARPA), то есть “IP → имя” делается не зеркальным поиском, а через специальную структуру имён.

Практика: команды и примеры

Трассировка цепочки резолвинга

Команда dig example.com A +trace показывает путь, похожий на итеративный обход: корень → TLD → авторитативные серверы, что помогает увидеть делегирования и понять, где именно возникает проблема.

dig example.com A +trace

Запрос разных типов записей

Полезно явно различать A/AAAA/CNAME/NS, потому что “получить IP” — это запрос конкретного типа записи, а не “магия домена”.

dig example.com A
dig example.com AAAA
dig example.com CNAME
dig example.com NS

Пример на Node.js (через системный резолвер)

В Node.js модуль node:dns часто опирается на системный резолвер, поэтому результат обычно отражает работу рекурсивного резолвера и его кэша (а также настройки ОС).

import { promises as dns } from 'node:dns';

const host = 'example.com';

const a = await dns.resolve4(host);
const aaaa = await dns.resolve6(host);

console.log({ host, a, aaaa });

DoH (DNS over HTTPS) как актуальный транспорт

DoH передаёт DNS-запросы и ответы поверх HTTPS, то есть шифрует транспорт и использует инфраструктуру HTTPS (сертификаты, прокси, корпоративные политики и т.п.).
DoH не “отменяет” DNS как систему: меняется транспорт доставки запроса, но сущности DNS (имя, тип записи, кэширование, TTL, делегирование) остаются теми же.
DNSSEC и DoH решают разные задачи: DNSSEC про проверяемую целостность данных DNS, DoH — про защищённый канал доставки.

# пример DoH-запроса на уровне идеи:
# GET https://dns.example/dns-query?dns=<base64url(dns-wire-message)>
# Accept: application/dns-message

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

Кратко: DNS — распределённая система, которая по доменному имени возвращает ресурсные записи (часто A/AAAA) через иерархию серверов и кэширование с TTL. Типичный путь при отсутствии кэша проходит через root, затем TLD и затем авторитативные серверы зоны, после чего результат сохраняется в кэше на ограниченное время.