DNS Security Extensions

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

История

Разработка DNSSEC началась в середине 1990-х годов, когда сообщество специалистов по информационной безопасности осознало уязвимости протокола DNS. Первоначально DNS был спроектирован без учёта требований безопасности: данные передавались в открытом виде, и любой злоумышленник, контролирующий сетевой путь, мог подменить ответ DNS-сервера. В 1997 году Инженерный совет Интернета (IETF) опубликовал первые RFC, описывающие расширения безопасности DNS (RFC 2065 и RFC 2535). Однако ранние версии DNSSEC оказались сложными в реализации и не получили широкого распространения.

В 2005 году был опубликован новый набор стандартов (RFC 4033, RFC 4034, RFC 4035), которые стали основой современного DNSSEC. Эти спецификации упростили архитектуру, ввели новые типы записей (RRSIG, DNSKEY, DS, NSEC) и определили цепочку доверия от корневой зоны до конечного домена. В 2010 году корневая зона DNS была подписана, что позволило начать массовое внедрение технологии. С тех пор DNSSEC постепенно распространяется среди регистраторов доменов, хостинг-провайдеров и интернет-провайдеров.

В России внедрение DNSSEC началось позже, чем в ряде западных стран. По состоянию на 2024 год значительная часть российских доменов в зонах .RU и .РФ поддерживает DNSSEC, однако уровень использования среди конечных пользователей и организаций остаётся невысоким.

Принцип работы

DNSSEC основан на асимметричной криптографии. Каждая зона DNS (например, example.com) генерирует пару ключей: закрытый ключ (private key) и открытый ключ (public key). Закрытый ключ используется для создания цифровой подписи для каждой записи зоны, а открытый ключ распространяется для проверки подписи.

Основные типы записей

Для работы DNSSEC используются несколько новых типов ресурсных записей:

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

Цепочка доверия

Проверка подписи DNSSEC строится на иерархической модели DNS. Резолвер (например, DNS-сервер интернет-провайдера) должен доверять открытому ключу корневой зоны. Этот ключ является единственным «якорем доверия» (trust anchor), который распространяется вместе с программным обеспечением резолвера. Далее проверка осуществляется по цепочке:

1. Резолвер запрашивает DS-запись для зоны .RU у корневой зоны и проверяет её подпись с помощью корневого ключа.
2. Получив DS-запись, резолвер запрашивает DNSKEY-запись зоны .RU и проверяет, что её хеш совпадает с DS-записью.
3. Затем резолвер запрашивает DS-запись для домена example.ru у зоны .RU и проверяет её подпись.
4. Аналогично проверяется DNSKEY-запись example.ru.
5. Наконец, резолвер запрашивает A-запись для www.example.ru и проверяет её подпись с помощью открытого ключа example.ru.

Если на любом этапе подпись не совпадает, резолвер возвращает ошибку (SERVFAIL), и пользователь не получает IP-адрес сайта.

Классификация

DNSSEC можно классифицировать по нескольким признакам:

По типу реализации

• Полное внедрение (Full DNSSEC) — когда и зона, и резолвер поддерживают DNSSEC. В этом случае обеспечивается полная аутентификация данных.
• Частичное внедрение — когда зона подписана, но резолвер не проверяет подписи (например, из-за отсутствия поддержки или настройки). В этом случае DNSSEC не даёт преимуществ.
• DNSSEC-валидация на стороне резолвера — когда резолвер проверяет подписи, но зона не подписана. В этом случае резолвер не может подтвердить целостность данных, но может выявить отсутствие подписей.

По типу ключей

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

Применение

DNSSEC применяется в следующих сценариях:

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

Критика и ограничения

Несмотря на преимущества, DNSSEC имеет ряд недостатков и критикуется экспертами:

• Сложность внедрения — настройка DNSSEC требует знаний в области криптографии и DNS. Ошибки при генерации ключей или подписании зон могут привести к недоступности домена.
• Увеличение размера ответов — добавление подписей (RRSIG) и ключей (DNSKEY) увеличивает размер DNS-пакетов, что может вызывать проблемы с фрагментацией UDP и требовать использования TCP.
• Отсутствие конфиденциальности — DNSSEC не шифрует данные. Для защиты от прослушивания необходимо использовать дополнительные протоколы, такие как DNS over HTTPS (DoH) или DNS over TLS (DoT).
• Уязвимость к DDoS-атакам — DNSSEC-записи могут использоваться для усиления трафика в атаках типа DNS amplification, так как ответы с подписями могут быть значительно больше запросов.
• Проблемы с управлением ключами — регулярная смена ключей (rollover) требует координации между владельцем зоны и регистратором домена. Ошибки при смене ключей могут привести к разрыву цепочки доверия.
• Низкий уровень внедрения — по данным отчётов 2023–2024 годов, только около 30–40% доменов в зоне .RU и около 50% в зоне .РФ имеют подписанные зоны. Среди конечных пользователей процент резолверов, проверяющих подписи, ещё ниже.

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

• Корневая зона DNS была подписана 15 июля 2010 года. Это событие считается началом эры DNSSEC.
• В 2011 году была обнаружена уязвимость в реализации DNSSEC в некоторых DNS-серверах, позволявшая злоумышленникам обходить проверку подписей.
• Протокол DNSSEC не требует шифрования, поэтому его часто комбинируют с DoH или DoT для обеспечения как аутентификации, так и конфиденциальности.
• В России внедрение DNSSEC поддерживается Координационным центром доменов .RU/.РФ. На сайте центра доступны инструкции по подписанию зон.

Источники

• RFC 4033, RFC 4034, RFC 4035 (2005) — базовые спецификации DNSSEC.
• RFC 5155 (2008) — спецификация NSEC3.
• RFC 6840 (2013) — уточнения и дополнения к DNSSEC.
• RFC 9364 (2023) — обзор DNSSEC и рекомендации по внедрению.
• Материалы Координационного центра доменов .RU/.РФ (2024).
• Отчёты компании ICANN о состоянии внедрения DNSSEC (2023).