DNSSEC¶

DNSSEC (Domain Name System Security Extensions) — это набор расширений протокола DNS (системы доменных имён), предназначенный для обеспечения целостности и подлинности данных, передаваемых в процессе разрешения доменных имён. DNSSEC не шифрует трафик, а добавляет криптографические цифровые подписи к DNS-записям, что позволяет клиентам проверять, что полученный ответ действительно исходит от авторитетного источника и не был изменён злоумышленником в ходе передачи (атака «человек посередине») или подмены кэша (DNS-спуфинг).

¶Предпосылки создания

Оригинальный протокол DNS, разработанный в 1980-х годах Полом Мокапетрисом, не предусматривал никаких механизмов безопасности. Он был спроектирован как открытая и децентрализованная система, где любой DNS-сервер мог кэшировать и передавать записи без проверки их подлинности. Это создавало уязвимости:

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

Осознание этих рисков привело к началу разработки DNSSEC в середине 1990-х годов. Первая спецификация (RFC 2065) была опубликована в 1997 году, но она оказалась сложной в реализации. Более зрелая версия, описанная в серии RFC (4033, 4034, 4035), вышла в 2005 году и стала основой современного DNSSEC.

¶Как работает DNSSEC

DNSSEC добавляет в DNS четыре новых типа ресурсных записей (RR), которые формируют цепочку доверия:

• RRSIG (Resource Record Signature) — цифровая подпись для набора записей одного типа (например, для всех A-записей домена). Подпись создаётся закрытым ключом зоны.
• DNSKEY (DNS Public Key) — открытый ключ, используемый для проверки подписей RRSIG. Существует два типа: ZSK (Zone Signing Key) и KSK (Key Signing Key).
• DS (Delegation Signer) — хеш открытого ключа (KSK) дочерней зоны, размещаемый в родительской зоне. Связывает зоны в цепочку доверия.
• NSEC / NSEC3 (Next Secure) — записи, доказывающие, что запрашиваемое доменное имя не существует. NSEC3 — улучшенная версия, предотвращающая перебор зоны.

¶Процесс проверки

1. Запрос: клиент (stub-резолвер) отправляет запрос рекурсивному DNS-серверу, поддерживающему DNSSEC.
2. Получение ответа: рекурсивный сервер запрашивает у авторитетного сервера не только запись (например, A-запись для example.com), но и соответствующую подпись RRSIG.
3. Верификация: рекурсивный сервер проверяет подпись RRSIG с помощью открытого ключа (DNSKEY) зоны example.com.
4. Цепочка доверия: сервер последовательно проверяет подлинность DNSKEY зоны example.com, используя DS-запись в родительской зоне .com, затем DNSKEY зоны .com через корневую зону. Корневая зона завершает цепочку, так как её открытый ключ (корневой KSK) является точкой доверия и встроен в доверенное программное обеспечение (например, в ОС или DNS-резолвер).
5. Результат: если все подписи корректны и цепочка доверия не нарушена, клиент получает подтверждённый ответ. В противном случае возвращается код ошибки SERVFAIL.

¶Ключи и управление

DNSSEC использует асимметричную криптографию (RSA, ECDSA, Ed25519). Каждая зона имеет два типа ключей для повышения безопасности и гибкости:

• ZSK (Zone Signing Key) — используется для подписи всех записей в зоне. Меняется чаще (например, раз в месяц) для снижения риска компрометации.
• KSK (Key Signing Key) — используется для подписи только набора DNSKEY-записей (включая ZSK). Меняется реже (раз в год или реже). Открытая часть KSK передаётся в родительскую зону через DS-запись.

Процесс ротации ключей (Rollover) требует синхронизации между родительской и дочерней зонами, чтобы избежать разрыва цепочки доверия.

¶Преимущества и недостатки

¶Преимущества

• Целостность данных: гарантирует, что DNS-ответ не был изменён.
• Подлинность источника: подтверждает, что ответ исходит от авторитетного сервера.
• Защита от отравления кэша: делает невозможным внедрение поддельных записей.
• Повышение доверия к другим протоколам: DNSSEC является основой для DANE (DNS-based Authentication of Named Entities), который позволяет связывать TLS-сертификаты с доменными именами без участия центра сертификации.

¶Недостатки

• Сложность управления: требуется администрирование криптографических ключей, их ротация и синхронизация с родительской зоной.
• Увеличение размера ответов: подписи RRSIG могут увеличивать размер DNS-пакетов, что иногда приводит к необходимости использования TCP вместо UDP.
• Отсутствие конфиденциальности: DNSSEC не шифрует данные, поэтому злоумышленник может видеть, какие домены запрашивает пользователь (для шифрования используется DNS-over-TLS или DNS-over-HTTPS).
• Риск ошибок: неправильная настройка DNSSEC может привести к тому, что домен станет недоступным для пользователей, чьи резолверы проверяют подписи (validation failures).

¶Внедрение и распространение

Внедрение DNSSEC началось с корневой зоны DNS. В 2010 году корневая зона была подписана, что стало ключевым событием для глобального развёртывания. К 2024 году большинство доменов верхнего уровня (gTLD, например, .com, .org, .net) и многие национальные домены (ccTLD, например, .ru, .рф, .de, .uk) поддерживают DNSSEC.

По данным отчётов ICANN и APNIC, по состоянию на 2024 год около 30-35% всех доменов второго уровня имеют подписанные зоны. Однако уровень валидации (проверки подписей) со стороны пользовательских резолверов ниже — примерно 10-15% интернет-трафика проходит проверку DNSSEC. Крупные провайдеры DNS-услуг (Cloudflare, Google Public DNS, Quad9) активно поддерживают валидацию.

¶Ситуация в России

В России DNSSEC поддерживается на уровне национальных доменов .ru и .рф (Координационный центр доменов .RU/.РФ). Многие крупные регистраторы и хостинг-провайдеры предлагают автоматическое подписание зон для клиентов. Тем не менее, уровень внедрения среди малых и средних сайтов остаётся невысоким из-за сложности настройки.

¶Критика и альтернативы

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

• DNS-over-TLS (DoT) и DNS-over-HTTPS (DoH) — протоколы, шифрующие DNS-запросы, но не обеспечивающие целостность самих данных.
• DNSCrypt — протокол, шифрующий трафик между клиентом и резолвером, но не поддерживаемый на уровне авторитетных серверов.
• DNSSEC + DoT/DoH — комбинация, считающаяся наиболее безопасной: DNSSEC гарантирует подлинность, а DoT/DoH — конфиденциальность.

¶Будущее DNSSEC

Развитие DNSSEC продолжается. Основные направления:

• Упрощение управления: появление инструментов автоматической подписи зон (например, OpenDNSSEC, BIND с опцией auto-dnssec) и интеграция с панелями управления хостингом.
• Улучшение алгоритмов: переход на постквантовую криптографию для защиты от будущих квантовых компьютеров.
• Расширение использования DANE: для защиты электронной почты (SMTP MTA-STS) и HTTPS-соединений.
• Повышение осведомлённости: образовательные кампании для администраторов доменов и провайдеров.

¶Интересные факты

• Первый домен, подписанный с использованием DNSSEC, — se (Швеция) в 2005 году.
• Ключ корневой зоны DNSSEC (Root KSK) имеет длину 2048 бит и хранится в защищённом аппаратном модуле безопасности (HSM) в США, с географически распределёнными резервными копиями.
• В 2018 году была проведена первая плановая смена (rollover) корневого KSK, которая потребовала координации по всему миру.

¶Источники

• RFC 4033, 4034, 4035 — «DNS Security Introduction and Requirements», «Resource Records for the DNS Security Extensions», «Protocol Modifications for the DNS Security Extensions».
• RFC 6840 — «Clarifications and Implementation Notes for DNSSEC».
• RFC 6781 — «DNSSEC Operational Practices».
• ICANN, «DNSSEC: What Is It and Why Is It Important?»
• Координационный центр доменов .RU/.РФ, «DNSSEC в России».
• APNIC Blog, «DNSSEC Validation Rates by Country».