Что такое DNSSEC и как он работает

DNSSEC (DNS Security Extensions) добавляет к DNS-записям цифровые подписи, чтобы резолверы могли проверить, что ответ действительно пришёл от владельца домена и не был изменён в пути. Он ничего не шифрует: подлинность подтверждается цепочкой доверия, которая начинается с корня DNS.

В обычном DNS нет способа отличить настоящий ответ от поддельного. DNSSEC, стандартизованный в RFC 4033, 4034 и 4035, закрывает этот пробел. В этом руководстве разбираются задействованные типы записей, принцип проверки и ошибки, которые чаще всего выводят подписанные домены из строя.

Какую проблему решает DNSSEC

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

DNSSEC делает подделку обнаружимой. Каждый набор записей подписывается закрытым ключом зоны, а соответствующий открытый ключ публикуется в DNS. Проверяющий резолвер сверяет подпись и отвергает всё, что не проходит проверку. Если вам нужно сначала освежить в памяти, что такое резолверы и авторитетные серверы, прочитайте статью что такое DNS и как он работает.

Типы записей DNSSEC

Наше руководство по типам DNS-записей рассказывает об обычных записях, таких как A, MX и TXT, которые защищают эти подписи.

Зачем нужно доказывать отсутствие записи

Без NSEC или NSEC3 злоумышленник мог бы подделать ответ NXDOMAIN («такого имени не существует»), который не может нести собственную подпись, поскольку подписывать нечего. Записи NSEC дают резолверу подписанное утверждение, что между двумя именами ничего нет, поэтому и отрицательный ответ можно проверить.

Ключи подписи ключей и ключи подписи зоны

Большинство зон использует два вида ключей, и оба публикуются как записи DNSKEY:

• Ключ подписи зоны (ZSK), флаги DNSKEY 256: подписывает обычные наборы записей зоны. Его можно часто менять, не привлекая никого другого.
• Ключ подписи ключей (KSK), флаги DNSKEY 257: подписывает только набор записей DNSKEY. Его хеш попадает в запись DS у родителя, поэтому для смены нужно обновить данные у регистратора.

Разделение ролей позволяет проводить плановую смену ключей внутри вашего DNS-провайдера, а более редкая смена KSK остаётся единственной, затрагивающей родительскую зону. Некоторые конфигурации вместо этого используют один комбинированный ключ подписи: так проще, и это обычное дело для современных алгоритмов на эллиптических кривых, например алгоритма 13 (ECDSA P-256 с SHA-256).

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

Подпись полезна, только если резолвер доверяет ключу, которым она создана. DNSSEC выстраивает это доверие шаг за шагом от корня, подписанного в 2010 году. Проверяющие резолверы поставляются с KSK корневой зоны в качестве встроенного якоря доверия. Чтобы проверить www.example.com, резолвер:

1. С помощью корневого якоря доверия проверяет набор DNSKEY корня.
2. Проверяет подписанную запись DS для com в корневой зоне, затем сверяет её с KSK из набора DNSKEY зоны com.
3. Проверяет подписанную запись DS для example.com в зоне com, затем сверяет её с KSK, опубликованным example.com.
4. С помощью набора DNSKEY зоны example.com проверяет RRSIG для A-записей www.example.com.

Если проверка проходит на каждом звене, ответ считается безопасным (secure). Если у родителя нет записи DS для зоны, зона небезопасна (insecure, то есть не подписана), и ответ возвращается как обычно. Если DS есть, а подписи не проверяются, ответ считается недостоверным (bogus).

Как выглядит проверка: AD и SERVFAIL

Когда проверяющий резолвер успешно проверил ответ, он устанавливает в ответе флаг AD (Authenticated Data). Его можно увидеть с помощью dig:

$ dig +dnssec www.example.com A @1.1.1.1

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.com.  300  IN  A      192.0.2.10
www.example.com.  300  IN  RRSIG  A 13 3 300 20261101000000 20261011000000 12345 example.com. (signature data)

Если проверка не проходит, резолвер не отдаёт возможно поддельные данные. Он возвращает SERVFAIL, а пользователю это выглядит так же, как несуществующий сайт или сбой DNS. Чтобы убедиться, что причина в DNSSEC, повторите запрос с отключённой проверкой:

dig www.example.com A           # status: SERVFAIL
dig +cd www.example.com A       # status: NOERROR, answer returned

Если запрос с +cd (checking disabled, проверка отключена) проходит, а обычный нет, значит, DNSSEC зоны сломан. Наша проверка DNSSEC выполняет эти проверки за вас и показывает состояние DS, DNSKEY и подписей.

Как чаще всего ломается DNSSEC

Переезд к другому DNS-провайдеру без удаления записи DS

Это классический сбой. Запись DS в реестре всё ещё указывает на KSK прежнего провайдера. После смены серверов имён новый провайдер либо отдаёт зону без подписи, либо подписывает её другими ключами. Проверяющие резолверы находят DS без подходящего ключа, считают зону недостоверной, и каждый запрос возвращает SERVFAIL.

Безопасный переезд выглядит так:

1. У регистратора удалите запись DS.
2. Подождите, пока прежняя DS исчезнет из кешей: не меньше TTL записи DS в родительской зоне, который можно увидеть командой dig example.com DS. Запас в день-два считается обычной мерой предосторожности.
3. Смените серверы имён на серверы нового провайдера и подождите, пока устареют прежние записи NS.
4. Включите DNSSEC у нового провайдера и опубликуйте его новую запись DS у регистратора.

Некоторые провайдеры поддерживают схему с несколькими подписывающими (multi-signer), которая позволяет избежать периода без подписи, но для неё нужно взаимодействие обоих провайдеров.

Истёкшие подписи

У каждой RRSIG есть срок действия. Если процесс подписи останавливается, например на собственном сервере, где сломалась задача повторной подписи, подписи со временем истекают, и зона становится недостоверной.

Слишком быстрая смена ключей

Если удалить старый ключ до того, как кеши получили новый, начнутся сбои у резолверов, которые всё ещё хранят старый набор DNSKEY или запись DS. При смене ключей нужно соблюдать все задействованные TTL.

Как включить DNSSEC для своего домена

1. Проверьте, что ваш TLD поддерживает DNSSEC; большинство общих и многие национальные домены верхнего уровня его поддерживают.
2. Включите подпись DNSSEC у вашего DNS-хостинга. Он сгенерирует ключи и подпишет зону.
3. Скопируйте данные записи DS (тег ключа, алгоритм, тип дайджеста и сам дайджест) в настройки DNSSEC у вашего регистратора. Если провайдер и регистратор — одна и та же компания, это часто происходит автоматически, а некоторые реестры подхватывают записи CDS сами.
4. Проверьте результат нашей проверкой DNSSEC и убедитесь, что обычные запросы по-прежнему работают, с помощью инструмента проверки DNS-записей.

Часто задаваемые вопросы

Шифрует ли DNSSEC мои DNS-запросы?

Нет. DNSSEC обеспечивает подлинность и целостность, но не конфиденциальность. Запросы и ответы по-прежнему видны в сети. Шифрование дают DNS over TLS и DNS over HTTPS, которые дополняют DNSSEC.

Нужен ли DNSSEC, если мой сайт работает по HTTPS?

Сертификаты HTTPS и так не дают поддельному DNS-ответу незаметно выдать себя за ваш сайт, но DNSSEC защищает ещё и маршрутизацию почты, TXT-записи для подтверждения владения и другие записи. Он же необходим для DANE, который публикует сведения о TLS-сертификатах в DNS.

Почему мой домен работает в одних сетях и не работает в других?

Если DNSSEC сломан, SERVFAIL возвращают только проверяющие резолверы; непроверяющие продолжают отвечать. Поэтому кажется, будто сбой зависит от сети.

Как безопасно отключить DNSSEC?

Сначала удалите запись DS у регистратора, дождитесь, пока она исчезнет из кешей, и только потом прекращайте подписывать зону. Если сделать наоборот, домен перестанет работать.