DNS — что это такое и как работает

DNS (Domain Name System) — система, хранящая информацию о доменах Интернета. Ключевая её функция ― предоставление IP-адреса узла или ресурса по его полному доменному имени.

Что такое DNS?

Каждый узел Интернета, а также сетей, построенных на его стандартах, имеет свой собственный уникальный сетевой адрес, состоящий из четырех байт (в версии протокола IPv4) или 16 байт (в версии протокола IPv6). В символьном виде его можно представить, например, так: 192.124.0.8 (IPv4) или так: 2001:0fb6:89ac:0000:0000:8a4b:0330:8634 (IPv6). В Интернете принято обозначать узлы доменными именами, например, www.stormwall.pro. Полное доменное имя — это, по сути, синоним IP-адреса, более «человеческое» название, понятное многим пользователям.

Доменное имя выглядит как последовательность доменов (символьных имен областей Интернета, выстроенных в иерархическую систему), с точками в качестве разделителей. Например, pro — домен первого уровня, а stormwall.pro — второго.

Соответствие между доменными именами и IP-адресами как раз и обеспечивает система DNS — она позволяет обращаться к отдельным интернет-узлам не по «загадочному» (с точки зрения людей) IP-адресу, а по доменному имени, указывая его, например, в браузере или в запросе к удаленной базе данных.

Серверы DNS — что это?

Работу DNS обеспечивают множество географически распределенных программных серверов, выстроенных в иерархическую (древовидную) структуру.

Система работает примерно так. Браузер или иная программа, взаимодействующая с Интернетом, отправляет запрос к «ближайшему» DNS-серверу, чтобы он по доменному имени нашел IP-адрес нужного узла. Если этот DNS-сервер «знает» адрес, то возвращает его в качестве ответа на запрос. Если же DNS-сервер не может найти адрес в своей базе данных, то отправляет запрос на вышестоящий по иерархии сервер либо на корневой. Вышестоящий сервер рассматривает запрос и поступает аналогичным образом: либо находит у себя и отправляет в качестве ответа IP-адрес искомого узла, либо передает запрос на корневой DNS-сервер, который начинает поиск на DNS-серверах, нижестоящих в иерархии доменов. Если IP-адрес удается найти, то он передается по цепочке тому DNS-серверу, с которого начался поиск, и тот отправляет ответ программе, которая сформулировала первоначальный запрос. Если поиск оказывается неудачным, то в программу возвращается сообщение об ошибке.

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

Аналогичным образом решается задача обратного поиска, когда по IP-адресу узла Интернета производится поиск его доменного имени. Такой поиск используется, в частности, в системах электронной почты.

Еще один важный вариант запроса — на добавление или изменение информации, содержащейся в DNS. Например, чтобы сайт с новым доменным именем (что-то вроде newservername.com) заработал, необходимо зарегистрировать его, сделать необходимые настройки и указать IP-адреса DNS-серверов, которые «знают», где находится новый сайт. Чтобы информация о новом доменном имени стала известна всему Интернету и чтобы новый сайт заработал, потребуется некоторое время.

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

Зоны DNS

Всё пространство имен DNS поделено на зоны, ответственность за которые несут те или иные DNS-серверы или группы DNS-серверов. Ответственные (или уполномоченные) серверы DNS могут выполнять запросы внутри своих зон. Если представить всю структуру DNS как дерево доменных имен, то зона — это, по сути, часть этого дерева, которая хранится на ответственном DNS-сервере.

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

В зависимости от того, какой поиск может вестись внутри зоны (IP-адреса по доменному имени, или, наоборот, доменного имени по IP-адресу) принято разделять зоны прямого просмотра и зоны обратного просмотра.

Виды DNS-записей

Каждый тип решает свою задачу. Так, A-запись DNS сопоставляет домен с IPv4-адресом сервера. Если она отсутствует или настроена неверно, веб-ресурс не сможет открываться по своему доменному имени. MX-запись определяет, на какие почтовые серверы направлять письма для домена. Подробнее — в таблице. 

Тип записи	Назначение	Пример
A	Сопоставляет доменное имя с IPv4-адресом, переводит название сайта в числовой IP-адрес сервера.	name.ru → 93.184.216.34
AAAA	Аналог A-записи для привязки доменного имени к IPv6-адресу. Обычно используется одновременно с A-записью для поддержки обеих версий IP-протокола.	name.ru → 2606:2800:220:1:248:1893:25c8:1946
CNAME	Создаёт псевдоним (алиас) для другого, канонического домена. Нельзя использовать для корневого домена — запрещено RFC 1034 (документом, который регламентирует требования к доменным именам). Узел с CNAME не должен одновременно содержать другие записи данных (A, AAAA, MX и т.д.).	www.name.ru →name.ru
MX	Определяет почтовые серверы, принимающие входящие письма для домена. Значение приоритета задаётся числом: чем оно ниже, тем выше приоритет сервера. Несколько MX дают резервирование. Указывают имя хоста (разрешается в IP через A/AAAA), не IP и не CNAME.	name.ru → 10 mail.name.ru.
TXT	Служит для хранения произвольных текстовых данных. Часто используется при подтверждении владения доменом, а также для публикации записей SPF, DKIM и DMARC.	name.ru TXT «v=spf1 include:_spf.name.ru ~all»
NS	Содержит информацию об авторитативных DNS-серверах, которые обслуживают доменную зону и отвечают на запросы о её записях. Без корректных NS делегирование доменной зоны работать не будет.	name.ru → ns1.example.ru
SOA	Обязательная запись для любой DNS-зоны. В ней указываются основные служебные параметры: первичный DNS-сервер, контактный адрес администратора зоны (в специальном формате DNS), серийный номер зоны для синхронизации изменений и временные интервалы (refresh, retry, expire).	name.ru → ns1.name.ru  admin.name.ru
SRV	Применяется для автоматического обнаружения сетевых сервисов и позволяет определить, на каком сервере доступна нужная служба, например, VoIP/SIP, XMPP, Kubernetes или Active Directory. В записи задаются приоритет, вес, номер порта и целевой узел.	_sip._tcp.name.ru → 10 60 5060 sip.name.ru
PTR	Нужен для обратного DNS-разрешения, связывает IP-адрес с доменным именем. Такие записи часто проверяются почтовыми системами при анализе сообщений на спам. Управление PTR-записью обычно находится у владельца IP — хостинг- или интернет-провайдера, а не у владельца домена.	164.34.0.192.in-addr.arpa → referrals.icann.org

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

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

Основное следствие DDoS-атак на DNS-серверы — их недоступность для пользователей. И поскольку DNS-серверы перестают обслуживать полезные внешние запросы, то и сайты, находящиеся «за» ними, тоже становятся недоступными. В этом случае владельцы несут потери как материальные (недополученная прибыль, иски недовольных клиентов, снижение их лояльности и отток), так и репутационные (волна негатива в СМИ и соцсетях). К сожалению, отражение DDoS-атак на DNS-серверы оказывается весьма непростым из-за того, что многие атаки проводятся посредством протокола UDP, имеющего немало уязвимостей.

Наиболее распространенные виды DDoS-атак на серверы DNS:

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

DNS-атака с отражением (DNS Reflection) основана на том, что ответ на DNS-запрос оказывается в разы длиннее самого запроса. Для атаки на DNS-сервер, намеченный в качестве цели, на один или несколько других DNS-серверов высылаются DNS-запросы, в которых вместо IP-адреса источника указывается IP-адрес жертвы. В результате на нее обрушивается поток DNS-ответов, на анализ которых тратится значительная часть производительности сервера-жертвы — вплоть до полного отказа в обслуживании.

DNS-амплификация (атака с усилением) использует особенности протокола DNS и неправильно настроенные открытые DNS-резолверы. Злоумышленник отправляет небольшие запросы на открытые DNS-серверы и подставляет в качестве обратного адреса IP жертвы. Сервер отвечает пакетами в разы большего объёма. Коэффициент усиления может составить 28–54×: то есть на каждый байт запроса жертва получает в десятки раз больше трафика.

DNS Hijacking (угон DNS) — злоумышленник вмешивается в сам процесс разрешения запросов, чтобы перенаправить пользователя на вредоносный ресурс. Способов подмены несколько:

• локальный перехват — замена локальных настроек на устройстве жертвы;
• угон через роутер — злоумышленник получает доступ к панели управления маршрутизатором и подменяет DNS-серверы. Изменения затрагивают все устройства, подключённые к этой сети;
• поддельные DNS-серверы — хакер компрометирует DNS-сервер и вносит изменения в его записи;
• атака «человек посередине» (man-in-the-middle) — злоумышленник перехватывает обмен данными между устройством пользователя и DNS-сервером, подменяя ответы и перенаправляя запросы на нужные ему ресурсы.

Цель — получить контроль над трафиком: украсть логины и пароли, распространить вредоносное ПО, подменить легитимный сайт фишинговым.

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

Механика такая: получив запрос, резолвер сначала проверяет кэш, и если записи нет — обращается дальше по иерархии DNS. Пока он ждёт ответа от авторитетного сервера, злоумышленник засыпает его поддельными ответами. Если фальшивый ответ приходит раньше настоящего и совпадает по параметрам запроса, которые использует резолвер для проверки соответствия ответа. Поддельная запись попадает в кэш и выдаётся всем последующим запросам, пока не истечёт её TTL (заданное время хранения).

Масштаб угрозы зависит от того, какой резолвер пострадал: атака на корпоративный сервер затронет сотрудников компании, а на устройство провайдера или публичного сервиса — тысячи и даже миллионы пользователей. Для борьбы с атаками такого типа используется протокол DNSSEC. 

Кроме того, рекомендуется предпринять следующие шаги:

• Убедиться, что DNS-серверы работают на выделенных физических серверах достаточной мощности. Желательно разместить их в разных дата-центрах, принадлежащих к разным сегментам сети и имеющим несколько маршрутов.
• Обеспечить регулярное обновление программного обеспечения DNS-серверов.
• Ограничить доступ к серверам DNS с правами администратора узкому кругу лиц, причем только изнутри сети или через VPN.
• «Закрыть» на сервере обработку неиспользуемых сетевых протоколов и сервисов.
• Отключить рекурсивную обработку запросов на DNS-серверах.
• Запретить динамические обновления зон DNS.
• Путем настроек обеспечить защиту от спуфинга.
• Отменить дополнительный поиск IP-адресов серверов DNS.
• Отключить перенос доменных зон на ваши DNS-серверы.
• Запретить и отключить все прочие функции DNS-серверов, которые в данный момент не используются.
• Обеспечить регулярное сканирование DNS-серверов на наличие известных уязвимостей.
• Заранее подключить сервис фильтрации трафика, направляемого на DNS-серверы, с автоматическим включением отражения атак на DNS.

DNSSEC — защита целостности DNS

Что такое DNSSEC? Это расширение протокола DNS, которое добавляет к DNS-записям криптографическую подпись, чтобы исключить подмену ответов. По сути, механизм аутентификации: он подтверждает, что полученные данные действительно пришли от легитимного источника и не были изменены по пути.

Как это работает: администратор домена подписывает DNS-записи закрытым ключом, а DNS-резолвер проверяет цифровую подпись с использованием открытых ключей и цепочки доверия DNSSEC. Если данные не сходятся с подписью, ответ признаётся недостоверным и отклоняется. Доверие выстраивается по цепочке от корневой зоны через DS-записи и ключи каждой дочерней зоны. 

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

Но есть и ограничения. DNSSEC не может:

• нейтрализовать DDoS-атаку — его роль именно в обеспечении целостности и достоверности данных. Ответы DNSSEC значительно больше по размеру, поэтому внедрение протокола повышает вероятность успешных атак типа DNS Amplification (усиление DNS);
• зашифровать информацию. Он только подписывает данные, но не обеспечивает их конфиденциальность. Запросы и ответы остаются открытыми — DNSSEC не скрывает, к каким доменам вы обращаетесь, и не предотвращает утечку этой информации через DNS. 

Проблему конфиденциальности решают протоколы, которые шифруют сам DNS-трафик:

1. DNS over TLS (DoT) передаёт DNS-запросы внутри зашифрованного TLS-соединения, обычно по порту 853. Защищает трафик от прослушивания и модификации в канале связи между клиентом и резолвером, поддерживается как на стороне клиента, так и на стороне DNS-сервера.
2. DNS over HTTPS (DoH) передаёт запросы внутри HTTPS-соединения. Они защищены от чтения и изменения третьими лицами. А поскольку запросы идут по порту 443, их трудно заблокировать, не заблокировав HTTPS целиком. DoH легко интегрируется в современные браузеры. DoH и DNSSEC не исключают, а дополняют друг друга: один меняет способ передачи запросов и обеспечивает их конфиденциальность, другой проверяет подлинность.

Инструменты мониторинга 

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

• dnstop — консольная утилита, которая анализирует DNS-трафик в реальном времени. Она собирает статистику и выводит её в виде интерактивных таблиц: по IP источника и назначения, типам запросов, доменам верхнего и второго уровня, кодам ответов. Поддерживает фильтрацию по типу запросов (A, PTR), кодам ответов (NXDOMAIN, REFUSED) и доменным именам, умеет анализировать как трафик, так и сохранённые файлы. Полезна для мониторинга нагрузки на DNS-сервер и выявления аномалий — неизвестных доменов верхнего уровня, запросов к локальным устройствам, нетипичного поведения приложений;
• packetbeat — более комплексное решение, распределённая система мониторинга сетевого трафика. Её агенты устанавливаются на серверах, захватывают сетевой трафик и анализируют протоколы прикладного уровня (HTTP, MySQL, Redis и др.). Packetbeat коррелирует сообщения в транзакции, показывая не просто поток пакетов, а взаимодействие процессов. Интегрируется с инструментами Elasticsearch и Logstash для хранения, поиска и анализа собранных данных. Полезен для мониторинга производительности приложений, выявления «узких мест» в обмене данными между сервисами и анализа ошибок и задержек на уровне протоколов.

Критерий	dnstop	packetbeat
Специализация	Только DNS	Прикладные протоколы (HTTP, MySQL и др.)
Масштаб	Узкоспециализированный инструмент	Распределённая система
Визуализация	Интерактивные таблицы в консоли	Дашборды
Сложность внедрения	Простая установка и запуск	Требует настройки агентов, инструментов для сбора данных
Когда применять	Мониторинг DNS-запросов на сервере или в сети	Анализ взаимодействия сервисов, мониторинг производительности

Для ручной проверки записей и отладки DNS используют утилиту dig, которая выводит детальную структуру ответа и значения TTL, а также утилиты nslookup и host для быстрой проверки прямого и обратного соответствия IP-адресов доменам. При работе с защищенными зонами незаменим drill — инструмент, специально предназначенный для отладки и валидации цепочек доверия DNSSEC.

Ответы на частые вопросы

Что такое DNS?

DNS (Domain Name System) — это распределённая иерархическая система разрешения имён, работающая по клиент-серверной модели. Она сопоставляет доменные имена с различными ресурсными записями (A, AAAA, MX, TXT и другими) через последовательные запросы к корневым, TLD- и авторитативным DNS-серверам. Наиболее известный сценарий — получение IP-адреса по имени сайта. Без этой системы приходилось бы вручную вводить числовые адреса для доступа к сервисам.

Зачем нужен DNS-сервер?

Он принимает запросы от пользователей, сопоставляет доменные имена с IP-адресами и возвращает их для последующего подключения к нужному серверу. Благодаря этому пользователям не приходится запоминать числовые адреса ресурсов. Помимо разрешения доменных имён, DNS-серверы выполняют и ряд других важных функций:  

• участвуют в распределении трафика, возвращают разные IP-адреса в зависимости от политики балансировки, географии или состояния сервисов;
• помогают обнаружить сервисы в микросервисной архитектуре; 
• обслуживают почту через MX-записи;
• участвуют в безопасности (политики email, подтверждение владения доменом при выпуске SSL/TLS-сертификатов, фильтрация вредоносного контента);
• кэшируют ранее разрешённые имена для ускорения повторных запросов;
• обеспечивают отказоустойчивость за счёт перенаправления запросов на резервные узлы при сбоях.

Что произойдёт, если DNS-сервер недоступен?

Если DNS-сервер не отвечает на запросы, браузер не сможет определить IP-адрес, связанный с доменным именем ресурса. В результате установить соединение с нужным сервером не получится, и сайт останется недоступным для пользователя. Вместо содержимого страницы браузер обычно отображает сообщения об ошибке, например: «Не удаётся найти DNS-адрес сайта», «DNS-сервер не отвечает» или «DNS-сервер временно недоступен». 

Чем отличается рекурсивный DNS-резолвер от авторитативного?

Эти компоненты выполняют разные задачи в архитектуре DNS. Рекурсивный резолвер выступает посредником между пользователем и системой доменных имён. Получив запрос, он сначала ищет нужную информацию в собственном кэше. Если записи там нет, резолвер самостоятельно проходит весь путь разрешения имени: обращается к корневым DNS-серверам, затем к серверам доменных зон верхнего уровня (TLD) и далее к авторитативным серверам. После получения ответа он возвращает результат клиенту. Благодаря этому устройству или браузеру пользователя достаточно отправить всего один запрос. Дополнительно резолвер кэширует полученные данные на заданный в настройках срок, что ускоряет повторные обращения и уменьшает нагрузку на DNS-инфраструктуру.

Авторитативный DNS-сервер — источник достоверной информации о домене. В отличие от резолверов, которые хранят данные временно, он содержит актуальные записи доменной зоны: A, AAAA, MX, NS, CNAME, TXT, SOA и другие. Именно этот сервер предоставляет окончательный ответ на запросы, сообщая IP-адреса ресурсов, параметры почтовой инфраструктуры и прочие сведения о домене. Любые изменения в DNS-конфигурации сначала вносятся на авторитативные серверы и лишь затем распространяются по остальной системе. Для повышения отказоустойчивости и распределения нагрузки обычно используется несколько авторитативных серверов для одной доменной зоны.

Если кратко, то рекурсивный резолвер ищет ответ, а авторитативный сервер его хранит и выдаёт.

Как DDoS-атака на DNS влияет на работу сайта?

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

Чтобы мощная DDoS-атака на DNS-серверы не застала вас врасплох, следует заранее подготовить план ваших действий после ее начала, а также план аварийного восстановления в случае отказа ваших серверов DNS в обслуживании. Разумеется, необходимо обеспечить также регулярные тренировки действий ИТ-специалистов при начале атак на DNS-серверы.