Настройка DNSSEC под ключ: защита DNS от подмены

DNSSEC настройка: где ломается цепочка доверия

DNSSEC отвечает на один узкий вопрос: ответ пришёл из самой зоны или от посредника. Без него кэширующий резолвер проглатывает подменённый ответ, клиент попадает на чужой адрес, и внешне это ничем не отличается от штатной работы сервиса — до момента, когда на этом адресе начнут собирать доступы.

Проверка подлинности ответов DNS опирается на цепочку доверия зоны. Родитель хранит DS-запись с отпечатком ключа подписи дочерней зоны, резолвер сверяет по ней полученную подпись и тянет уверенность вниз по иерархии до самого домена. Разрыв на любом звене — и ответ считается неподтверждённым, даже если все данные на месте.

Самый частый обрыв — расхождение ключей подписи у регистратора и в зоне. Ключи меняют, а DS-запись публикуют с задержкой или с прежним отпечатком, и ждать обновления приходится ровно столько, сколько живёт запись в кэше родителя. Отдельная причина — просроченная подпись: зона подписывается заранее с запасом, и если переподписание остановилось, валидация обрывается без единой правки в конфигурации.

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

Дальше разбираем, как это закрывается: от порядка публикации DS при смене ключей до проверок, которые ловят обрыв цепочки раньше, чем его увидит пользователь.

Что даёт подписанная зона: эффект в измеримых величинах

Подписанная зона переносит проверку подлинности ответа в момент валидации: резолвер сверяет подпись записи с цепочкой доверия и вместо подделанных данных возвращает отказ. Доля ложных ответов, дошедших до пользователя, падает до нуля — подмена на пути между кэшем и корневой зоной больше не даёт результата. Корневую зону подписывает ICANN, поэтому цепочка доверия не обрывается ни на одном уровне домена.

Время расследования инцидентов сокращается кратно, потому что факт подмены перестаёт быть предметом догадок. Раньше приходилось сравнивать ответы из разных точек и от разных провайдеров, чтобы доказать сам факт; теперь достаточно увидеть расхождение подписи — и сразу понятно, где причина: истёкшая подпись, рассинхрон ключей у регистратора или устаревшая копия зоны. Разбор укладывается в минуты, а не в часы переписки с несколькими сторонами.

Отдельно уходит класс отказов вида «сайт то открывается, то нет»: отравленная запись в промежуточном кэше не может быть отдана как валидная. Остаются явные отказы валидации — они видны в логах и разбираются по коду, вместо тихой переадресации на чужой адрес или подменённой почтовой записи. Стабильность разрешения имён из разряда жалоб переходит в метрику: доля успешных валидаций держится ровно и не проседает в часы пик.

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

Варианты подключения защиты: сравнение режимов

Схемы включения DNSSEC различаются тем, где живут ключи и кто публикует DS-запись в родительской зоне. От этого зависит и трудоёмкость работ, и то, какие сбои остаются вне нашего контроля.

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

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

Порядок внедрения: от аудита зоны до передачи

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

Этапы

1. Аудит DNS-зоны. Инвентаризируем все записи и делегированные подзоны, сверяем копии зоны на разных серверах, находим конфликты, из-за которых подпись станет невалидной.
2. Схема делегирования и цепочка доверия. Определяем, кто передаёт зону родителю, где публикуются ключи и как подтверждается их связь — без этого подпись не примут внешние резолверы.
3. Включение подписи зоны. Генерируем ключи подписи, задаём сроки их ротации и время жизни подписей в кэше, синхронизируем зону между всеми серверами.
4. Тестовый режим. Зона уже отдаётся с подписями, но ключ родителю не передан: видно, что ответы формируются корректно, при этом клиенты не затронуты.
5. Публикация у родителя. После подтверждения теста публикуем ключ — с этого момента зона считается подписанной, а откат возможен только согласованным действием.
6. Проверка с разных резолверов. Опрашиваем публичные, локальные и распределённые резолверы: ответы подтверждаются, отказов нет, поведение одинаково у всех.
7. Передача регламента. Отдаём документ с порядком ротации ключей, действиями при сбое подписи и точками мониторинга, обучаем команду на реальных сценариях.

Политики, ключи и документация: что остаётся у вас

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

• Карта зон и поддоменов — перечень зон, их точек делегирования и соответствия записям у регистратора: видно, где заканчивается ваша ответственность и начинается зона провайдера.
• Схема цепочки доверия — от корневой зоны до подписанных записей, с указанием, где хранятся родительские и дочерние ключи и как они связаны.
• Политика смены ключей — сроки жизни ключей подписи и ключей подписи ключей, порядок публикации новой записи у регистратора, кто инициирует плановую смену и что делать при компрометации.
• Разграничение ролей доступа к зоне — кто меняет ключи, кто только записи, кто имеет доступ на чтение; отдельная учётная запись для аварийных работ.
• Регламент проверок — что и как часто сверяем: валидность подписи, сроки жизни ключей, совпадение данных у регистратора и в самой зоне.
• Документация инфраструктуры DNS — адреса серверов, схема резервирования, места хранения ключей и порядок восстановления из резервной копии.
• Инструкция на случай инцидента — пошаговое снятие подписи с зоны при аварии и возврат к рабочему состоянию без простоя домена.

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

Кейс: перевод зоны на подпись без потери трафика

Исходное состояние

В работу пришла живая зона: основной домен, несколько десятков поддоменов под почту, API и внутренние сервисы, срок жизни записей — от пары минут до суток. Зона не была подписана, поэтому любой промежуточный резолвер мог подменить ответ, и со стороны владельца это никак не обнаруживалось.

Отдельный риск — первый для домена DS в родительской зоне: ошибка в цепочке доверия выключает весь домен, а не одну запись. Поэтому до публикации сняли базовые замеры: время ответа авторитетных серверов, распределение запросов по типам и долю трафика от валидирующих резолверов.

Замеры и проверки на резолверах

Подписанную версию зоны собрали на отдельном стенде и прогнали через внешние проверки цепочки, включая Google Public DNS. DS у регистратора опубликовали только после чистого прохождения — шаг необратим на время, равное сроку жизни делегирования.

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

Контрольный обход резолверов и проверку цепочки повторяем по расписанию: доверие ломается тихо, и без регулярной проверки об этом узнают от клиентов.

Настройка DNSSEC при смене регистратора: что учесть

Да, смена регистратора при включённом DNSSEC проходит без простоя — при условии, что порядок действий соблюдён жёстко. DS-запись живёт в родительской зоне и указывает на конкретный ключ подписи, поэтому пока она ссылается на старый ключ, а серверы отдают новый, валидирующие резолверы возвращают SERVFAIL — для клиентов это выглядит как полный отказ домена.

Порядок такой: заранее снизить TTL и выждать старый интервал, перенести зону вместе с приватной частью ключей KSK/ZSK (или осознанно сгенерировать новые), поднять новую площадку и убедиться, что она отдаёт DNSKEY и RRSIG, затем сменить DS через нового регистратора и только после обновления родительской зоны гасить старую. Реестровый интерфейс, через который публикуется DS, определяет ICANN, но сроки применения изменений у каждого реестра свои — их уточняют до начала работ.

Типовые ошибки перехода — снять DS раньше публикации нового ключа, перенести только публичную часть, не тронуть TTL и срок жизни подписи, забыть убрать старые NS из делегирования: часть резолверов продолжит ходить на площадку без подписи.

Технические сомнения: разбор частых ситуаций

Сомнения обычно всплывают не в момент подписи зоны, а через неделю эксплуатации: часть запросов перестаёт проходить проверку, кто-то из соседей делегирует поддомен, почта начинает вести себя странно. Ниже — разбор ситуаций, с которыми наши инженеры сталкиваются чаще всего при настройке DNSSEC.

Поддомен делегирован другой команде — что будет с проверкой?

При делегировании подпись дочерней зоны живёт отдельно: своя пара ключей и свой DS на стороне родителя. Если дочернюю зону никто не подписал, проверка для её имён просто не выполняется — остальная зона продолжает работать штатно, отказа не будет. Поэтому мы на старте собираем карту делегирований и по каждому поддомену решаем: подписываем сами, договариваемся с владельцем или оставляем как есть. Это фиксируется в документации, чтобы смена ответственного через полгода не превратилась в аварию.

Совместимость с почтой и сторонними сервисами

Почтовые записи подписываются вместе с зоной, и на работу MX это не влияет — ломается обычно не почта, а резолверы, которые не умеют разбирать разросшиеся ответы. Порядок действий: включаем NSEC3 с минимальным числом хеш-итераций, следим за размером ответов при переборе имён, проверяем отдачу по TCP, отдельно тестируем внешние сервисы, которые тянут зону целиком. Если сервис-подрядчик не поддерживает проверку подписей, проблему решает подписанная промежуточная зона, а не отказ от DNSSEC.

Как проверить цепочку доверия до включения в бой?

Мы прогоняем контрольный сценарий на тестовой копии зоны: корень — родительская зона — наша зона, сверяя на каждом шаге дайджест DS с ключом и срок действия подписей. Затем снимаем выборку с внешних резолверов и внутренних серверов организации — они часто настроены по-разному. Дополнительно ставим мониторинг на срок годности подписей и на долю ответов без подтверждения проверки, чтобы истечение ключа не стало неожиданностью.

Обсудим вашу зону и вернёмся с оценкой и планом

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

• Полный перечень зон и поддоменов, включая те, что делегированы на другие серверы или обслуживаются у подрядчиков: пропущенная зона останется без подписи, и её трафик продолжит ходить незащищённым.
• Схема делегирования: кто держит родительскую зону, где публикуются записи о ключах, есть ли промежуточные звенья и зоны-заглушки на стороне регистратора.
• Доступы, которые понадобятся в работе: панель регистратора для публикации записей о ключах, серверы с DNS-сервисом, репозиторий конфигураций, система мониторинга.
• Текущее состояние: включён ли DNSSEC на части зон, как хранятся ключи, с какой периодичностью меняются, кто отвечает за продление.
• Перечень внешних сервисов и резолверов, которые завязаны на ваши домены, — часть из них может не поддерживать проверку подписи, и это выясняется до включения, а не после.

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

Опишите вашу задачу и приложите то, что уже есть под рукой, — вернёмся с оценкой и планом работ.