# 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/uk/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/uk/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/uk/kb/proverka-dns-zony-dig/).

## Обмеження DANE: обов'язковий DNSSEC і підтримка софту

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

## Підсумок: чек-лист впровадження TLSA

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

---

Джерело: https://www.zevshost.net/uk/kb/tlsa-dane-dns/