hostprofi.ru
Подобрать хостинг
Термин·буква D

DNSSEC

краткое определение

DNSSEC (DNS Security Extensions) — расширение протокола DNS для криптографической подписи DNS-записей. Защищает от атак типа DNS spoofing и cache poisoning: резолвер проверяет цифровые подписи и отвергает подделанные ответы.

DNSSEC (Domain Name System Security Extensions) — набор расширений протокола DNS, обеспечивающих аутентификацию происхождения DNS-данных и целостность ответов. Стандартизован в RFC 4033-4035 (2005). Без DNSSEC злоумышленник, получив доступ к трафику или к кэширующему резолверу, может подменить DNS-ответ и перенаправить пользователей на фиктивный сервер.

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

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

  • RRSIG (Resource Record Signature) — криптографическая подпись набора записей.
  • DNSKEY — публичный ключ зоны (два типа: KSK — Zone Signing Key и ZSK — Key Signing Key).
  • DS (Delegation Signer) — хэш KSK дочерней зоны, размещённый в родительской зоне для построения цепочки доверия.
  • NSEC/NSEC3 — записи для аутентифицированного подтверждения отсутствия записи (authenticated denial of existence).

Цепочка доверия строится сверху вниз: root zone → TLD (.ru, .com) → домен. ICANN подписала root zone в 2010 году. Зона .RU подключила DNSSEC в 2011 году, .com — в 2011 году. Если хотя бы одно звено цепочки не подписано — проверка DNSSEC невозможна для домена.

При запросе DNSSEC-резолвер: запрашивает RRSIG вместе с ответом, загружает DNSKEY зоны, проверяет подпись RRSIG ключом DNSKEY, проверяет DS-запись у родителя. Если подпись не совпадает — возвращает SERVFAIL клиенту.

История

Атака Каминского (2008) — наглядная демонстрация уязвимости DNS без DNSSEC: Дэн Каминский показал, как за несколько секунд можно отравить DNS-кэш крупного резолвера. Это ускорило внедрение DNSSEC. ICANN подписала root zone 15 июля 2010 года. К 2024 году около 20-25% запросов в глобальном DNS используют DNSSEC-валидацию (данные APNIC).

DNSSEC в хостинге

Для включения DNSSEC владелец домена настраивает подпись зоны в панели управления DNS-провайдера (или хостинга с DNS), затем регистрирует DS-запись у регистратора домена. Это несколько кликов в современных панелях (Cloudflare DNS, Amazon Route 53, ISPmanager). Отдельный серьёзный сценарий — A-записи, MX-записи и SPF могут подделываться без DNSSEC, приводя к перехвату email и трафика.

На что обращать внимание

DNSSEC не шифрует DNS-трафик — DNS-ответы остаются в открытом виде, только подписаны. Для шифрования нужны DoT (DNS over TLS) или DoH (DNS over HTTPS). Ошибки в управлении ключами DNSSEC приводят к полной недоступности домена — SERVFAIL для всех запросов. При смене DNS-провайдера нужно синхронизировать DS-записи у регистратора, иначе цепочка доверия рвётся. Автоматическая ротация ключей (key rollover) поддерживается у большинства современных DNS-провайдеров.

История DNSSEC

DNSSEC разработан как ответ на Kaminsky Attack (2008): Дэн Каминский обнаружил уязвимость DNS cache poisoning, позволявшую перенаправлять трафик с любого домена. Базовые стандарты: RFC 4033–4035 (2005). Корневая зона DNS подписана DNSSEC в 2010 году. К 2023 году около 90% корневых серверов поддерживают DNSSEC, но только ~30% доменов .COM подписаны. Россия: .RU подписан DNSSEC в 2011 году.

Типичные ошибки

Главная ошибка — включить DNSSEC, но не настроить автоматическую ротацию ключей. Ключи DNSSEC истекают (обычно раз в год для KSK), и если DS-запись у регистратора не обновлена, домен перестаёт резолвиться для DNSSEC-валидирующих резолверов. Вторая ошибка — смена NS-серверов без синхронизации DS-записей: новые NS имеют другие DNSKEY, цепочка доверия обрывается. Третья — использование слабых алгоритмов: минимальный рекомендуемый — RSA/SHA-256 (алгоритм 8) или ECDSA P-256 (алгоритм 13, предпочтителен с 2020 года).

Другие термины