Внедрение DNSSEC сдерживается владением ключами, а не криптографической сложностью.
DNSSEC — стандарт уже более десяти лет, и при этом внедрение остаётся неравномерным. Криптография хорошо понята; операционная модель хорошо задокументирована. То, что останавливает многие организации от его включения, — это владение: ключ подписи (KSK) и ключ подписи зоны (ZSK) являются корнями доверия всей зоны, и большинство предприятий не хотят, чтобы эти ключи были в руках вендора.
Облачные DNS-провайдеры предлагают sign-and-serve DNSSEC, но ключи живут в KMS провайдера. Провайдер может отозвать, ротировать или быть вызван по повестке — целостность вашей зоны зависит от продолжающейся работы провайдера. Некоторые организации принимают этот компромисс; многие в регулируемых секторах (правительство, оборона, финансы) — не могут.
Историческая альтернатива — эксплуатация собственного конвейера подписи DNSSEC: BIND с пользовательским управлением ключами, скрипты для ротации ключей по расписанию, интеграция с внешним HSM, конфигурация slave для приёма подписанных записей. Это работает, но операционная нагрузка значительна, а режимы отказа молчаливы (истёкший RRSIG, отсутствующая цепочка NSEC).
TR7 GTM приводит DNSSEC на ту же операторскую поверхность, что и остальная плоскость авторитативного DNS — opt-in на домен, подписанные записи как первоклассные данные, трансфер зоны, переносящий подпись, — без зависимости от внешней службы подписи.
Наш подход
DNSSEC — это флаг возможности на домен, объединённый с первоклассной поддержкой всех типов записей DNSSEC. Sign-and-serve происходит на узле TR7 GTM; владение ключами остаётся у оператора.
Opt-in DNSSEC на домен
Каждый DNS-домен в TR7 GTM независимо включает или отключает DNSSEC через булево поле схемы. Смешанные развёртывания — некоторые подписанные зоны, некоторые неподписанные — сосуществуют на одном парке без принуждения к коммитменту на уровне парка.
Восемь типов записей DNSSEC как первоклассные данные
DNSKEY, DS, NSEC, NSEC3, NSEC3PARAM, RRSIG, CDS, CDNSKEY являются частью списка поддерживаемых типов записей наряду с A, AAAA, CNAME, MX и остальными. Схема рассматривает их как данные, а не как отдельную подсистему.
Режимы редактирования SOA контролируют продвижение серийника
Оператор выбирает, как инкрементируется серийник SOA: DEFAULT (формат YYYYMMDD01), INCREASE (+1 на изменение), EPOCH (UNIX timestamp) или OFF (ручной контроль). Продвижение серийника важно для валидаторов DNSSEC и для downstream-slave.
Трансфер зоны переносит подписанные записи нетронутыми
AXFR/IXFR передаёт записи DNSSEC наряду с другими типами записей. Slave в режиме Express обслуживают подписанные ответы мастера без пере-подписания — единая точка подписи, множественные точки обслуживания.
Возможности
DNSSEC в TR7 GTM покрывает операционную поверхность — схему, трансфер, обслуживание, целостность — без делегирования стороннему подписанту.
Не только подписывание, но и проверка
Подписывание доказывает ваши зоны миру. Проверка защищает ваших собственных пользователей: ответы, приходящие через рекурсивный резолвер, сверяются с цепочкой доверия, поэтому подделанный или изменённый ответ ломается до попадания в кэш — а резкий рост вердиктов bogus поднимает тревогу, ведь это либо атака, либо сломанная зона, и знать нужно немедленно.
Булев флаг DNSSEC на домен
Каждый DNS-домен несёт булево поле `dnssec`. Когда true, зона рассматривается как DNSSEC-активная: записи DNSKEY и DS ожидаются, записи RRSIG сопровождают каждый RRset в проводе, а записи NSEC/NSEC3 покрывают пространство имён зоны.
Управление записями DNSKEY
Записи DNSKEY (публичные ключи зоны) управляются как обычные записи в схеме. Операторы импортируют или определяют содержимое DNSKEY; ротация обрабатывается добавлением новых записей DNSKEY перед удалением старых, следуя стандартным паттернам pre-publish rollover.
Поддержка записей DS для делегирования родительской зоны
Записи DS (Delegation Signer) управляются в родительской зоне. Когда родительская и дочерняя зоны обе размещены в TR7 GTM, записи DS распространяются естественно; когда родитель в другом месте, операторы экспортируют записи DS для отправки upstream.
Аутентифицированное отрицание существования NSEC и NSEC3
Записи NSEC и NSEC3 доказывают, что запрошенное имя не существует. NSEC3 добавляет соль и итерации, чтобы победить перечисление зоны. Оба типа записей первоклассны в схеме и обслуживаются как часть зоны.
Записи подписи RRSIG
Записи RRSIG несут криптографические подписи над RRset. Схема поддерживает RRSIG как тип записи; трансфер AXFR/IXFR переносит RRSIG наряду с подписанными RRset.
CDS и CDNSKEY для автоматизированных обновлений родителя
Записи CDS и CDNSKEY сообщают предполагаемое состояние DS дочерней зоны родителю — обеспечивая автоматизацию на стороне родителя (RFC 7344). Полезно для организаций, эксплуатирующих делегирования между несколькими DNS-провайдерами.
Режимы редактирования SOA для контроля серийника
Четыре выбираемых оператором режима для продвижения серийника SOA: DEFAULT (на основе даты YYYYMMDD01), INCREASE (+1 на изменение), EPOCH (UNIX timestamp), OFF (ручной контроль). Значения серийника критичны для DNSSEC, поскольку подписанные зоны должны продвигать серийник при каждом изменении, чтобы инвалидировать закешированные подписи.
IP slave-серверов для репликации подписанной зоны
Каждый домен может перечислять IP slave-серверов, которым он пушит обновления подписанной зоны через NOTIFY. Операторы запускают собственные downstream-slave (PowerDNS, BIND, NSD) и получают подписанные копии для распределённого обслуживания.
Совместимость с режимом Express для подписи через скрытого мастера
Домены в режиме Express, вытянутые с upstream-мастера, наследуют состояние DNSSEC мастера. Если мастер подписывает, TR7 обслуживает подписанные ответы; если мастер не подписывает, TR7 обслуживает неподписанные. Решение о подписи принадлежит мастеру.
35 всего типов DNS-записей, включая 8 DNSSEC-типов
Полный список типов записей (A, AAAA, AFSDB, ALIAS, CAA, CERT, CDNSKEY, CDS, CNAME, DNSKEY, DNAME, DS, HINFO, KEY, LOC, MX, NAPTR, NS, NSEC, NSEC3, NSEC3PARAM, OPENPGPKEY, PTR, RP, RRSIG, SOA, SPF, SSHFP, SRV, TKEY, TSIG, TLSA, SMIMEA, TXT, URI) включает восемь типов, связанных с DNSSEC, как первоклассных членов.
Операционная глубина
DNSSEC в TR7 GTM эксплуатируется вместе с трансфером зоны, ротацией ключей, делегированием родителя и ожиданиями валидатора.
Грануляция opt-in на домен
DNSSEC включается на домен. Операторы развёртывают DNSSEC зону за зоной, валидируя каждую перед расширением. Смешанные состояния поддерживаются бессрочно — некоторые зоны подписанные, некоторые неподписанные, на одном парке TR7.
Ротация ключей через управление записями
Ротация DNSKEY следует стандартным паттернам pre-publish / double-signature: добавить новый ключ как DNSKEY-запись, дождаться обновления кешей, переключить активного подписанта, вывести старый ключ. Схема рассматривает каждый ключ как данные; расписание ротации контролируется оператором.
Окна действия RRSIG
Записи RRSIG несут интервалы действия. Операторы определяют каденцию обновления — обычно подписи обновляются до истечения, чтобы избежать сбоев валидатора при переходящих проблемах с конвейером подписи. Платформа выводит на поверхность предстоящие истечения для действий оператора.
Выбор NSEC vs NSEC3
NSEC позволяет zone walking (атакующий может перечислить все имена); NSEC3 добавляет соль и итерации, чтобы предотвратить walking. Операторы выбирают на зону — публичные зоны часто используют NSEC3 для предотвращения перечисления; закрытые зоны могут использовать NSEC ради простоты.
Координация делегирования родителя
Делегирование zone-cut требует, чтобы родитель опубликовал DS-запись. Когда родительская зона размещена в TR7, записи DS являются частью набора записей родителя. Когда родитель в другом месте, операторы экспортируют значения DS из записей CDS и отправляют их upstream.
Совместимость со slave-серверами
Downstream slave-серверы получают подписанные зоны через трансфер AXFR/IXFR и обслуживают их. Slave не пере-подписывают; они доверяют подписям мастера. Это поддерживает распределённое обслуживание (несколько slave POP, региональные кеши) без накладных расходов на пере-подписание.
Когда использовать
Целостность DNS в правительстве и обороне
Зоны общественного сектора, требующие целостности DNSSEC для соответствия, часто должны держать ключи подписи внутри периметра безопасности. On-prem DNSSEC TR7 поддерживает это требование без делегирования облачному провайдеру.
Подписанные зоны финансового сектора
Зоны банковского и платёжного процессинга используют DNSSEC для предотвращения DNS-спуфинг атак на клиентские сервисы. Opt-in на домен позволяет банкам развёртывать DNSSEC зону за зоной, валидируя каждую перед более широким развёртыванием.
Архитектуры со скрытым мастером и подписанным обслуживанием
Мастер подписывает зону; узлы TR7 действуют как Express-slave и обслуживают подписанные ответы мастера. Подпись происходит один раз; обслуживание происходит в масштабе без накладных расходов пере-подписания на эдже.
DNS у нескольких провайдеров с координацией родителя через CDS
Организации, использующие нескольких DNS-провайдеров для резервирования, публикуют записи CDS через TR7, чтобы родительская зона могла автоматически узнавать текущие значения DS. Автоматизация на стороне родителя снижает ручную координацию ротации.
Часто задаваемые вопросы
Управляет ли TR7 ключами DNSSEC или мне нужно принести свои?
Могу ли я использовать DNSSEC на зонах в режиме Express?
Как режим редактирования SOA влияет на DNSSEC?
Что с zone walking через NSEC?
Как обрабатываются slave-серверы с DNSSEC?
Совместим ли DNSSEC с возможностями GSLB и выбора ЦОД?
Подписывайте свои зоны на собственной инфраструктуре.
Пройдитесь по on-prem DNSSEC с TR7 GTM: opt-in на домен, все типы записей DNSSEC как первоклассные данные, трансфер зоны, переносящий подписи нетронутыми.