Что такое DNSSEC?
DNSSEC (Domain Name System Security Extensions) добавляет цифровые подписи к наборам DNS-записей. Резолвер, выполняющий проверку DNSSEC, может использовать действительные подписи и цепочку доверия для аутентификации подписанных данных и обнаружения несанкционированных изменений. DNSSEC не шифрует DNS-запросы и ответы.Как работает DNSSEC
Цепочка доверия (пример с раздельными ключами):
Корневая зона (.)
├── Корневой KSK (якорь доверия) подписывает RRset типа DNSKEY корневой зоны
└── Корневой ZSK подписывает авторитетные RRset корневой зоны, включая RRset типа DS в родительской зоне для .com
└── Дайджест в DS соответствует KSK зоны .com
├── KSK зоны .com подписывает RRset типа DNSKEY зоны .com
└── ZSK зоны .com подписывает авторитетные RRset зоны .com, включая RRset типа DS в родительской зоне для example.com
└── Дайджест в DS соответствует KSK зоны example.com
├── KSK зоны example.com подписывает RRset типа DNSKEY зоны example.com
└── ZSK зоны example.com подписывает авторитетные RRset зоны example.com
Резолвер проверяет подписи и дайджесты DS, начиная с корневого якоря доверия
Типы записей DNSSEC
| Запись | Назначение | Описание |
|---|---|---|
| RRSIG | Подпись | Криптографическая подпись каждого набора записей |
| DNSKEY | Открытый ключ | Открытые ключи подписи зоны (KSK и ZSK) |
| DS | Делегирующий подписывающий объект | Хеш KSK дочерней зоны в родительской зоне |
| NSEC/NSEC3 | Подтверждённое отрицание | Доказывает отсутствие записи |
Типы ключей
| Ключ | Назначение | Периодичность ротации |
|---|---|---|
| KSK (Key Signing Key) | Подписывает записи DNSKEY | Зависит от политики; см. примечание ниже |
| ZSK (Zone Signing Key) | Подписывает остальные авторитетные RRset зоны; NS RRset делегаций и связанные с ними glue RRset на стороне родителя не подписываются ([RFC 4035 §2.2](https://www.rfc-editor.org/rfc/rfc4035.html#section-2.2)) | Зависит от политики; см. примечание ниже |
Период ротации зависит от роли KSK и политики оператора. Для KSK, связанного с записью DS в родительской зоне, [RFC 6781 §3.3](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3) считает годичный срок действия разумным при регулярной ротации. Для KSK, используемого как якорь доверия, ротация требует координации с операторами валидирующих DNS-резолверов, а срок действия ключа может быть значительно дольше ([RFC 6781 §3.2.2](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.2.2)).
Сроки ротации ZSK зависят от TTL записей DNSKEY и подписей RRSIG, распространения изменений в зоне, а также от того, как долго в кэшах резолверов могут храниться подписи, созданные ключом, который выводят из эксплуатации ([RFC 7583 §3.2.1](https://www.rfc-editor.org/rfc/rfc7583.html#section-3.2.1)). Для ZSK, хранящегося онлайн в условиях достаточно высокого риска компрометации, [RFC 6781 §3.3](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3) считает разумным планируемый срок действия в один месяц; это условная рекомендация, а не универсальный интервал ротации.
Смена корневого KSK 11 октября 2026 года
ICANN указывает, что смена KSK корневой зоны запланирована на 11 октября 2026 года. Операторам DNS-резолверов с проверкой DNSSEC следует убедиться, что KSK-2024 (идентификатор ключа 38696) указан в конфигурации якорей доверия. Не считайте, что автоматическое обновление якорей доверия прошло успешно. Если ключ отсутствует, проверьте, включено ли автоматическое обновление, и следуйте инструкциям производителя резолвера. Актуальные сведения см. в [рекомендациях ICANN по смене KSK корневой зоны](https://www.icann.org/resources/pages/ksk-rollover-en).
Процесс проверки DNSSEC
1. Клиент запрашивает у DNS-резолвера A-запись example.com
2. Резолвер получает A-запись и подпись RRSIG
3. Резолвер получает DNSKEY для проверки RRSIG
4. Резолвер проверяет DS относительно DNSKEY
5. Цепочка продолжается до корня, проверяя каждый уровень
6. Если все подписи действительны, ответ считается аутентифицированным
Что может выявить проверка DNSSEC
Для проверки нужны подписанные RRset, резолвер с проверкой DNSSEC и целостная цепочка доверия. Неподписанные данные и данные из незащищённых зон аутентифицировать нельзя.
| Угроза | Пример | Защита DNSSEC |
|---|---|---|
| Отравление кэша | Поддельные DNS-данные, внесённые в кэш резолвера | Резолвер с проверкой DNSSEC может отклонить данные, не прошедшие проверку подписи или цепочки доверия. |
| Подмена ответа | Изменение подписанного RRset при передаче | Изменённые данные не проходят проверку подписи. |
| Подмена DNS | Поддельный ответ для подписанной зоны | Резолвер с проверкой DNSSEC может отклонить ответ, не прошедший проверку. |
Что учитывать при внедрении
- Производительность: из-за подписей ответы больше (примерно 1000–4000 байт вместо примерно 100 байт)
- Управление ключами: нужны безопасные генерация, хранение и ротация ключей
- Подписание зоны: при изменении записей зону нужно подписывать заново
- Поддержка резолвера: клиентам нужны резолверы с проверкой DNSSEC
Лучшие практики
1. Выбирайте алгоритм подписи DNSSEC: [реестр алгоритмов DNSSEC IANA](https://www.iana.org/assignments/dns-sec-alg-numbers) рекомендует ECDSAP256SHA256 (алгоритм 13) для подписи и проверки. ECDSAP384SHA384 (14) может подойти для задач, требующих 192-битного уровня криптографической стойкости; перед сменой алгоритма проверьте поддержку резолверов ([RFC 9904](https://www.rfc-editor.org/rfc/rfc9904.html), [RFC 8624 §3.1](https://www.rfc-editor.org/rfc/rfc8624.html#section-3.1)).
2. Автоматизируйте ротацию ключей: используйте инструменты вроде OpenDNSSEC для жизненного цикла ключей
3. Следите за истечением: у подписей RRSIG есть сроки действия
4. Тестируйте до внедрения: проверяйте зону инструментами вроде dnsviz.net
5. Планируйте аварийные действия: документируйте процедуры смены ключей
При проверке цепочки DNSSEC резолвер подтверждает происхождение и целостность подписанных DNS-данных. Такая проверка не устанавливает, заслуживает ли доверия сайт или сервер по возвращённому адресу.