DANE для SMTP решает давнюю проблему оппортунистического шифрования: обычный smtp tls шифрует канал, но подлинность сервера почти нигде не гарантируется. DANE связывает сертификат SMTP‑сервера с DNS‑именем через запись TLSA, причём доверие основано не на DNSSEC‑подписи вашей зоны. В результате отправляющий MTA может строго проверить, что подключается к именно тому узлу, чей ключ опубликован в DNS, и не понизить шифрование при активном вмешательстве на пути.
Как работает DANE для SMTP
Механика проста на бумаге и критична к деталям на практике. Отправляющий MTA:
- разрешает MX для домена получателя;
- для каждого MX‑узла ищет TLSA‑запись по имени вида
_25._tcp.<mx-хост>; - проверяет, что ответ на TLSA защищён DNSSEC (флаг AD, валидная цепочка подписи);
- устанавливает TLS и сравнивает полученный сертификат/ключ с данными из TLSA;
- при успешном совпадении продолжает доставку по защищённому каналу, при провале — не шлёт на этот MX (или пробует другой).
Ключевые свойства:
- DANE требует DNSSEC. Без валидной подписи TLSA игнорируется для SMTP‑DANE и клиент вернётся к оппортунистическому TLS.
- Записи TLSA публикуются для целевых узлов MX, а не для самого домена.
- Имя TLSA включает порт и протокол: для SMTP это
_25._tcp.<mx-хост>.
MX никогда не должен указывать на CNAME. TLSA тоже публикуется на имя хоста A/AAAA, на который указывает MX.
Структура TLSA: usage, selector, match
TLSA имеет три параметра плюс значение. В текстовом виде это четыре столбца:
_25._tcp.mx1.example.ru. 3600 IN TLSA 3 1 1 a1b2c3... (hex)
Поля:
- Certificate Usage (0,1,2,3): как интерпретировать запись.
- Selector (0,1): что именно хешируем — весь сертификат или только ключ (SPKI).
- Matching Type (0,1,2): точное совпадение/хеш SHA‑256/хеш SHA‑512.
Практически для SMTP чаще всего рекомендуют 3 1 1 — DANE‑EE, SPKI, SHA‑256. Это:
- жёстко привязывает конечный сертификат к опубликованному открытому ключу;
- не требует доверия к публичному УЦ;
- позволяет менять сам сертификат (например, переиздавать), сохраняя ключ.
Альтернатива — 3 0 1 (хеш всего сертификата), но тогда каждое перевыпускание меняет TLSA‑значение. Варианты 2 x x (DANE‑TA) встречаются реже, требуют аккуратной работы с доверенными якорями и чаще используются крупными почтовыми операторами.
Где публиковать TLSA
Запись создаётся для каждого конечного MX‑хоста, на который указывает MX вашей зоны. Пример:
example.ru. 3600 IN MX 10 mx1.example.ru.
example.ru. 3600 IN MX 20 mx2.example.ru.
_25._tcp.mx1.example.ru. 3600 IN TLSA 3 1 1 <HEX1>
_25._tcp.mx2.example.ru. 3600 IN TLSA 3 1 1 <HEX2>
Если для доставки используется SMTPS на 465 (редко в MTA‑to‑MTA) или Submission на 587, то соответственно имя будет _465._tcp.<host> или _587._tcp.<host>. Для межсерверной доставки нас интересует порт 25.
Подготовка: включаем DNSSEC
Без DNSSEC DANE не работает. Этапы:
- Подпишите зону домена KSK/ZSK‑ключами в используемом DNS‑провайдере или на своём авторитативном сервере.
- Опубликуйте DS в реестре домена через регистратора.
- Проверьте валидацию: ответы на MX и TLSA должны приходить с флагом AD при запросе через валидирующий резолвер.
Базовые проверки:
# Проверить MX и AD‑флаг
dig +dnssec +multi example.ru MX
# Проверить TLSA и AD‑флаг
dig +dnssec +multi _25._tcp.mx1.example.ru TLSA
Если AD не установлен, значит вы либо спрашиваете невалидирующий резолвер, либо цепочка DS/DNSKEY/подписей неполная. Исправьте это до публикации TLSA, иначе рискуете попасть в недоставку почты при включённом DANE у отправителей. Если домен оформлен через регистрацию доменов, все действия по DS выполняются у регистратора.
Генерация значения TLSA
Нам нужен хеш от сертификата или ключа. Для популярного варианта 3 1 1 (SPKI/SHA‑256) используем openssl:
# Извлечь SPKI и посчитать SHA‑256 (без двоеточий)
openssl x509 -in /etc/ssl/certs/mail.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | xxd -p -c 256
Результат — шестнадцатеричная строка, которую вставляем в TLSA. Для варианта 3 0 1 (хеш всего сертификата):
# SHA‑256 от DER‑представления сертификата
openssl x509 -in /etc/ssl/certs/mail.pem -outform DER | openssl dgst -sha256 -binary | xxd -p -c 256
Если сертификат хранится как полный цепочный файл, укажите конкретный конечный сертификат (EE), а не цепочку. В случае пачки файлов выделите нужный.
Публикация TLSA: TTL, синтаксис, распространённые нюансы
Рекомендации по TTL:
- Для начала поставьте разумный TTL, например 3600–7200 секунд, чтобы облегчить возможный откат.
- После стабилизации можно поднять до 86400, если инфраструктура и ротация ключей выстроены.
Синтаксис для текстовой зоны BIND‑подобного формата:
_25._tcp.mx1 3600 IN TLSA 3 1 1 a1b2c3d4e5...f0
Если DNS‑панель не поддерживает тип TLSA, используйте интерфейс «сырой записи» или запросите поддержку. Не пытайтесь имитировать TLSA через TXT — это не будет работать.
Проверка соответствия на проводе
Когда запись опубликована и DNSSEC валиден, проверить соединение можно так:
# Посмотреть, какой сертификат отдаёт SMTP‑сервер
openssl s_client -starttls smtp -connect mx1.example.ru:25 -showcerts
# Убедиться, что TLSA видна и подписана
dig +dnssec _25._tcp.mx1.example.ru TLSA
Для Postfix есть удобная утилита диагностики DANE:
# Проверить доставку и DANE‑валидацию до домена
posttls-finger -Lsummary -c -l dane example.ru
Она последовательно пройдёт MX‑записи и покажет, как прошла проверка TLSA для каждого хоста.
Настройка SMTP‑сервера: входящее и исходящее
Входящее (вы — MX, другие проверяют вас)
Чтобы другие сервера могли успешно пройти DANE‑проверку:
- Настройте TLS на SMTP‑демоне (сертификат и ключ). Для совместимости с не‑DANE лучше использовать сертификат от публичного УЦ, но DANE это не требует. У нас доступны SSL-сертификаты.
- Опубликуйте корректные TLSA‑записи для всех MX‑узлов.
- Следите за тем, чтобы имя в сертификате соответствовало MX‑хосту (полезно для клиентов без DANE). При usage 3 это не обязательно, но повышает совместимость.
Исходящее (вы проверяете чужие MX по DANE)
Postfix (исходящее):
# main.cf — включаем DANE и DNSSEC‑валидацию при исходящей доставке
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec
smtp_tls_loglevel = 1
# Рекомендуемые протоколы/шифры по политике безопасности вашей организации
smtp_tls_protocols = !SSLv2, !SSLv3
С этими настройками Postfix будет валидировать TLS через TLSA, когда у домена получателя есть DNSSEC и публикации TLSA. Если у домена нет DNSSEC/TLSA, поведение останется оппортунистическим.
Postfix (входящее):
# main.cf — базовая TLS‑настройка на приём (не про DANE, но нужна для шифрования)
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/ssl/certs/mail.pem
smtpd_tls_key_file = /etc/ssl/private/mail.key
smtpd_tls_loglevel = 1
Exim (исходящее):
# В transport remote_smtp включаем запрос DNSSEC и DANE
remote_smtp:
driver = smtp
dnssec_request_domains = *
tls_dane = yes
Конкретные имена опций могут отличаться между версиями Exim; проверьте документацию вашей сборки. Смысл — запрашивать DNSSEC‑валидацию записей и включать DANE для проверки TLS. Если поднимаете собственный MTA и авторитативный DNS на VDS, автоматизируйте выпуск и установку сертификатов.
Стратегия ротации ключей и сертификатов
Самая опасная часть — не потерять доставляемость при замене ключа или сертификата. Для схемы 3 1 1 есть безопасный сценарий:
- Сгенерируйте новый ключ и сертификат.
- Добавьте вторую TLSA‑запись с хешем SPKI нового ключа, не удаляя старую (двойная публикация).
- Подождите время не меньше максимального TTL в цепочке и периода обновления кэшей (обычно 1–2 суток для надёжности).
- Переключите SMTP на новый сертификат.
- Через день‑два удалите старую TLSA.
Такой двухфазный подход исключает окно, в котором часть отправителей увидит несоответствие. Если используете 3 0 1 (хеш всего сертификата), принцип такой же — публикуете обе записи заранее.
Типичные ошибки и отладка
- Нет DNSSEC на домене. TLSA публикуется, но игнорируется отправителями. Решение — включить DNSSEC и опубликовать DS.
- Неправильное имя TLSA. Публикуют
_25._tcp.example.ruвместо_25._tcp.mx1.example.ru, а MX указывает на другой хост. TLSA должен быть на конечном MX‑узле. - Не тот объект хешируется. Для 3 1 1 нужен хеш SPKI, а не файла цепочки. Проверьте свою команду openssl.
- Сломанный DNSSEC. Истёкшая подпись, несоответствие DS в реестре. Проверьте валидацию через независимый валидирующий резолвер.
- Мгновенная замена без двойной публикации. Приводит к провалам доставки до обновления кэшей. Делайте оверлап.
- Несовместимые шифры/протоколы. Слишком агрессивная политика TLS на сервере может порвать доставку со старыми отправителями. Сопоставляйте требование безопасности и реальную почтовую экосистему.
Мини‑чеклист диагностики:
# 1) Проверить MX
dig +dnssec example.ru MX
# 2) Проверить TLSA на каждом MX‑узле
dig +dnssec _25._tcp.mx1.example.ru TLSA
# 3) Сверить сертификат на проводе
openssl s_client -starttls smtp -connect mx1.example.ru:25 -servername mx1.example.ru
# 4) Постфикс‑проверка маршрута и DANE
posttls-finger -Lsummary -c -l dane example.ru
DANE и MTA‑STS: вместе надёжнее
DANE опирается на DNSSEC и работает на уровне DNS. MTA‑STS базируется на политике, доступной по HTTPS, с доверием к публичным УЦ, и не требует DNSSEC. Эти механизмы дополняют друг друга: при доступности DNSSEC DANE обеспечивает криптографически сильную привязку ключа к MX; при недоступности DNSSEC MTA‑STS может смягчить риски понижения шифрования. Для максимального охвата экосистемы используйте оба подхода и не забывайте про SPF, DKIM и DMARC — см. материал «DNS‑записи для аутентификации почты» в разделе DNS‑записи для аутентификации почты.
Практические рекомендации по проектированию
- Старайтесь использовать
3 1 1и хранить ключи отдельно от сертификатов — это упрощает перевыпуски. - Не публикуйте TLSA до включения и проверки DNSSEC. Сначала DNSSEC, затем TLSA.
- Держите MX‑инфраструктуру простой: без CNAME под MX и неожиданных переадресаций.
- Логируйте TLS‑инциденты на MTA, включите повышенный уровень логов на период запуска.
- Планируйте ротацию с двойной публикацией и пониженными TTL на время работ. Для автоматизации выпуска сертификатов может пригодиться подход с DNS‑01 — см. заметку про автоматизацию wildcard в материале Wildcard SSL и DNS‑01.
FAQ
Можно ли использовать самоподписанный сертификат с DANE? Да, при usage 3 DANE‑EE доверие к УЦ не требуется. Но клиенты без DANE могут не принять такой сертификат и уйти в plaintext или отказаться от TLS. Для совместимости с миром лучше публичный УЦ.
Нужно ли, чтобы CN/SAN совпадали с MX‑именем? Для DANE‑EE это не обязательно, но желательно для неконсистентных клиентов и лучшей диагностики.
Сколько TLSA‑записей можно публиковать? Сколько нужно. Дубли для ротации — нормальная практика. Все записи в RRset оцениваются равноценно; совпадение с любой засчитывается.
Как быть с IPv6? DANE не зависит от семейства адресов. Опубликуйте AAAA для MX при необходимости — TLSA остаётся прежним.
Итоги
DANE для SMTP — зрелая технология повышения безопасности доставки почты. Она требует дисциплины в управлении DNSSEC, аккуратной публикации TLSA и продуманной ротации ключей, но взамен даёт верифицируемое шифрование на транспортном уровне. Начните с включения DNSSEC, выберите консервативную схему 3 1 1, автоматизируйте генерацию хешей и проверки, добавьте двуступенчатую ротацию — и ваша почта будет устойчивее к атакам понижения шифрования и MITM.
