DNS: как работает система доменных имён — от запроса до ответа

Вы вводите «vk.ru» в адресную строку браузера и через доли секунды видите страницу. Между нажатием Enter и загрузкой сайта проходит цепочка запросов к системе, которая переводит доменное имя в IP-адрес сервера.

Как работает DNS, обычно не задумываются до момента, когда переезд на новый сервер оборачивается часами ожидания или когда разные пользователи видят разные версии сайта. DNS (Domain Name System) отвечает за трансляцию: браузер не умеет открывать «vk.ru» напрямую, ему нужен числовой адрес. Без DNS пришлось бы запоминать 87.250.250.242 вместо короткого имени.

Дальше разберём иерархию DNS-серверов, механизм запроса шаг за шагом, типы записей и причины, по которым изменение DNS не вступает в силу мгновенно.

Что такое DNS и зачем он нужен

Имена вместо чисел

DNS — иерархическая распределённая система именования, которая сопоставляет доменные имена с IP-адресами и другими данными о ресурсах сети (RFC 1034). Форматы сообщений, типы записей и механизм запросов описаны в RFC 1035.

Браузер не умеет открывать «vk.ru» напрямую: ему нужен IP-адрес сервера. Без DNS каждый адрес пришлось бы вводить числами. IP-адреса сервисов меняются: при переезде на другой сервер имя остаётся прежним, обновляется только запись в DNS.

Кто придумал DNS

До DNS соответствие имён хостов и их адресов в сети ARPANET велось в едином текстовом файле HOSTS.TXT. Файл централизованно поддерживал Stanford Research Institute и распространял по FTP (RFC 952). Схема работала, пока сеть оставалась маленькой: любое изменение требовало скачать обновлённую версию файла на каждую машину.

Когда число хостов выросло, подход с одним файлом перестал работать. В 1983 году Пол Мокапетрис предложил иерархическую распределённую систему, описанную в RFC 882 и RFC 883 (позже их заменили RFC 1034 и RFC 1035). Архитектура с тех пор не менялась принципиально, а система масштабировалась до миллиардов доменов.

Иерархия DNS: от корня до домена

Уровни иерархии

DNS устроен как дерево, которое читается справа налево. В домене «mail.vk.com»:

• «.» — корень (root). Невидимая точка в конце любого полного доменного имени: TLD формально отделён от неё (RFC 1034).
• «ru» — домен верхнего уровня (TLD).
• «vk» — домен второго уровня, зарегистрированный конкретной организацией.
• «mail» — поддомен, которым управляет владелец vk.com.

Корневые серверы: 13 имён, сотни машин

Корневую зону DNS обслуживают 13 логических серверов — от a.root-servers.net до m.root-servers.net (данные IANA и Root Servers Technical Operations Association). За каждым именем физически стоят сотни инстансов по всему миру: они работают благодаря Anycast-маршрутизации, которая направляет запрос к ближайшей копии. Корневые серверы не хранят IP конкретного домена: они знают только, где искать серверы нужного TLD.

Зоны и делегирование

Управление корневой зоной и делегирование доменов верхнего уровня — задача IANA, которая работает под эгидой ICANN. Каждый TLD делегируется отдельному реестру: доменом .com управляет VeriSign по соглашению с ICANN, национальным доменом .ru — АНО «Координационный центр доменов .RU/.РФ», техническую поддержку которого обеспечивает Технический центр Интернет.

TLD-зоны делегируют управление конкретными доменами их владельцам через NS-записи. Каждый уровень иерархии знает только о своей части дерева и передаёт запрос ниже.

Как работает DNS-запрос: шаг за шагом

Полный путь запроса для «vk.com»

1. Браузер проверяет локальный кэш операционной системы. Если запись есть и TTL не истёк, ответ готов, дальнейших запросов нет.
2. Если кэша нет, запрос уходит к DNS-резолверу (например, 8.8.8.8).
3. Резолвер проверяет свой кэш. Если запись есть, возвращает её сразу.
4. Резолвер отправляет запрос к корневому серверу: где серверы зоны .com? Корневой сервер возвращает адреса TLD-серверов.
5. Резолвер спрашивает сервер .com: где авторитетные серверы для vk.com? TLD-сервер возвращает NS-записи зоны vk.com.
6. Резолвер спрашивает авторитетный сервер vk.com: какой IP у vk.com? Авторитетный сервер возвращает A-запись с адресом.
7. Резолвер кэширует ответ на время, заданное TTL записи, и возвращает IP браузеру.
8. Браузер устанавливает TCP-соединение с полученным IP-адресом.

Рекурсивный и итеративный режим

Запрос от браузера к резолверу — рекурсивный: резолвер берёт на себя всю цепочку и возвращает готовый ответ. Запросы резолвера к корневым серверам и далее — итеративные: каждый сервер отвечает «спроси вот там» и не отдаёт готовый результат.

DNS-зоны, A-записи, MX и NS для доменов настраиваются в панели управления VK Cloud. Управлять DNS в VK Cloud →

Типы DNS-записей

На что обратить внимание

CNAME и корень зоны. CNAME-запись не может сосуществовать с другими записями того же имени, поэтому её не используют в корне зоны (апексе), где обязательны SOA и NS (RFC 1034). Для корня домена нужна A- или AAAA-запись.

MX указывает на имя, не на IP. MX-запись содержит доменное имя почтового сервера и приоритет. Это имя должно разрешаться отдельной A- или AAAA-записью (RFC 1035).

TXT для SPF и DKIM. TXT-запись хранит произвольные текстовые данные при домене. Чаще всего её используют для SPF — механизма, подтверждающего право почтового сервера отправлять письма от имени домена (RFC 7208), и для DKIM-подписи, которая публикуется в поддомене _domainkey и криптографически верифицирует отправителя (RFC 6376).

PTR, SRV, CAA. PTR-запись работает в обратную сторону: сопоставляет IP-адрес с доменным именем через зону in-addr.arpa для IPv4 или ip6.arpa для IPv6 (RFC 1035). SRV-запись описывает адрес и порт сервиса по шаблону _service._proto.name (RFC 2782). CAA-запись указывает, какие удостоверяющие центры вправе выпускать SSL/TLS-сертификаты для домена (RFC 8659).

TTL и кэширование: почему изменения DNS не применяются сразу

Что такое TTL

TTL (Time to Live) задаётся в секундах в самой DNS-записи и определяет, как долго резолверы вправе использовать закэшированное значение без повторного обращения к авторитетному серверу (RFC 1035). Если TTL записи A равен 3600, резолвер будет отдавать сохранённый ответ в течение часа.

Отдельно в SOA-записи зоны есть поле minimum TTL: оно задаёт время кэширования отрицательных ответов — ситуаций, когда домен не найден (RFC 2308).

Почему это важно при изменении записей

Вы сменили A-запись на новый IP, но часть пользователей продолжает попадать на старый сервер. Причина: у них в кэше прежнее значение, которое ещё не истекло. Поэтому перед переездом правильный порядок такой: снизить TTL до 300–600 секунд заранее, выполнить переезд, вернуть TTL к обычному значению.

Рекомендуемые значения TTL

Практические следствия для разработчиков и DevOps

Диагностика DNS

dig vk.com                  # полный вывод: запись, TTL, сервер, время ответа
nslookup vk.com             # простой запрос, удобен на Windows
dig vk.com @8.8.8.8         # запрос к конкретному резолверу

Утилита dig входит в состав пакета BIND и выводит полную информацию об ответе, включая TTL и время выполнения запроса. Этого достаточно, чтобы понять, где застряло разрешение имени.

DNS в облачной инфраструктуре

В облаке DNS используется не только для публичных доменов. Внутри виртуальной сети сервисы обращаются друг к другу по именам через внутренний DNS. Балансировщики нагрузки нередко отдают несколько IP-адресов для одного имени по методу round-robin DNS: авторитетный сервер публикует несколько A-записей и выдаёт их в разном порядке при последовательных запросах (RFC 1794). В Kubernetes с версии 1.13 разрешением имён сервисов внутри кластера занимается CoreDNS, заменивший kube-dns.