DNS: как устроена адресная книга интернета и чем она полезна бизнесу

В 1983 году инженеры Пол Мокапетрис и Джон Постел представили систему доменных имён (Domain Name System — DNS). Этот подход снял ограничения старого механизма с файлом hosts, который перестал масштабироваться вместе с ростом ARPANET.

Базовые принципы DNS описаны в RFC 1034 и RFC 1035 и остаются актуальными. Для защиты приватности появилась поддержка механизмов шифрования для DNS‑протокола: DoT (DNS over TLS) и DoH (DNS over HTTPS).

В материале — об устройстве DNS, роли серверов, структуре ресурсных записей и базовых практиках безопасности. Также покажем, как сервис Yandex Cloud DNS помогает управлять доменными зонами в облаке.

Что такое DNS и какую роль играет

DNS преобразует человекочитаемые доменные имена в IP‑адреса и обратно. Система присваивает уникальные имена ресурсам в интернете и во внутренних сетях. При необходимости имя можно получить по IP.

Структура доменных имён организована иерархически, в виде дерева. На вершине этой структуры находится корень — точка «.». Ниже — домены верхнего уровня (Top‑Level Domain, TLD), например «.ru» и «.com». За ними следуют домены второго уровня, третьего и последующих уровней, которые называют поддоменами.

Структуру поддерживают серверы имён. За каждой зоной закреплён свой набор серверов, которые хранят соответствия имён и IP‑адресов в пределах своей ответственности.

Поиск ответов выполняет резолвер — прикладная программа. Когда в адресной строке вводят имя, резолвер последовательно опрашивает нужные серверы и получает IP‑адрес.

Доменное пространство распределено между многими администраторами. Благодаря этому система масштабируется и устойчиво переносит сбои: единой точки отказа не возникает.

Зачем бизнесу DNS

Любое устройство в сети имеет уникальный адрес: IPv4 вида 192.0.2.1 или IPv6 вида 2001:db8:1. По этим адресам узлы находят друг друга и обмениваются данными. Приведённые выше адреса зарезервированы для примеров и не применяются в реальных сетях.

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

Работу всей схемы обеспечивает распределённая сеть DNS‑серверов с разными ролями.

Что такое DNS‑сервер и зачем он нужен

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

Основная задача DNS — вернуть IP‑адрес по доменному имени. Когда пользователь вводит адрес сайта в браузере, DNS‑сервер находит нужный IP‑адрес и возвращает его. После этого браузер устанавливает соединение с целевым сервером. Аналогичным образом DNS работает и при обращении сервисов друг к другу по полным доменным именам (FQDN).

Эти функции разделены между типами серверов, и у каждого своя роль.

Как работают DNS‑серверы

Процесс получения IP‑адреса для имени состоит из ряда шагов. Разберём на примере www.ya.ru:

1. Проверка на локальной машине. Система сначала смотрит файл hosts. Если запись найдена, браузер сразу подключается к сайту. Если нет, формируется рекурсивный запрос к резолверу провайдера.

2. Запрос к резолверу. Резолвер проверяет собственный кеш — временное хранилище свежих ответов. Если там уже есть IP для www.ya.ru, он сразу отправляется в браузер. Иначе начинается поиск через корневые серверы.

3. Корневые серверы. Эти узлы не возвращают IP конкретных сайтов, но подсказывают, к какой зоне TLD обращаться дальше. В нашем примере — к «.ru».

4. Сервер TLD. Резолвер обращается к TLD‑серверу «.ru». Тот не хранит конечный IP, но знает авторитативные серверы домена yandex.ru и отдаёт их в NS‑записях.

5. Авторитативный сервер. Дальше запрос идёт на авторитативный сервер зоны ya.ru. Источник данных возвращает A‑запись для www.ya.ru и сам IP‑адрес.

6. Ответ и кеширование. Резолвер отдаёт IP браузеру и сохраняет ответ в кеш для будущих обращений. Браузер устанавливает прямое соединение с www.ya.ru.

Что такое DNS‑зоны

Именное пространство разбито на административные области — DNS‑зоны. За каждую отвечает её владелец — это может быть как организация, так и частное лицо. Внутри зоны хранится информация о доменах в виде ресурсных записей.

Важно различать домен и зону:

• домен — имя в иерархии, например ya.ru;

• зона — контейнер с записями для одного или нескольких доменов.

Типы зон:

• Прямые (Forward Lookup) преобразуют имена в IP‑адреса — самый распространённый вариант.

• Обратные (Reverse Lookup) определяют имя по IP с помощью PTR‑записей. Применяются для проверки подлинности почтовых серверов и в диагностических утилитах, например traceroute.

• Публичные и внутренние. Публичные доступны из интернета. Внутренние содержат адреса ресурсов в изолированных сетях и открыты только из этих сетей.

Виды DNS‑серверов

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

• Корневые серверы. Верхний уровень. Эти узлы не сообщают IP сайтов, но знают адреса TLD‑серверов и перенаправляют к ним запросы.

• TLD‑серверы. Обслуживают домены верхнего уровня — «.com», «.org», «.ru» и другие. Хранят адреса авторитативных серверов доменов второго уровня и подсказывают резолверу следующий шаг.

• Авторитативные серверы. Последнее звено в цепочке. Содержат ресурсные записи конкретной зоны и возвращают окончательный ответ — IP‑адрес искомого имени.

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

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

Первичный и вторичный серверы: доступность и устойчивость

Чтобы не возникала единая точка отказа, авторитативные серверы дублируют. Первичный сервер хранит эталонную копию зоны. Вторичные периодически копируют данные через трансфер зоны. На запросы отвечают оба, нагрузка распределяется.

Где размещены корневые DNS‑серверы

Корневые серверы — один из базовых элементов инфраструктуры. Логических имён всего 13 — от A до M (a.root‑servers.net, b.root‑servers.net и т. д.). Ими управляют 12 независимых организаций под контролем ICANN.

Число логических имён исторически связано с размером DNS‑пакета. Физических машин больше. Для глобальной доступности применяется маршрутизация Anycast: один и тот же IP объявляется на сотнях узлов по всему миру, а запрос уходит на ближайший с точки зрения сети инстанс.

Сейчас в мире развёрнуто более 1,8 тыс. физических копий (зеркал) корневых серверов. Часть из них работает в России — это снижает задержки и повышает устойчивость национального сегмента сети.

Ресурсные записи: как хранится информация в DNS

Данные в DNS представлены ресурсными записями (RR — Resource Records). Записи зоны объединяются в текстовый файл зоны фиксированного формата.

Структура записи:

• Name — имя. Домен, к которому относится запись, например www.example.com;
• Type — тип. Назначение записи. Тип A — IPv4‑адрес, MX — почтовый сервер и т. д.;
• Class — класс. Тип сети. Для интернета почти всегда используется IN;
• TTL — Time To Live. Время жизни в секундах. Определяет, сколько ответ хранится в кеше резолвера. Низкий TTL ускоряет обновление, но увеличивает нагрузку на серверы;
• RDATA — данные записи. Полезная часть. Для A — IP, для MX — приоритет и имя почтового сервера.

Через записи администраторы управляют маршрутизацией и работой сервисов, связанных с доменом.

Короткий справочник типовых RR:

• A — Address, IPv4‑адрес домена, например 192.0.2.1.
• AAAA — IPv6 Address, IPv6‑адрес домена, например 2001:db8:1.
• CNAME — Canonical Name, псевдоним, указывающий с одного имени на другое, каноническое.
• MX — Mail Exchange, почтовые серверы домена; включает приоритет, чтобы построить отказоустойчивую схему.
• NS — Name Server, авторитативные серверы зоны — основа делегирования.
• TXT — Text, произвольный текст; часто используют для подтверждения владения доменом и настройки почтовых политик SPF и DKIM.
• SOA — Start of Authority, «заголовок» зоны: первичный сервер, контакт администратора, серийный номер и таймеры синхронизации.
• SRV — Service, описание сетевых сервисов с указанием хоста и порта. Применяется для SIP, LDAP и сервис‑дискавери в Kubernetes^®.
• PTR — Pointer, обратное соответствие IP → имя. Используется в обратных зонах и проверках почтовых серверов.

Защита DNS‑серверов от атак

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

Принципы управления DNS‑инфраструктурой

DNS — опорный элемент интернета и облачных платформ. Для рационального управления инфраструктурой полезны такие практики:

• управляемые DNS‑сервисы — передача DNS‑хостинга облачному провайдеру снимает часть операционных задач и упрощает масштабирование;
• разделение публичных и внутренних зон — внутренние зоны решают адресацию внутри виртуальных сетей и снижают риски;
• управление TTL — баланс между скоростью обновления и нагрузкой на серверы; перед миграциями уместно временно уменьшить TTL у затрагиваемых записей;
• автоматизация управления записями — интеграция изменений DNS‑записей в CI/CD‑конвейеры сокращает вероятность ошибок, возникающих при ручной настройке;
• мониторинг запросов — анализ DNS‑трафика помогает находить аномалии и точки оптимизации производительности.

Почему изменения в DNS применяются не сразу

После регистрации домена или правок в записях результат виден не мгновенно. Задержку часто называют «распространением DNS», но корректнее говорить о кешировании.

Рекурсивные резолверы по всему миру сохраняют ответы на время, указанное в TTL. Если для A‑записи установлен TTL 24 часа — 86,4 тыс. секунд, — то после смены IP ответы со старым адресом будут возвращаться до истечения этого срока. Поэтому часть пользователей какое‑то время видит сайт по прежнему адресу, часть — по новому.

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

Управление доменными зонами с Yandex Cloud DNS

Для работы с DNS‑записями в облаке можно использовать сервис Yandex Cloud DNS. Он обеспечивает отказоустойчивый DNS‑хостинг с малым временем отклика.

Управление зонами доступно через веб‑интерфейс, CLI и API. Именно API позволяет интегрировать управление DNS в подход «инфраструктура как код» (IaC) и автоматизировать процессы с помощью таких инструментов, как Terraform.

Yandex Cloud DNS интегрирован с сервисами платформы. Для виртуальных машин в Yandex Compute Cloud и узлов в Yandex Managed Service for Kubernetes^® внутренние имена присваиваются автоматически. Записи для них можно добавлять во внутренние зоны Yandex Cloud DNS вручную или программно — так удобнее адресовать ресурсы по полному доменному имени, FQDN. Контроль доступа реализован через Yandex Identity and Access Management.