# TLSA и DANE: привязка сертификата к DNS-зоне

> TLSA-запись и технология DANE привязывают TLS-сертификат к DNS-зоне поверх DNSSEC: синтаксис записи, генерация хэша и проверка через dig.

## Что такое DANE и какую проблему решает TLSA

Обычный TLS полагается на удостоверяющие центры: браузер доверяет сертификату, если его подписал признанный CA. Если скомпрометирован хоть один CA из сотен встроенных в систему, злоумышленник может выпустить сертификат на чужой домен. DANE (DNS-Based Authentication of Named Entities, RFC 6698) решает эту проблему иначе: владелец домена сам публикует в DNS-зоне, какой сертификат или ключ считается легитимным для его сервиса, а зона защищена DNSSEC-подписью.

Запись, которая хранит эту привязку, называется TLSA. Она отвечает на вопрос «каким сертификатам можно доверять на этом порту этого хоста», независимо от того, что скажет цепочка CA.

## Синтаксис TLSA-записи: usage, selector, matching type

Имя записи строится как `_порт._протокол.хост`, а значение — из трёх чисел и хэша:

```
_443._tcp.example.com. IN TLSA 3 1 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971
```

Первое число (usage) задаёт модель доверия: 0 — ограничение на CA (PKIX-TA), 1 — ограничение на конечный сертификат при сохранении проверки через публичный CA (PKIX-EE), 2 — собственный корневой CA вместо публичного (DANE-TA), 3 — прямая привязка к конкретному сертификату без участия CA вообще (DANE-EE), самый частый вариант для Let's Encrypt. Selector определяет, что именно хэшируется: 0 — весь сертификат, 1 — только открытый ключ (SubjectPublicKeyInfo), что удобно при обновлении сертификата с тем же ключом. Matching type: 0 — сертификат целиком, 1 — SHA-256, 2 — SHA-512.

## Как сгенерировать TLSA-запись для своего сертификата

Хэш открытого ключа по SHA-256 получают через openssl:

```
openssl x509 -in cert.pem -noout -pubkey \n  | openssl pkey -pubin -outform DER \n  | openssl dgst -sha256 -binary | xxd -p -c 256
```

Полученную строку подставляют четвёртым полем в запись TLSA с usage 3 и selector 1. При выпуске сертификата через ACME-DNS-challenge, описанный в статье [про DNS-challenge для SSL](https://www.zevshost.net/ru/kb/acme-dns-challenge-ssl/), хэш стоит пересчитывать при каждой смене ключа, а не только сертификата.

## DANE для почты: применение в SMTP

Веб-браузеры DANE для HTTPS практически не поддерживают: Chrome убрал такую проверку ещё в 2015 году, Firefox её так и не включил по умолчанию. Зато DANE активно используется для защиты почтового трафика: Postfix с параметром `smtp_tls_security_level = dane` проверяет TLSA-запись на MX-хосте получателя перед отправкой письма и отказывается слать её открытым текстом, если запись есть, а сертификат ей не соответствует. Настройка обычной защиты почты на уровне SPF, DKIM и DMARC описана в статье [про защиту email](https://www.zevshost.net/ru/kb/spf-dkim-dmarc-setup/), а DANE дополняет её на транспортном уровне, а не на уровне содержимого письма.

## Как проверить TLSA-запись

Запись проверяется через dig, а соответствие сертификату — через сверку хэша вручную:

```
dig TLSA _443._tcp.example.com +short
```

Если утилита dnsviz или онлайн-чекер сообщает, что DNSSEC для зоны не проходит проверку, TLSA-запись бесполезна: резолвер обязан доверять именно подписи DNSSEC, иначе злоумышленник может подменить саму TLSA-запись так же легко, как и сертификат. Способы диагностики зоны собраны в статье [про dig, dnsviz и типовые ошибки](https://www.zevshost.net/ru/kb/proverka-dns-zony-dig/).

## Ограничения DANE: обязательный DNSSEC и поддержка софта

- DANE работает только поверх подписанной DNSSEC-зоны — без неё запись TLSA не даёт защиты, см. статью [про настройку DNSSEC](https://www.zevshost.net/ru/kb/dnssec-nastroika/).
- Браузеры не проверяют TLSA для HTTPS-соединений, поэтому для веб-сайтов DANE носит вспомогательный характер.
- Почтовые серверы, не поддерживающие DANE, просто игнорируют запись и продолжают полагаться на CA.
- При ротации сертификата важно заранее опубликовать TLSA для нового ключа, иначе строгие DANE-клиенты откажутся соединяться в момент смены.

## Итог: чек-лист внедрения TLSA

Перед включением DANE убедитесь: зона подписана DNSSEC и проходит валидацию, TLSA-запись создана с usage 3 и selector 1 для собственных сертификатов, хэш пересчитан под текущий ключ, а почтовый сервер настроен на строгую проверку DANE только после того, как запись опубликована и проверена внешним резолвером.

---

Источник: https://www.zevshost.net/ru/kb/tlsa-dane-dns/