Что такое DNS и как он работает?

DNS (Domain Name System) — это распределённая инфраструктура именования в интернете, которая переводит удобочитаемые доменные имена — например, example.com — в машиночитаемые IP-адреса, такие как 93.184.216.34. Без DNS каждый запрос браузера, вызов API и доставка электронной почты требовали бы от пользователей и приложений знания точного числового адреса каждого удалённого хоста, что сделало бы современный интернет операционно невозможным в масштабе.

В своей основе DNS — это глобально распределённая иерархическая база данных. Это не единственный сервер и не централизованный реестр — это дерево делегирования, охватывающее сотни тысяч авторитетных серверов имён по всему миру, координируемое через небольшой набор корневых серверов и регулируемое стандартами, определёнными в RFC 1034 и RFC 1035.

Почему DNS — это больше, чем просто «телефонная книга»

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

• Маршрутизацию почты через записи MX, направляющие электронную почту на правильные почтовые серверы
• Обнаружение сервисов через записи SRV, используемые такими протоколами, как SIP, XMPP и внутренняя сеть Kubernetes
• Верификацию владения доменом через записи TXT, используемые для SPF, DKIM, DMARC и Google Search Console
• Каноническое именование через записи CNAME, обеспечивающее интеграцию с CDN и балансировку нагрузки
• Адресацию IPv6 через записи AAAA
• Обратный поиск через записи PTR в зоне in-addr.arpa, критически важный для репутации почтового сервера и аудита безопасности
• Валидацию DNSSEC, которая добавляет криптографические подписи к DNS-ответам для предотвращения отравления кэша

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

Иерархия DNS: как структурировано пространство имён

DNS организована в виде перевёрнутого дерева. Понимание этой структуры необходимо для понимания того, почему разрешение работает именно так.

.  (Root Zone)
├── com
│   ├── example.com  (Second-Level Domain)
│   │   └── www.example.com  (Subdomain / FQDN)
├── org
├── net
└── uk
    └── co.uk

• Корневая зона (.): Управляется IANA. Существует 13 логических адресов корневых серверов (от A до M), эксплуатируемых такими организациями, как Verisign, NASA и ICANN. На практике они обслуживаются сотнями физических машин через маршрутизацию anycast.
• Домены верхнего уровня (TLD): Общие TLD, такие как .com, .net, .org, и национальные TLD, такие как .uk, .de, .md. Каждый TLD имеет собственный набор авторитетных серверов имён.
• Домены второго уровня (SLD): Домен, который вы регистрируете — example.com. Авторитетный DNS для этой зоны контролируется тем, кто зарегистрировал домен.
• Поддомены: www, mail, api, staging — это записи внутри зоны SLD, полностью контролируемые владельцем домена.

Пошагово: как разрешается DNS-запрос

Полное рекурсивное разрешение DNS включает до семи отдельных сетевых обменов. Вот точная последовательность:

Шаг 1 — Проверка кэша браузера

Когда вы вводите www.example.com в браузер, операционная система сначала проверяет свой локальный DNS-кэш. В Linux это может управляться systemd-resolved; в Windows — службой DNS Client. Если существует действительная кэшированная запись и её TTL (Time to Live) не истёк, разрешение останавливается здесь.

Вы можете просмотреть локальный DNS-кэш в Linux с помощью:

resolvectl statistics

Или очистить его с помощью:

sudo resolvectl flush-caches

В Windows:

ipconfig /displaydns
ipconfig /flushdns

Шаг 2 — Запрос к рекурсивному резолверу

Если кэшированного ответа нет, ОС перенаправляет запрос к настроенному рекурсивному резолверу (также называемому рекурсивным DNS-сервером или резолвером полного обслуживания). Как правило, это:

• Резолвер вашего интернет-провайдера (назначается через DHCP)
• Публичный резолвер: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), 9.9.9.9 (Quad9)
• Самостоятельно размещённый резолвер, такой как Unbound или BIND, на вашей собственной инфраструктуре VPS Хостинга

Рекурсивный резолвер выполняет основную работу. Он обходит иерархию DNS от вашего имени и кэширует результаты для более быстрого обслуживания будущих запросов.

Шаг 3 — Направление к корневому серверу

Рекурсивный резолвер запрашивает один из 13 кластеров корневых серверов. Корневой сервер не знает IP-адреса www.example.com. Вместо этого он возвращает направление — список авторитетных серверов имён для зоны TLD .com вместе с их IP-адресами (называемыми glue-записями).

Шаг 4 — Запрос к серверу имён TLD

Резолвер запрашивает серверы имён TLD .com (эксплуатируемые Verisign). Эти серверы также не содержат окончательного ответа. Они возвращают ещё одно направление — авторитетные серверы имён конкретно для example.com (например, ns1.example.com, ns2.example.com).

Шаг 5 — Запрос к авторитетному серверу имён

Резолвер запрашивает авторитетный сервер имён для example.com. Этот сервер содержит фактический файл зоны и возвращает окончательный ответ — запись A с IPv4-адресом (или AAAA для IPv6).

Шаг 6 — Кэширование и доставка ответа

Рекурсивный резолвер кэширует ответ в соответствии со значением TTL записи (например, 300 секунд = 5 минут, 86400 секунд = 24 часа). Затем он возвращает IP-адрес ОС клиента, которая передаёт его браузеру.

Шаг 7 — TCP/IP-соединение

Браузер использует разрешённый IP-адрес для открытия TCP-соединения (обычно на порту 443 для HTTPS). Работа DNS на этом завершена. Веб-сервер отвечает, и страница загружается.

Весь этот процесс — шаги со 2 по 6 — обычно завершается за 20–120 миллисекунд при тёплом кэше резолвера и менее чем за 500 миллисекунд при полностью холодном, некэшированном разрешении, проходящем через все уровни иерархии.

Типы DNS-записей: технический справочник

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

Типы DNS-запросов: рекурсивные, итеративные и нерекурсивные

Большинство пользовательских устройств отправляют рекурсивные запросы к настроенному резолверу. Сам резолвер использует итеративные запросы при обходе иерархии.

TTL: наиболее неправильно понимаемый параметр DNS

TTL (Time to Live) — это количество секунд, в течение которых DNS-запись может кэшироваться резолверами и клиентами. Он устанавливается владельцем домена в файле зоны.

• Низкий TTL (60–300 секунд): Более быстрое распространение изменений. Необходим перед запланированными миграциями, изменениями IP или событиями переключения при отказе. Увеличивает нагрузку запросов на авторитетные серверы.
• Высокий TTL (3600–86400 секунд): Снижает нагрузку на резолвер и ускоряет повторные запросы. Изменения распространяются дольше.

Критически важный операционный совет: При планировании миграции сервера или смены IP уменьшите TTL до 300 секунд как минимум за 48 часов до изменения. Это гарантирует, что к моменту обновления записи A ни один резолвер не будет кэшировать старое значение более 5 минут. Несоблюдение этого требования является одной из наиболее распространённых причин длительного простоя во время миграций.

Когда вы регистрируете домен через Регистрацию доменов и направляете его на новый сервер, окно распространения напрямую определяется предыдущим значением TTL — а не произвольным правилом «24–48 часов», которое часто цитируют неверно.

Транспортные протоколы DNS: UDP, TCP, DoH и DoT

Традиционный DNS работает через UDP-порт 53 для запросов размером менее 512 байт. Ответы, превышающие этот размер, вызывают переключение на TCP-порт 53. Ответы DNSSEC, передача зон (AXFR) и большие записи TXT обычно требуют TCP.

Современные протоколы конфиденциальности DNS существенно изменили эту ситуацию:

DoH vs. DoT — реальное операционное различие: DoH туннелирует DNS внутри HTTPS-трафика на порту 443, делая его неотличимым от обычного веб-трафика. Это полезно для конфиденциальности, но существенно затрудняет мониторинг и фильтрацию корпоративной сети. DoT использует выделенный порт (853), который сетевые администраторы могут независимо отслеживать, блокировать или инспектировать. Для самостоятельно управляемой инфраструктуры на Выделенном сервере запуск локального резолвера DoT или DoH даёт вам как конфиденциальность, так и полный контроль над политикой разрешения.

DNSSEC: криптографическая целостность для DNS

DNSSEC (расширения безопасности DNS) добавляет цепочку криптографических подписей к DNS-ответам, позволяя резолверам проверять подлинность ответа и отсутствие его модификации при передаче. Это защищает от отравления DNS-кэша (атака Каминского) и подмены DNS через атаку «человек посередине».

DNSSEC не шифрует DNS-трафик — он только подписывает его. Цепочка подписей работает следующим образом:

1. Владелец зоны генерирует ключ подписи зоны (ZSK) и ключ подписи ключей (KSK)
2. Каждый набор DNS-записей подписывается с помощью ZSK, создавая записи RRSIG
3. KSK подписывает набор записей DNSKEY
4. Запись DS (Delegation Signer) публикуется в родительской зоне (например, .com), создавая цепочку доверия вплоть до корня

Включение DNSSEC настоятельно рекомендуется для любого домена, обрабатывающего финансовые транзакции, аутентификацию или электронную почту. Неправильно настроенный DNSSEC — особенно истёкшая подпись или несовпадающая запись DS — вызовет полный сбой разрешения для проверяющих резолверов, что является более серьёзным режимом отказа, чем полное отсутствие DNSSEC.

Распространённые сбои DNS и способы их диагностики

NXDOMAIN — несуществующий домен

Авторитетный сервер подтвердил, что домен не существует. Распространённые причины: опечатка в имени домена, истёкшая регистрация домена, удалённая DNS-запись.

dig www.example.com
# Look for: status: NXDOMAIN

SERVFAIL — сбой сервера

Резолвер не смог выполнить запрос. Распространённые причины: сбой валидации DNSSEC, недоступный авторитетный сервер, неправильно настроенный файл зоны.

dig +dnssec example.com
# Look for: status: SERVFAIL

Чтобы обойти валидацию DNSSEC и изолировать проблему:

dig +cd example.com
# +cd = checking disabled; bypasses DNSSEC validation

Устаревший кэш / задержка распространения

После обновления DNS-записи старые значения сохраняются в кэше резолверов до истечения TTL. Чтобы напрямую запросить авторитетный сервер и обойти кэш резолвера:

dig @ns1.example.com www.example.com

Проверка глобального распространения DNS

Используйте dig с конкретными публичными резолверами для проверки статуса распространения:

dig @8.8.8.8 www.example.com A
dig @1.1.1.1 www.example.com A
dig @9.9.9.9 www.example.com A

DNS в хостинговых средах: практические конфигурации

При развёртывании веб-сайта или приложения на VPS с cPanel управление DNS обычно осуществляется через DNS-кластер WHM или редактор зон cPanel. Понимание структуры файла зоны позволяет вносить изменения, которые графический интерфейс не предоставляет.

Минимальный файл зоны для example.com выглядит следующим образом:

$TTL 3600
@   IN  SOA  ns1.example.com. admin.example.com. (
            2024010101  ; Serial
            3600        ; Refresh
            900         ; Retry
            604800      ; Expire
            300 )       ; Minimum TTL

@       IN  NS      ns1.example.com.
@       IN  NS      ns2.example.com.
@       IN  A       203.0.113.10
www     IN  A       203.0.113.10
mail    IN  A       203.0.113.20
@       IN  MX  10  mail.example.com.
@       IN  TXT     "v=spf1 ip4:203.0.113.20 ~all"

Для корректной работы Почтового хостинга запись MX должна указывать на имя хоста (а не непосредственно на IP-адрес), и это имя хоста само должно разрешаться через запись A. Распространённая ошибка конфигурации — указание MX непосредственно на IP — нарушает RFC 2821 и вызывает сбои доставки на строгих почтовых серверах.

Производительность DNS: что реально влияет на скорость разрешения

• Близость резолвера: Резолвер, географически близкий к клиенту (или находящийся в той же сети), резко сокращает время приёма-передачи.
• Процент попаданий в кэш: Высокотрафиковые домены с разумными TTL почти всегда обслуживаются из кэша. Разрешение с холодным кэшем в 5–20 раз медленнее.
• Маршрутизация anycast: Корневые серверы и крупные публичные резолверы используют anycast, автоматически направляя запросы к ближайшему физическому узлу.
• Количество DNS-запросов на страницу: Одна веб-страница может инициировать 20–50 DNS-запросов (ресурсы CDN, аналитика, шрифты, рекламные сети). Браузеры распараллеливают их, но каждое уникальное имя хоста требует собственного поиска.
• Предварительная выборка DNS: Современные браузеры поддерживают <link rel="dns-prefetch" href="//cdn.example.com"> для разрешения имён хостов сторонних ресурсов до того, как они понадобятся, снижая воспринимаемую задержку.

DNS и альтернативные механизмы разрешения

Файл /etc/hosts обрабатывается перед DNS практически в каждой операционной системе. Это делает его незаменимым для локальной разработки — вы можете сопоставить myapp.local с 127.0.0.1 без каких-либо изменений в DNS-инфраструктуре.

Ключевые выводы и контрольный список решений

Используйте этот контрольный список при настройке или устранении неполадок DNS в любой производственной среде:

• Перед любой миграцией сервера: Уменьшите TTL до 300 секунд как минимум за 48 часов заранее
• Для доставляемости электронной почты: Убедитесь, что записи MX, SPF (TXT), DKIM (TXT), DMARC (TXT) и PTR правильно настроены
• Для безопасности: Включите DNSSEC для вашего домена и добавьте записи CAA для ограничения выпуска сертификатов
• Для конфиденциальности: Используйте DoT или DoH на клиентских устройствах и серверах; избегайте отправки незашифрованного DNS через ненадёжные сети
• Для производительности: Установите TTL 3600–86400 для стабильных записей; используйте 300 только для записей, которые часто меняются
• Для диагностики: Всегда запрашивайте авторитетный сервер напрямую с помощью dig @ns1.yourdomain.com, чтобы отличить задержку распространения от реальной ошибки конфигурации
• Для управления зоной: Увеличивайте серийный номер SOA каждый раз при изменении файла зоны — резолверы используют его для обнаружения изменений
• Для хостинга: Убедитесь, что делегирование серверов имён у вашего регистратора совпадает с записями NS в вашем файле зоны — несоответствие является наиболее распространённой причиной «неработающего DNS» после переноса домена

Часто задаваемые вопросы

В чём разница между DNS-резолвером и авторитетным DNS-сервером?

Рекурсивный резолвер (например, 8.8.8.8) — это посредник, который запрашивает иерархию DNS от имени вашего устройства и кэширует результаты. Авторитетный сервер имён содержит фактические записи зоны для конкретного домена и предоставляет окончательные ответы. Ваш резолвер запрашивает множество авторитетных серверов; авторитетный сервер вашего домена отвечает только за зоны, которые он обслуживает.

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

Задержка распространения вызвана кэшированием на основе TTL. Каждый резолвер, ранее кэшировавший вашу старую запись, будет продолжать её обслуживать до истечения TTL. Если ваш TTL составлял 86400 (24 часа), резолверы могут обслуживать старую запись до 24 часов после вашего обновления. Это не ошибка — это предусмотренный механизм кэширования, который делает DNS масштабируемым.

Что такое утечка DNS и почему это важно?

Утечка DNS происходит, когда ваше устройство отправляет DNS-запросы за пределы предполагаемого резолвера — как правило, к резолверу вашего интернет-провайдера — даже при использовании VPN или инструмента обеспечения конфиденциальности. Это раскрывает вашу активность в интернете вашему провайдеру. Вы можете проверить наличие утечек на dnsleaktest.com и устранить их, настроив VPN-клиент для принудительной маршрутизации DNS через собственный резолвер.

Может ли DNS использоваться как вектор атаки?

Да. Распространённые атаки на основе DNS включают отравление кэша (внедрение ложных записей в кэш резолвера), DDoS-усиление через DNS (использование открытых резолверов для перегрузки цели большими DNS-ответами), перехват DNS (перенаправление запросов на вредоносные серверы) и DNS-туннелирование (эксфильтрация данных путём их кодирования в строках DNS-запросов). DNSSEC снижает риск отравления кэша; ограничение частоты запросов и ограничение частоты ответов (RRL) на авторитетных серверах снижают риск усиления.

Как найти авторитетные серверы имён для любого домена?

Используйте dig с типом записи NS и флагом +short для чистого вывода:

dig NS example.com +short

Чтобы отследить полный путь делегирования от корня до авторитетного сервера, используйте:

dig +trace example.com

Это показывает каждый переход направления — корень → TLD → авторитетный — что является наиболее надёжным способом диагностики ошибок конфигурации делегирования.