Глобальный инструмент валидации DNSKEY
Ресурсная запись DNSKEY — это криптографическая основа DNSSEC (Domain Name System Security Extensions). Базовый протокол DNS по своей природе не зашифрован и не имеет состояния (stateless), что делает его крайне уязвимым к отравлению кэша (cache poisoning) и подмене (spoofing) Man-in-the-Middle (MitM). DNSSEC решает эту проблему путем прикрепления математических криптографических подписей к ответам DNS. Запись DNSKEY выступает в роли хранилища открытых ключей; она хранит открытые ключи в кодировке Base64, которые удаленные резолверы используют для проверки того, что Payload A или MX записей действительно был сгенерирован авторитетным сервером имен и не был изменен при передаче.
Архитектура ZSK и KSK
Стандартная реализация DNSSEC использует два различных ключа для баланса безопасности и операционной эффективности. Zone Signing Key (ZSK) — это криптографический ключ меньшего размера с низкими накладными расходами, используемый для быстрой подписи отдельных записей (A, TXT, CNAME) внутри зоны. Поскольку он обрабатывает массовое подписание, ZSK часто ротируется (например, каждые 30 дней) для предотвращения взлома методом полного перебора (brute-force). Key Signing Key (KSK) — это гораздо более сильный, тщательно охраняемый ключ. Его единственная цель — подписать сам ZSK. Разделяя эти ключи, администраторы могут локально ротировать ZSK на сервере имен без необходимости постоянного взаимодействия с родительским реестром TLD.
Цепочка доверия (Chain of Trust) и DS-записи
Публикация записи DNSKEY в вашей зоне бесполезна, если нет проверяемого пути доверия, простирающегося до корня Интернета. Как только KSK генерирует подпись, математический хэш этого KSK отправляется регистратору домена в качестве записи DS (Delegation Signer). Регистратор публикует эту запись DS в родительской зоне TLD (как реестр .com). Когда рекурсивный резолвер опрашивает ваш домен, он извлекает DS-запись из родителя для аутентификации KSK, использует KSK для аутентификации ZSK и использует ZSK для аутентификации конечного IP-адреса. Если любое звено в этой криптографической цепочке будет разорвано, валидация полностью завершится неудачей.
Катастрофические сбои SERVFAIL
Управление записями DNSKEY требует абсолютной точности. DNSSEC спроектирован так, чтобы "fail closed" (отказывать с блокировкой). Если автоматизированный скрипт ротирует ZSK на сервере, но соответствующая публичная запись DNSKEY не будет обновлена в глобальной зоне, криптографические подписи не совпадут. Провайдеры (ISP) и публичные резолверы, такие как Google (8.8.8.8) и Cloudflare (1.1.1.1), интерпретируют это как активную кибератаку. Они мгновенно отбросят DNS-ответ и вернут клиенту фатальный статус SERVFAIL, фактически стерев домен из Интернета до тех пор, пока ключи не будут синхронизированы вручную или DNSSEC не будет полностью отключен на уровне регистратора.