Какую проблему решает DNSSEC
Обычный DNS создавался без защиты подлинности. Резолвер получает ответ и не может проверить, что его отправил настоящий сервер и что по дороге он не был изменён. Отсюда возможность подделки: злоумышленник в сети или взломанный сервер способен вернуть чужой адрес, и пользователь попадёт не на тот узел. Расширение DNSSEC добавляет к записям криптографическую подпись, благодаря чему резолвер, поддерживающий проверку, распознаёт подделку и отвергает ответ.
Для читателей важно сразу уточнить границу: DNSSEC подтверждает подлинность данных, но не скрывает их. Запросы остаются видимыми. Для конфиденциальности запросов служат другие технологии, например dns-over-tls.
Ключи и подписи
Владелец зоны создаёт пару ключей. Закрытой частью он подписывает наборы записей, а открытую публикует в самой зоне в записи DNSKEY. Подпись хранится в записях RRSIG рядом с обычными. Резолвер, получив ответ, берёт открытый ключ и проверяет подпись; принципы описаны на страницах asimmetrichnoe-shifrovanie и elektronnaya-podpis. Если подпись не сходится, резолвер возвращает клиенту ошибку, а не подозрительный ответ.
Практически зону делят на два вида ключей. Один подписывает сами записи и меняется чаще. Другой, ключ подписи ключей, подписывает набор DNSKEY и меняется реже.
Обратите внимание, что подписанная зона не скрывает существование имён. Механизм отрицательных подтверждений позволяет доказывать, что имени нет, и при некоторых схемах это допускает перечисление содержимого зоны. Поэтому подпись не считают средством скрытия структуры домена.
Цепочка доверия от корня
Откуда резолвер знает, что открытый ключ домена настоящий? Родительская зона хранит запись DS: хеш ключа дочерней зоны. Зона com подписывает DS для example.com, корень подписывает DS для com. На самой вершине резолвер держит заранее известный якорь доверия, ключ корневой зоны. Получается непрерывная цепочка, каждая ступень которой подтверждена вышестоящей; сравните с идеей на странице tsepochka-doveriya. Хеш-функции, лежащие в основе, разобраны на странице hesh-funktsiya.
Если у домена нет записи DS в родительской зоне, цепочка разорвана, и домен считается неподписанным.
Что DNSSEC не делает
Он не шифрует трафик и не скрывает, какие имена вы запрашиваете. Он не защищает соединение с сайтом: для этого нужен TLS с проверкой сертификата. Он не проверяет устройство пользователя: проверку обычно выполняет резолвер, а участок между вашим устройством и резолвером остаётся уязвимым, если резолверу не доверять. Кроме того, подписанные ответы больше по размеру, а ошибки при смене ключей могут сделать домен недоступным для проверяющих резолверов.
Поэтому DNSSEC — один из слоёв защиты, а не замена остальных.
Как проверить: DNSSEC
Команда dig example.com A +dnssec добавит к ответу записи RRSIG. У ответа, прошедшего проверку в валидирующем резолвере, в поле flags появляется признак ad (authenticated data). Отсутствие подписи не всегда проблема: подписаны далеко не все домены. Ошибка проверки проявляется как код SERVFAIL при том, что запрос к тому же имени через невалидирующий резолвер проходит.
Запрос dig example.com DNSKEY покажет опубликованные ключи, а dig example.com DS в родительской зоне подскажет, есть ли ссылка на них. Если запись DS отсутствует, домен формально не защищён, даже когда подписи в зоне уже есть. Онлайн-анализаторы подписи строят всю цепочку и показывают, на каком звене она рвётся, что полезно при сбоях после смены ключей.
Порядок включения и типичные сбои
Включение DNSSEC делают в несколько шагов. Провайдер DNS генерирует ключи и подписывает зону. Затем владелец передаёт регистратору данные для записи DS, чтобы родительская зона подтвердила ключи. Порядок важен: если запись DS опубликована раньше, чем зона подписана правильно, проверяющие резолверы начнут возвращать ошибки, и домен перестанет открываться для значительной части пользователей.
Типичные сбои связаны со сменой ключей и с переносом домена между провайдерами. Если новый провайдер не знает ключей прежнего, а старая запись DS осталась, цепочка доверия ломается. Поэтому перед сменой DNS-хостинга отключают подпись, удаляют DS, ждут истечения TTL и только потом переносят зону. Мониторинг состояния подписи входит в хорошую практику обслуживания домена.