📖 Введение
Когда вы открываете браузер и набираете google.com или youtube.com, происходит нечто, что для пользователя кажется мгновенным и простым — сайт открывается.
Но за этим скрывается сложный механизм, обеспечивающий соответствие между понятными человеку именами и цифровыми адресами, по которым общаются компьютеры.
Эта технология называется DNS (Domain Name System) — система доменных имён.
Она играет ту же роль, что и телефонная книга: вместо того чтобы запоминать IP-адрес 142.250.190.78, мы используем имя google.com.
DNS — это основа Интернета. Без него не заработает ни веб, ни почта, ни большинство сервисов.
Разберём, откуда он появился, зачем нужен, как устроен, и что происходит, когда вы вводите адрес сайта.
🗃️ История DNS
В 1970-х, когда Интернет только зарождался под названием ARPANET, адресация была простой: имена и IP-адреса всех компьютеров хранились в одном текстовом файле hosts.txt.
Этот файл поддерживался вручную в Stanford Research Institute (SRI) и регулярно рассылался по сети.
Когда количество узлов перевалило за несколько сотен, централизованная система перестала работать: обновления шли медленно, адреса конфликтовали, а ошибки множились.
В 1983 году инженер Поль Мокапетрис (Paul Mockapetris) предложил решение — Domain Name System.
Новая система должна была быть:
- распределённой — без единой точки отказа,
- иерархической — чтобы зоны делегировались владельцам доменов,
- масштабируемой — способной расти вместе с Интернетом.
Так появился DNS, описанный в RFC 882 и 883 (позже заменённый RFC 1034 и 1035), который действует до сих пор.
🧩 Основная идея DNS
DNS решает задачу: сопоставить доменное имя (example.com) с IP-адресом (93.184.216.34).
Этот процесс называется разрешением имени (name resolution).
Система организована иерархически — имена читаются справа налево:
www.example.com.
- . — корневая зона (root)
- com — домен верхнего уровня (TLD)
- example — домен второго уровня
- www — поддомен (или хост)
🏗️ Архитектура DNS
DNS — это не один сервер, а сеть тысяч серверов, организованных в три уровня:
- Корневые серверы (Root servers) - Хранят адреса серверов доменов верхнего уровня (.com, .org, .fr и т.д.).Таких серверов логически 13 (A–M), но физически — тысячи, благодаря технологии Anycast.
- TLD-серверы (Top-Level Domain) - Управляют доменами верхнего уровня.Например, .com обслуживается Verisign, .fr — AFNIC.
- Авторитативные серверы (Authoritative DNS) - Содержат конечные данные о конкретных доменах: IP, MX-записи, TXT и т.д.Это “источник истины” для каждого домена.
- Рекурсивные резолверы (Recursive Resolvers) - Обычно предоставляются провайдерами или публичными сервисами (Google DNS, Cloudflare).Они выполняют весь путь запроса — от корня до конечного IP, а результат кэшируют.
🏭 Подробно: как работает DNS
Разберём, что происходит, когда пользователь вводит в браузере www.example.com.
1. От браузера к операционной системе
Когда приложение (например, Chrome или curl) хочет получить IP, оно вызывает системную функцию — getaddrinfo().
Она обращается к stub resolver — встроенному в ОС лёгкому клиенту, который не знает, где именно искать ответ, но знает, какому DNS-серверу отправить запрос.
Эти DNS-серверы указаны в сетевых настройках — например:
nameserver 1.1.1.1
nameserver 8.8.8.8
2. Проверка локальных источников
Прежде чем отправлять запрос в сеть, ОС проверяет:
- Файл /etc/hosts — если там явно указано соответствие:
93.184.216.34 example.com
- — DNS не нужен.
- Локальный кэш — браузеры и системы хранят недавние ответы с TTL (время жизни).
Если запись найдена и не устарела — IP возвращается приложению мгновенно.
3. Обращение к рекурсивному резолверу
Если кэша нет, stub resolver отправляет запрос по UDP/53 (иногда TCP/53) к указанному DNS-серверу (например, 8.8.8.8).
Этот сервер — рекурсивный резолвер. Он берёт на себя всю работу по поиску нужного IP.
4. Внутренности DNS-запроса
Каждый DNS-пакет содержит:
- ID запроса,
- флаги (например, “рекурсивный запрос”),
- Question section — имя, тип (A, AAAA, MX), класс (IN),
- и при ответе — секции Answer, Authority, Additional.
Пример:
«Найди A-запись для www.example.com»
5. Обращение к корневому серверу
Рекурсивный сервер знает адреса корневых серверов из файла root hints.
Он посылает им вопрос:
«Где искать зону .com?»
Корневой сервер отвечает:
;; AUTHORITY SECTION:
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800 IN A 192.5.6.30
Таким образом, он сообщает — “за зону .com отвечает этот сервер”.
6. Запрос к TLD-серверу (.com)
Теперь резолвер знает, куда идти дальше, и спрашивает TLD-сервер:
«Где находятся авторитативные серверы для example.com?»
Ответ:
example.com. 86400 IN NS ns1.iana.org.
example.com. 86400 IN NS ns2.iana.org.
7. Запрос к авторитативному серверу
Рекурсивный сервер обращается к ns1.iana.org:
«Какой IP у www.example.com?»
Ответ:
www.example.com. 3600 IN A 93.184.216.34
Если присутствует CNAME, например:
www.example.com. 3600 IN CNAME web.example.com.
web.example.com. 3600 IN A 93.184.216.34
резолвер продолжает цепочку, пока не получит реальный IP.
8. Возврат результата и кэширование
Рекурсивный сервер кэширует найденный ответ на TTL (3600 секунд) и возвращает его stub resolver’у.
ОС сохраняет IP в своём кэше, а браузер — в своём.
Теперь при повторных обращениях запрос не пойдёт в сеть, пока TTL не истечёт.
🔍 Глубже: рекурсия, кэш и делегирование
Рекурсивный vs итеративный запрос
- Рекурсивный — клиент (stub resolver) говорит: «Найди ответ полностью».
- Итеративный — сервер отвечает: «Я не знаю, но вот кто знает».
Рекурсивный сервер комбинирует оба подхода: он делает итеративные запросы вверх по цепочке, пока не найдёт окончательный ответ, а клиенту возвращает результат рекурсивно — одной порцией.
Кэширование на всех уровнях
Кэш присутствует:
- в браузере,
- в ОС,
- в резолвере,
- у провайдеров и CDN.
Каждая запись имеет TTL, задаваемый администратором зоны.
Малый TTL ускоряет обновления, но увеличивает нагрузку; большой — наоборот.
Glue-записи
Когда NS-сервер находится внутри собственной зоны (example.com → ns1.example.com), возникает “курица и яйцо”: чтобы найти ns1.example.com, нужно знать IP, но IP хранится там же.
Поэтому TLD добавляет glue-запись (A/AAAA-запись для NS), чтобы разорвать этот цикл.
Обратное разрешение (Reverse DNS)
Чтобы узнать имя по IP, используется зона in-addr.arpa (для IPv4) или ip6.arpa (для IPv6).
Например:
34.216.184.93.in-addr.arpa → example.com
Эти PTR-записи часто применяются в почтовых системах для проверки подлинности.
Тайм-ауты и отказоустойчивость
Рекурсивные серверы обращаются к нескольким NS одновременно.
Если один не отвечает в течение 2–5 секунд, они пробуют другой.
Если ни один не отвечает, возвращается код SERVFAIL.
UDP, TCP и шифрованные протоколы
- По умолчанию — UDP/53.
- Если ответ длиннее 512 байт или требуется надёжность — TCP/53.
- Современные шифрованные варианты:
DoT (DNS over TLS) — порт 853;
DoH (DNS over HTTPS) — порт 443;
DoQ (DNS over QUIC) — на стадии внедрения.
Пример реального обмена
$ dig +trace www.example.com
. 518400 IN NS a.root-servers.net.
com. 172800 IN NS a.gtld-servers.net.
example.com. 86400 IN NS b.iana-servers.net.
www.example.com. 3600 IN A 93.184.216.34
Команда показывает всю цепочку разрешения имени — шаг за шагом, как рекурсивный сервер проходит от корня до цели.
📁 Типы DNS-записей
🧱 Зоны и делегирование
Каждый домен управляется своей зоной, которая может быть делегирована другим.
Например:
- .com делегирует example.com владельцу;
- владелец может делегировать api.example.com отдельному DNS-серверу.
Так достигается масштабируемость и независимость управления.
🧰 DNS и безопасность
DNS изначально создавался в доверенной среде и не предполагал защиты.
Сегодня применяются:
- DNSSEC — цифровая подпись записей, защищающая от подмены;
- DNS over TLS (DoT) и DNS over HTTPS (DoH) — шифруют трафик;
- DNS filtering — фильтрация вредоносных доменов (например, Quad9).
🧠 Заключение
DNS — это инженерная система, которая за миллисекунды выполняет огромный объём работы: от запроса через цепочку корневых, TLD и авторитативных серверов — до кэширования и возврата результата.
Каждый веб-запрос, каждое письмо и каждое приложение начинается с одного — с DNS-запроса, который невидимо соединяет имена с адресами.