Что такое DNSSEC: как работает и как включить без простоя

У классического DNS нет способа доказать, что ответ подлинный. Резолвер отправляет вопрос по UDP и верит первому правдоподобному ответу. Любой, кто может подбросить или изменить этот ответ (через отравление кэша, взломанную сеть или подставной резолвер), способен отправить пользователей на другой сервер. DNSSEC, расширения безопасности DNS, закрывает эту брешь, добавляя к данным DNS цифровые подписи, чтобы резолвер мог убедиться, что ответ действительно исходит от владельца зоны и не был изменён по пути.

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

Что DNSSEC делает, а чего нет

Он обеспечивает:

Аутентификацию источника и целостность: записи опубликовал тот, кто владеет ключами зоны, и они не были изменены.
Подтверждённое отрицание существования: подписанное доказательство того, что имени или типа записи не существует, чтобы ответ «такого домена нет» тоже нельзя было подделать.

Он не обеспечивает:

Шифрование. Запросы и ответы остаются читаемыми для любого на пути. Приватность — задача DNS over TLS и DNS over HTTPS, которые защищают участок между клиентом и резолвером и дополняют DNSSEC, а не заменяют его.
Защиту от взлома учётной записи DNS. Если злоумышленник может редактировать вашу зону, провайдер послушно подпишет его записи.
Защиту веб-сессии. Это задача TLS. DNSSEC гарантирует, что вы попали на правильный адрес; сертификат доказывает, что сервер тот, за кого себя выдаёт.
Что-либо для пользователей, чей резолвер не проверяет подписи. Многие крупные публичные резолверы и провайдеры проверяют; не все.

Как это работает

DNSSEC добавляет несколько типов записей:

Запись	Где	Назначение
`RRSIG`	рядом с каждым набором записей	подпись этого набора (например, всех записей `A` для `www`)
`DNSKEY`	вершина зоны	открытые ключи зоны
`DS`	в родительской зоне	хеш ключа дочерней зоны; звено цепочки
`NSEC` / `NSEC3`	по всей зоне	доказывает, каких имён и типов не существует
`CDS` / `CDNSKEY`	вершина зоны	позволяет дочерней зоне автоматически сообщать родителю об изменении DS

Большинство зон используют два ключа. Ключ подписи зоны (ZSK) подписывает записи. Ключ подписи ключей (KSK) подписывает только набор DNSKEY, и именно хеш KSK публикуется у родителя как DS-запись. Такое разделение позволяет часто менять ZSK, не привлекая родителя. Некоторые провайдеры вместо этого используют один общий ключ (CSK); принцип тот же.

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

Проверяющий резолвер изначально доверяет ровно одной вещи: открытому ключу корневой зоны, подписанной с 2010 года. Всё остальное выводится из него:

root DNSKEY  (trust anchor, built into the resolver)
   └─ signs  DS for "com"          → matches com's DNSKEY
         └─ signs  DS for "example.com"   → matches example.com's DNSKEY
               └─ signs  www.example.com A 192.0.2.10

На каждом уровне родитель ручается за ключ дочерней зоны, публикуя и подписывая запись DS. Если каждое звено проверяется, ответ считается secure, и резолвер выставляет флаг ad (authenticated data). Если у зоны нет DS у родителя, она просто insecure: обрабатывается как обычный неподписанный DNS, никакого вреда. Но если DS существует, а подписи не сходятся (не тот ключ, истёкшая подпись, отсутствующий RRSIG), результат — bogus, и резолвер возвращает SERVFAIL. Для пользователей за проверяющими резолверами домен перестаёт существовать.

Этот последний случай и есть весь операционный риск DNSSEC, и он объясняет правила, о которых пойдёт речь дальше.

Ещё одна деталь, которую стоит знать: подписи истекают. У каждой RRSIG есть время начала и время окончания действия. Подписывающая сторона обязана регулярно переподписывать зону. Управляемые DNS-провайдеры делают это автоматически; самостоятельно размещённый подписант, который перестал работать, через неделю-другую приводит к простою.

Проверка DNSSEC с помощью dig

Есть ли DS-запись у родителя (то есть должен ли домен быть подписан)?

$ dig +short example.com DS
31589 13 2 3490A6806D47F17A34C29E2CE80E8A999FFBE4BE...

Поля: тег ключа, алгоритм (13 = ECDSA P-256 с SHA-256, обычный современный выбор), тип дайджеста (2 = SHA-256) и сам дайджест.

Публикует ли зона ключи и подписи?

$ dig +dnssec +multi example.com DNSKEY
$ dig +dnssec www.example.com A
www.example.com.  3600 IN A      192.0.2.10
www.example.com.  3600 IN RRSIG  A 13 3 3600 20261004000000 20260920000000 31589 example.com. oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr...

Проходит ли проверку? Спросите проверяющий резолвер и посмотрите на флаги:

$ dig www.example.com A @1.1.1.1 | grep flags
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, ...

ad означает, что резолвер проверил ответ. Чтобы отличить сбой DNSSEC от других сбоев, повторите неудачный запрос с отключённой проверкой:

$ dig www.example.com A @1.1.1.1          # status: SERVFAIL
$ dig www.example.com A @1.1.1.1 +cd      # status: NOERROR, ответ есть

SERVFAIL в обычном режиме, но ответ с +cd — верный признак сломанной настройки DNSSEC. delv www.example.com (поставляется вместе с BIND) выполняет проверку локально и объясняет, где рвётся цепочка.

Как включить DNSSEC

Его должны поддерживать три стороны: TLD (почти все поддерживают), DNS-провайдер (подписывает зону) и регистратор (передаёт DS в реестр).

Включите подписание у DNS-провайдера. Он создаст ключи и начнёт публиковать записи DNSKEY и RRSIG. На этом этапе ничего сломаться не может, потому что без DS зона по-прежнему «insecure».
Проверьте подписанную зону: dig +dnssec к серверам имён провайдера должен показывать RRSIG для ваших записей. Подождите хотя бы один TTL, чтобы в кэшах лежали подписанные данные.
Опубликуйте DS-запись.
- Если регистратор и DNS-провайдер — одна компания, обычно это один клик или происходит автоматически.
- Иначе скопируйте значения DS (тег ключа, алгоритм, тип дайджеста, дайджест) от DNS-провайдера в форму DNSSEC у регистратора. Некоторые регистраторы вместо этого просят DNSKEY и вычисляют DS сами. Копируйте внимательно: один неверный символ делает домен bogus.
- Некоторые реестры и регистраторы опрашивают записи CDS/CDNSKEY и создают или обновляют DS самостоятельно. Если ваши это умеют, предпочтите этот путь.
Проверьте цепочку командами выше и внешним валидатором, с нескольких резолверов.
Следите. Истечение подписей и несовпадение DS не дают о себе знать, пока не сломаются.

Опасные моменты

Смена DNS-провайдера или серверов имён. DS у родителя указывает на ключ старого провайдера. Переключите серверы имён, не позаботившись об этом, и домен станет bogus. Либо удалите DS, дождитесь истечения его TTL (часто это сутки), переезжайте, потом включайте заново; либо проводите согласованную миграцию с несколькими подписантами. Полная последовательность — в статье смена серверов имён без простоя.
Отключение DNSSEC. Порядок обратный включению: сначала удалите DS, переждите его TTL и только потом прекращайте подписание. Отключить подписание, пока DS ещё опубликован, — классический простой, устроенный собственными руками.
Перенос домена к другому регистратору, когда старый регистратор ещё и размещает DNS. См. как перенести домен к другому регистратору.
Смена ключей на самостоятельно размещённых подписантах. Смена KSK затрагивает родителя и должна идти по схеме «опубликовать — подождать — переключить — подождать — удалить». У управляемого провайдера это его работа.

Помните, что снижение собственных TTL при сломанной цепочке не помогает: TTL записи DS задаёт родительская зона.

Частые ошибки

Вставить DS с неверным номером алгоритма или типа дайджеста.
Оставить старый DS после переезда к другому DNS-провайдеру.
Отключить подписание раньше, чем удалён DS.
Самостоятельно размещённый подписант, у которого умерла задача cron; всё работает, пока не истекут подписи.
Выбрать NSEC, не понимая, что он позволяет перечислить имена зоны («обход зоны»). NSEC3 или техники минимальных ответов, которые применяют крупные провайдеры, затрудняют это.
Использовать устаревшие алгоритмы (RSA/SHA-1), тогда как ECDSA P-256 даёт более компактные ответы и повсеместно поддерживается современными валидаторами.
Считать, что раз сайт открывается у вас, с DNSSEC всё в порядке. Ваш резолвер может не проверять подписи.

Стоит ли оно того

Для большинства доменов у управляемого DNS-провайдера: да. Это бесплатно, это один-два клика, и это убирает класс атак, которые иначе для вас невидимы. Цена — операционная дисциплина в те немногие моменты, что перечислены выше. Если ваша команда меняет DNS-провайдеров походя и за учётную запись у регистратора никто не отвечает, сначала исправьте это.

Проверьте в OrbitProbe

Проверка DNS-записей в OrbitProbe показывает записи, которые публичные резолверы возвращают для вашего домена, вместе с их TTL. Подписанный домен, который вдруг перестаёт возвращать какие-либо записи с проверяющих резолверов, тогда как панель провайдера выглядит нормально, — это тот самый рисунок, который нужно узнавать: сразу переходите к тесту с +cd выше. Как реестр видит делегирование, в том числе помечено ли оно как подписанное, видно в регистрационных данных, о которых рассказано в статье WHOIS и RDAP.