Все мы любим, когда интернет работает (и не виснет ?) — сайты открываются, видео грузятся, письма доходят. Но мало кто задумывается, как именно браузер узнаёт, куда вас отправить, когда вы вводите знакомое «habr.com».
Эта статья для тех, кто хочет понять, как именно устроена и работает система доменных имён, её защита на уровне DNSSEC и почему эта технология важна для безопасности интернета. Если вы техно-гик и не боитесь деталей — добро пожаловать под кат!
Так как DNSSEC — надстройка над DNS, сначала нужно объяснить самое простое.
Чтобы понять друг друга, мы с вами общаемся (слишком логично, я понимаю). Например, к вам подошёл прохожий и спросил: «как пройти на улицу Ленина?». Вы ему показали, объяснили маршрут и он пошёл по указанному пути и пришёл куда надо.
Но как понять компьютеру, куда пользователь хочет попасть? Если вы в браузере вводите что-то типа «смешные видео с котиками», браузер не будет использовать DNS. Он отправит этот запрос в поисковую систему, установленную по умолчанию, и та покажет вам результаты поиска. Стоп, а тогда зачем нужен DNS, всё же и так работает?
Его роль начинается, когда вы вводите конкретный адрес сайта, например www.wikipedia.org или www.youtube.com. Так вот DNS переводит удобные человеку имена в числовые адреса, понятные машине, например 192.0.2.44. Иначе пришлось бы запоминать длинные наборы цифр. А так, достаточно ввести имя, и система найдёт нужный сервер.
Помните страшную пугалку примерно из 2010-го: «Я вычислю тебя по айпи»? В ней и кроется то, как все устройства в сети общаются — IP-адреса. Все компьютеры, подключённые к интернету, включая смартфоны, настольные компьютеры и серверы, предоставляющие контент для огромных торговых веб-сайтов, нахо��ят друг друга и обмениваются информацией с помощью этих цифр.
Серверы DNS преобразуют запросы по именам в IP-адреса, обеспечивая соединение конечного пользователя с определённым сервером при вводе доменного имени в веб-браузер пользователя. Такие сообщения называются запросами.
Допустим, у нас есть адрес: www.habr.com. На первый взгляд, просто веб-сайт, но в контексте DNS это структура из трёх уровней, и читается она с конца вперёд:
.com — домен верхнего уровня (Top-Level Domain, TLD), относящийся к категории общих доменов верхнего уровня, контролируемых центральными организациями.
habr — домен второго уровня (Second-Level Domain), уникальное имя, зарегистрированное в зоне .com. Обычно представляет бренд, компанию или проект.
www — домен третьего уровня (Third‑Level Domain) или поддомен, часто ассоциируется с основным веб‑сайтом или сервисом компании.
Интересный факт: www — лишь условность, сайты отказываются от него в пользу доступа напрямую через домен второго уровня.
В экосистеме DNS есть две ключевые роли
Авторитативный DNS — сервис предоставляет механизм обновления, который разработчики используют для управления публичными DNS‑именами. Он хранит окончательные записи домена: какие IP привязаны к имени, куда идут письма, какие серверы имён обслуживают зону. Любые изменения в настройках домена вносятся именно в авторитативную зону и затем распространяются по сети.
Типы записей:
A — связывает доменное имя с IPv4-адресом.
AAAA — то же самое для IPv6.
MX — указывает серверы для приёма электронной почты.
CNAME — алиас: одно имя перенаправляется на другое.
TXT — произвольный текст, часто используется для верификации (SPF, DKIM, DMARC).
NS — показывает, какие серверы управляют зоной (authoritative nameservers).
SRV — указывает хосты и порты для специальных сервисов (VoIP, XMPP и т. п.).
DS — используется в DNSSEC для передачи информации о ключах дочерней зоны.
Обычно пользователи не отправляют запросы напрямую к авторитативным DNS-сервисам.
Рекурсивный DNS-сервер — это промежуточный резолвер, к которому обычно обращается ваш компьютер. Он берёт на себя всю рутинную работу по поиску ответа. Это значит, если в его кэше нет нужной записи, он сам пройдёт путь по иерархии DNS и вернёт готовый результат клиенту.
DNS использует и UDP, и TCP на порту 53. Большинство простых запросов идёт по UDP — это быстро и без установления соединения. TCP применяется, когда ответ большой (truncated) или при переносе зон (AXFR), а также для надёжного обмена (при необходимости).
Важно понимать разницу: рекурсивный резолвер делает работу за клиента и возвращает готовый ответ, а промежуточные запросы между серверами обычно итеративны — каждый узел отдаёт либо ответ, либо ссылку на следующий уровень.
Как протекает типичный запрос: клиент запрашивает рекурсивный резолвер. Резолвер смотрит в кэш — если запись есть, отвечает сразу. Если нет, резолвер выполняет серию итеративных запросов к другим серверам: сначала к корневым, затем к TLD (например .ru), затем к авторитативным для конкретной зоны. На каждом шаге сервер возвращает либо окончательный ответ, либо направление дальше — до тех пор, пока не будет получен точный IP.
Как DNS перенаправляет трафик на сайт?
Вы открываете браузер, вводите адрес, например, habr.com и нажимаете Enter.
Запрос сначала отправляется на специальный DNS-сервер провайдера — это и есть преобразователь имён (резолвер). Он знает, куда отправить запрос дальше.
Преобразователь имён DNS перенаправляет запрос корневому DNS-серверу.
Тот же преобразователь повторно перенаправляет запрос сайта www.habr.com одному из серверов имён домена верхнего уровня .com.
Сервер ищет в зоне хостинга habr.com запись www.habr.com, получает связанное с ней значение, например IP-адрес веб-сервера 192.0.2.44, и возвращает этот адрес преобразователю имён DNS.
Теперь преобразователь имён DNS знает, какой IP-адрес требуется пользователю. Он возвращает это значение веб-браузеру. И этот IP-адрес кешируется у провайдера для ускорения последующих запросов.
Теперь браузер может обратиться напрямую к нужному серверу по IP и загрузить страницу сайта.
Как быстро проверить DNS-зону с помощью dig
Dig или domain information groper — это инструмент командной строки, используемый для запроса информации о домене на DNS-серверах. Вы можете использовать его для устранения неполадок DNS. На большинстве Unix-систем он уже установлен; в Windows можно использовать WSL или установить пакет с DNS-утилитами.
Базовый запрос даёт общее представление о зоне.
Откройте терминал и вставьте туда:
dig <your-domain.com>Так мы получим общий обзор конфигурации DNS-домена.
Команда покажет общую картину DNS-записей: A, AAAA, MX и другие. Такой способ часто используют перед миграцией сайта на новый сервер — сразу видно, корректно ли разрешаются имена и не осталось ли старых IP-шников.
Если нужно проверить что-то конкретное, например почтовые записи, добавляем тип:
dig <your-domain.com> MXТак можно убедиться, что письма идут на нужный сервер и нет ли ошибок в конфигурации.
Для обратного поиска — когда есть IP, но не знаете, к какому домену он относится, используйте:
dig -x <IP address>Эта команда поможет понять, кто стоит за адресом, если вы, например, заметили подозрительную активность в логах.
Наконец, можно опрашивать конкретный DNS-сервер, чтобы проверить, как он видит ваш домен:
dig @1.1.1.1 your-domain.comЭто удобно, когда нужно убедиться, что изменения уже распространились и кеш обновился у разных провайдеров.
Как работает DNSSEC
Когда создавали DNS, о безопасности почти не думали — главное было, чтобы система просто работала. Но так, конечно, долго продолжаться не могло. И в 90-х годах инженеры из Инженерной проектной группы Интернета (IETF), осознали, что отсутствие более надёжной аутентификации в DNS превратилось в проблему.
Потому что в то время клиенты судили о верности полученной информации исключительно по двухбайтовому идентификатору запроса. А значит злоумышленнику требовалось перебрать всего 65536 значений, чтобы «отравить кэш». Так появились DNSSEC — расширения безопасности DNS, которые добавляют криптографическую подпись каждой записи.
Дальнейшие исследования и атаки, включая знаменитую находку Дэна Камински в 2008 году, выявили уязвимость в масштабах всего интернета — это подтвердило необходимость защиты. Массовое отравление кэша DNS способно парализовать работу ресурсов и своровать у пользователей данные.
Главное, что в DNSSEC криптографически подписываются не сами DNS-запросы и ответы, а данные DNS, которые подписываются владельцем этих данных.
Каждая зона DNS имеет пару открытых/закрытых ключей. Владелец зоны использует закрытый ключ зоны для подписи данных DNS в зоне и создания цифровых подписей на этих данных. По названию «закрытый ключ» можно догадаться, что его утечка может скомпрометировать цифровую подпись зоны, используемую для её аутентификации в системе DNSSEC.
Однако открытый ключ зоны публикуется в самой зоне, и любой желающий может его получить. Любой рекурсивный резолвер, который ищет данные в зоне, также получает открытый ключ зоны, который он использует для проверки подлинности данных DNS. Резолвер подтверждает, что цифровая подпись на полученных им данных DNS действительна. Если это так, то данные DNS являются легитимными и возвращаются пользователю.
Если подпись не подтверждается, резолвер предполагает наличие атаки, отбрасывает данные и возвращает пользователю сообщение об ошибке.
DNSSEC добавляет две важные функции в протокол DNS:
Аутентификация происхождения данных позволяет резолверу криптографически проверить, что полученные им данные действительно поступили из зоны, из которой, по его мнению, они были получены.
Защита целостности данных позволяет резолверу знать, что данные не были изменены при передаче с момента их первоначальной подписи владельцем зоны с помощью закрытого ключа зоны.
Цепочка доверия строится следующим образом: на верхнем уровне — корневая зона, подписанная своим DNSKEY (публичным ключом). В иерархии каждая зона содержит свой DNSKEY и подписи (RRSIG) для своих записей, а также DS-записи в родительской зоне — «отпечаток» (хэш) DNSKEY дочерней зоны, который публикуется в зоне-родителе. Это как цепочка: доверие передаётся сверху вниз. Trust anchor — это стартовая точка проверки, обычно является корневым ключом или ключем, внедрённым в DNS-валидатор.
Что именно подписывается? В DNSSEC для каждой DNS-записи создаётся цифровая подпись (RRSIG), которая подтверждает, что конкретная запись не была изменена. Эти подписи используют криптографические алгоритмы, такие как RSA или ECDSA. В ответах DNS-серверов включаются соответствующие RRSIG-записи, а также DNSKEY-записи с открытыми ключами.
Проверка работает так: при запросе домена резолвер сначала получает DNSKEY-записи и DS-записи, затем проверяет подписи (RRSIG) на ответных записях, подтверждая их целостность и подлинность с помощью публичных ключей. Это устраняет угрозы кеш-пойзонинга и атак, основанных на подделке ответов.
Для проверки DNSSEC можно использовать команду:
dig +dnssec example.com DNSKEYОна покажет DNSKEY-записи:
dig +dnssec example.com AА также A-записи с включёнными RRSIG и другими DNSSEC-записями. В частности, наличие RRSIG на A-записи говорит о том, что ответ аутентифицирован и защищён. Пример вывода:
example.com. 3600 IN RRSIG A 8 2 3600 20250421000000 20250420000000 12345 example.com. abcdef...`Что касается NSEC и NSEC3, эти записи используются для доказательства отсутствия DNS-записи (например, что поддомена нет). Они позволяют безопасно отвечать на вопрос «этот рекорд существует или нет?». NSEC3, в отличие от NSEC, был разработан для предотвращения полного перечисления всех существующих доменных имён (так называемого «zone walking») с помощью хеширования.
Однако важно помнить, что DNSSEC не шифрует трафик и не защищает от локальных атак типа MITM (Man-in-the-Middle). Также неправильная настройка ключей и неправильное управление ими могут привести к недоступности доменов, что делает внедрение DNSSEC довольно сложным и требующим постоянного контроля. Основной недостаток — необходимость поддержки и управления криптографическими ключами у регистраторов и DNS-операторов.
Рассмотрим BIND на Ubuntu — один из самых популярных и надёжных DNS-серверов. Как управлять доменами и улучшить безопасность? На примере Ubuntu пошагово покажем, как развернуть и настроить сервер для решения задач в инфраструктуре.
Установка и базовая настройка BIND на Ubuntu
Первым шагом для запуска собственного DNS-сервера является установка программного обеспечения BIND (Berkeley Internet Name Domain). В Ubuntu это легко сделать с помощью стандартного пакетного менеджера apt:
$ sudo apt update
$ sudo apt install bind9 bind9-docВот и всё. После выполнения команд выше BIND будет установлен и готов к настройке.
По умолчанию BIND слушает DNS-запросы и по IPv4, и по IPv6. Если ваш сервер должен обслуживать только IPv4-запросы, можно отключить IPv6. IPv6 можно отключить, отредактировав следующий файл и добавив параметр « -4 » в раздел OPTIONS :
$ sudo vim /etc/default/named
#
# run resolvconf?
RESOLVCONF=no
# startup options for the server
OPTIONS="-u bind -4"Чтобы изменения вступили в силу, перезапустите службу:
$ sudo systemctl restart bind9Основные конфигурационные файлы BIND на Ubuntu лежат в папке /etc/bind/. Здесь главный файл – это named.conf, в котором содержатся ссылки на другие файлы конфигурации. Обычно в него напрямую не вносят изменения. Конфигурация стандартных зон, таких как localhost и обратной зоны 255.in-addr.arpa, описана в named.conf.default-zones в соответствии с рекомендациями RFC 1912. Общие параметры сервера настраиваются в named.conf.options, а определение пользовательских зон — в файле named.conf.local.
Настройка основной (первичной) зоны
Начнём с некоторых общих настроек
Для повышения безопасности полезно в файле named.conf.options отключить прослушивание IPv6 и запретить передачу зон в обход правил:
options {
listen-on-v6 { none; };
allow-transfer { none; };
};Первый параметр полностью отключает IPv6, второй вариант глобально отключает передачу зон (в противном случае она включена по умолчанию). Как правило, не рекомендуется публиковать содержимое наших зон кому-либо в Интернете. Мы разрешим передачу зон только для конкретного IP-адреса вторичного участника.
Согласно документации Ubuntu, статические файлы зон (обновляемые только администраторами) обычно следует размещать непосредственно в папке /etc/bind/. Однако в нашем случае создаваемые зоны будут автоматически подписаны и обновлены записями DNSSEC. Для хранения динамических зон лучше всего использовать папку /var/lib/bind/. Если вы хотите использовать папку по умолчанию, вам потребуется изменить настройки AppArmor.
В файле named.conf.local нужно объявить зону для нашего домена ns-testing.com и создать файл db.ns-testing.com с содержимым зоны. Начнём с определения зоны:
$ sudo vim /etc/bind/named.conf.local
//
// Поместите здесь любую локальную конфигурацию
//
// Рассмотрите возможность добавления зон RFC 1918, если они не используются в вашей организации
//include "/etc/bind/zones.rfc1918";
zone "ns-testing.com" {
// Тип зоны
type primary;
// Файл зоны
file "/var/lib/bind/db.ns-testing.com";
// Вторичный сервер, которому разрешена передача зоны
allow-transfer { 98.71.216.161; };
// Уведомление вторичных серверов об изменениях (по умолчанию включено)
notify yes;
};Здесь:
type primary означает, что это первичный (основной) сервер для зоны.
file указывает путь к файлу с записями зоны. Мы используем /var/lib/bind/ для динамических зон.
allow-transfer разрешает передачу зоны только серверу с IP 98.71.216.161 (вторичный DNS).
notify yes включает уведомления вторичным серверам об изменениях зоны (ускоряет синхронизацию).
Создание файла зоны
Файл зоны содержит все DNS-записи для вашего домена. Создайте файл /var/lib/bind/db.ns-testing.com с таким содержимым:
$ sudo vim /var/lib/bind/db.ns-testing.com
$TTL 3600
@ IN SOA ns1.ns-testing.com. admin.ns-testing.com. (
2 ; Serial
3600 ; Refresh
300 ; Retry
86400 ; Expire
3600 ) ; Negative Cache TTL
IN NS ns1.ns-testing.com.
IN NS ns2.ns-testing.com.
ns1 IN A 51.137.105.102
ns2 IN A 98.71.216.161
www IN A 51.137.105.102
IN A 98.71.216.161Формат Resource Record (RR), используемый в файле зоны. Проще говоря, каждая строка в файле зоны, описывающая доменное имя и связанные с ним данные (IP‑адрес, сервер имён, почтовый сервер и т. д.), должна подчиняться этому формату:
Имя (Name) — необязательное поле, указывающее доменное имя, к которому относится запись. Например, www или mail. Если его нет, используется имя из предыдущей строки..
TTL (Time to Live) — время жизни записи в кэше (в сек). Это число говорит DNS‑резолверу, как долго он может хранить эту информацию, прежде чем нужно снова обратиться к серверу. Если TTL не указан, берётся значение по умолчанию из директивы $TTL, которая стоит в начале файла.
Класс (Class) — обозначает тип сети или протокола, для которого применима запись. Почти всегда используется IN (Internet). Другие классы, вроде CH (ChaosNet) или HS (Hesiod), встречаются только в старых системах.
Тип RR — тип записи (например, NS, A, SOA).
Данные (Data) — содержимое записи. Это поле зависит от типа. Например, для A это IP‑адрес, для NS — имя сервера, для MX — приоритет и адрес почтового сервера.
Для более аккуратного обновления рекомендуется использовать утилиту rndc — Remote Name Daemon Control, которая перезагрузит всё динамически.
Например, эта команда перечитывает основной конфигурационный файл и загружает новые зоны:
sudo rndc reconfigА эта перезагружает конкретную уже существующую зону, применяя в ней изменения без остановки работы всей службы:
sudo rndc reload ns-testing.comДальше — больше
Наконец, DNSSEC — это основа для следующего слоя безопасности. На его базе строятся новые технологии вроде DANE, которые позволяют проверять подлинность TLS‑сертификатов и почтовых серверов без участия центров сертификации. Чем больше провайдеров и сервисов начнут использовать DNSSEC и валидацию записей прямо в резолверах, тем меньше останется места для подмен и атак — и тем спокойнее и надёжнее будет интернет для всех нас.
© 2025 ООО «МТ ФИНАНС»