DANE для email: как настроить DNS-аутентификацию TLS

SPF, DKIM и DMARC доказывают, что письмо отправили именно вы. Но они не гарантируют, что между вашим сервером и принимающим никто не встал посередине. За шифрование канала отвечает STARTTLS, а за то, чтобы шифрование нельзя было тихо отключить, - DANE.

Проблема: STARTTLS без гарантий

Когда один почтовый сервер (MTA) подключается к другому по SMTP, он может предложить шифрование через команду STARTTLS. Принимающий сервер отвечает «ок» и показывает свой TLS-сертификат. Проблема в том, что SMTP-клиент обычно не проверяет, кому этот сертификат выдан. Он принимает любой - самоподписанный, просроченный, выданный другому домену. Шифрование есть, аутентификации - нет.

Ещё хуже: атакующий на канале между серверами может просто вырезать строку 250-STARTTLS из ответа сервера. Отправляющий MTA думает, что получатель не поддерживает шифрование, и передаёт письмо открытым текстом. Это называется STARTTLS stripping, и это не теория - такие атаки документировались в реальных сетях.

Что такое DANE и как он решает проблему

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

Если сертификат не совпадает - соединение обрывается. Если TLSA-запись существует, но сервер не предлагает STARTTLS, - письмо не отправляется. Никакого тихого отката на нешифрованный канал. Никакого принятия чужого сертификата.

Критическое условие: DANE работает только поверх DNSSEC. Без криптографической подписи зоны DNS атакующий мог бы подменить саму TLSA-запись, и вся схема потеряла бы смысл. DNSSEC гарантирует целостность данных в DNS - а DANE использует эти данные для аутентификации TLS.

Анатомия TLSA-записи

TLSA-запись размещается в DNS по определённому имени. Для почтового сервера mail.example.com на порту 25 имя записи будет:

_25._tcp.mail.example.com.  IN  TLSA  3 1 1 2bb183af2049...полный_sha256_хеш

Четыре числовых поля после TLSA определяют, что именно проверяется и как. Разберём каждое.

Certificate Usage (первое поле)

• 0 (PKIX-TA) - сертификат должен быть подписан указанным CA и пройти стандартную проверку цепочки.
• 1 (PKIX-EE) - конкретный конечный сертификат, плюс стандартная проверка цепочки через CA.
• 2 (DANE-TA) - доверяем указанному CA, без привязки к глобальным корневым хранилищам. Можно использовать внутренний CA.
• 3 (DANE-EE) - прямое указание конкретного сертификата. Никакой проверки цепочки, никаких CA. Самый распространённый вариант для SMTP.

Для почтовых серверов RFC 7672 рекомендует 3 (DANE-EE). Причина практическая: при usage 3 не нужна валидация имени хоста в сертификате и не нужна цепочка до CA. Это упрощает работу с Let's Encrypt, где сертификаты обновляются каждые 60-90 дней. Если привязать TLSA к публичному ключу (selector 1), а не к полному сертификату, - запись в DNS менять не придётся при каждом обновлении.

Selector (второе поле)

• 0 - хеш считается от полного сертификата (DER).
• 1 - хеш считается от публичного ключа (SubjectPublicKeyInfo). При обновлении сертификата с тем же ключом TLSA-запись остаётся валидной.

Matching Type (третье поле)

• 0 - полное содержимое (без хеширования). Длинное. Непрактично.
• 1 - SHA-256. Стандартный выбор.
• 2 - SHA-512. Допустимо, но SHA-256 достаточен и более совместим.

Итого, рекомендуемая комбинация для SMTP: 3 1 1 - DANE-EE, публичный ключ, SHA-256. Это даёт максимальную устойчивость при ротации сертификатов и минимальную зависимость от внешних CA.

Пошаговая настройка DANE для почтового сервера

Шаг 1. Убедитесь, что DNSSEC включён

DANE без DNSSEC не работает. Проверяйте подпись вашей зоны:

dig +dnssec example.com A +short

Если в ответе присутствует флаг ad (Authenticated Data) - зона подписана и валидируется. Полная проверка:

dig +dnssec +multi example.com SOA

# Должны быть RRSIG-записи в ответе
# Флаг "ad" в секции flags

Если DNSSEC не настроен - начните с него. У большинства крупных регистраторов (Cloudflare, Route53, Hetzner DNS) включение DNSSEC занимает несколько кликов. Для своего DNS-сервера придётся генерировать KSK/ZSK-ключи и публиковать DS-запись у регистратора. Это отдельная тема, но без неё двигаться дальше нет смысла.

Шаг 2. Настройте TLS на почтовом сервере

Ваш MTA должен предлагать STARTTLS с валидным сертификатом. Для Postfix в main.cf:

smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
smtpd_tls_security_level = may
smtpd_tls_protocols = >=TLSv1.2

Значение may означает: предлагаем TLS, но не требуем. Это стандарт для входящего SMTP - требование TLS на порту 25 сломает доставку от серверов, которые его не поддерживают. DANE работает со стороны отправителя: именно отправляющий MTA решает, доверять ли сертификату, проверяя TLSA.

Шаг 3. Сгенерируйте хеш для TLSA

Для записи 3 1 1 нужен SHA-256 хеш публичного ключа из сертификата:

# Извлечь хеш публичного ключа из сертификата
openssl x509 -in /etc/letsencrypt/live/mail.example.com/cert.pem \
  -noout -pubkey | \
  openssl pkey -pubin -outform DER | \
  openssl dgst -sha256 -binary | \
  xxd -p -c 32

Результат - 64 символа hex. Например:

2bb183af20492e69e42f5a83e91cf269c1837f2638898c1e045297b72a27bc4d

Альтернативный путь - использовать утилиту tlsa из пакета hash-slinger:

# Debian/Ubuntu
apt install hash-slinger

# Генерация TLSA-записи
tlsa --create --selector 1 --mtype 1 \
  --certificate /etc/letsencrypt/live/mail.example.com/cert.pem \
  mail.example.com

Утилита выдаст готовую DNS-запись, которую остаётся только скопировать в зону.

Шаг 4. Опубликуйте TLSA-запись в DNS

Допустим, MX-запись вашего домена указывает на mail.example.com. Тогда TLSA-запись для порта 25:

_25._tcp.mail.example.com.  IN  TLSA  3 1 1 (
  2bb183af20492e69e42f5a83e91cf269
  c1837f2638898c1e045297b72a27bc4d )

Обратите внимание: имя записи строится от MX-хоста, не от основного домена. Если у вас MX указывает на mx1.example.com, запись будет _25._tcp.mx1.example.com. Типичная ошибка - создать TLSA для основного домена, а не для хоста из MX. Отправляющий MTA ищет TLSA именно по тому имени, на которое указывает MX.

Шаг 5. Проверка

Убедитесь, что запись доступна и подписана DNSSEC:

# Проверка TLSA-записи
dig TLSA _25._tcp.mail.example.com +short

# Проверка с DNSSEC-валидацией
dig +dnssec TLSA _25._tcp.mail.example.com

# Полный чеклист DNS для почтового сервера
dig MX example.com +short
dig A mail.example.com +short
dig TLSA _25._tcp.mail.example.com +short
dig +dnssec _25._tcp.mail.example.com TLSA | grep -c RRSIG

Последняя команда должна вернуть 1 или больше - это означает, что RRSIG-подпись присутствует. Если 0 - DNSSEC для этой записи не работает, и DANE-валидация со стороны отправителя будет проигнорирована.

Для внешней проверки используйте check.sidnlabs.nl/dane или dane.sys4.de. Оба инструмента проверяют TLSA, DNSSEC и реальное TLS-соединение с вашим MX.

Ротация сертификатов без даунтайма

Если вы используете 3 1 1 (хеш публичного ключа), обновление сертификата с сохранением того же ключа не требует изменений в DNS. Certbot по умолчанию сохраняет ключ при продлении, так что в большинстве случаев вам не нужно ничего делать.

Если ключ всё-таки меняется (принудительная ротация, смена алгоритма, компрометация), порядок действий:

1. Сгенерируйте новый ключ и получите новый сертификат.
2. Вычислите хеш нового публичного ключа.
3. Добавьте вторую TLSA-запись с новым хешем. Не удаляйте старую.
4. Дождитесь, пока TTL старой записи истечёт и новая распространится (обычно 1-24 часа в зависимости от TTL).
5. Переключите сервер на новый сертификат.
6. Через период, равный TTL, удалите старую TLSA-запись.

Две TLSA-записи одновременно - это штатная ситуация. RFC явно допускает несколько записей для одного имени. Отправляющий MTA проверяет все и считает валидацию пройденной, если хотя бы одна совпала.

; Старый ключ (активный сертификат)
_25._tcp.mail.example.com.  IN  TLSA  3 1 1 2bb183af2049...старый_хеш

; Новый ключ (будущий сертификат)
_25._tcp.mail.example.com.  IN  TLSA  3 1 1 a1b2c3d4e5f6...новый_хеш

DANE vs MTA-STS: когда что использовать

MTA-STS (RFC 8461) решает ту же задачу - защита от STARTTLS stripping и проверка сертификата. Но делает это иначе: политика публикуется через HTTPS (файл .well-known/mta-sts.txt), а TXT-запись в DNS только сигнализирует о её наличии.

Ключевые различия:

• DANE требует DNSSEC. MTA-STS - нет. Если у вашего домена нет DNSSEC (а у большинства нет), MTA-STS - единственный вариант.
• DANE аутентифицирует конкретный ключ или сертификат. MTA-STS полагается на WebPKI (стандартные CA). DANE строже.
• MTA-STS использует TOFU (Trust On First Use) - первое обращение не защищено. DANE защищает с первого соединения, потому что данные подписаны DNSSEC.
• Поддержка отправителей: Postfix поддерживает DANE из коробки. Gmail проверяет и DANE, и MTA-STS. Outlook/Microsoft - только MTA-STS (DANE-валидация на стороне отправки у Microsoft до сих пор не реализована в полном объёме).

Если есть возможность - настраивайте оба. Они не конфликтуют. MTA-STS подхватит тех отправителей, которые не проверяют DANE, а DANE даст более строгую защиту для тех, кто его поддерживает.

Бонус: DANE-проверка на исходящих соединениях (Postfix)

До сих пор речь шла о публикации TLSA для вашего сервера - чтобы входящая почта была защищена. Но вы можете настроить и проверку DANE при отправке. Postfix делает это встроенными средствами:

# main.cf - включить DANE-проверку при отправке
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec

С этими настройками Postfix при отправке письма ищет TLSA-запись для MX получателя. Если запись найдена и подписана DNSSEC - соединение устанавливается только с проверенным сертификатом. Если TLSA нет - используется обычный оппортунистический TLS. Никакой потери совместимости.

Для работы DANE-проверки на исходящих нужен локальный DNSSEC-валидирующий резолвер. Unbound или systemd-resolved с включённой DNSSEC-валидацией подходят. Проверьте, что резолвер возвращает AD-флаг:

dig +dnssec example.com @127.0.0.1 | grep flags
# Ищите "ad" в списке флагов

Частые ошибки при настройке DANE

• TLSA без DNSSEC. Самая распространённая проблема. Запись в DNS есть, но зона не подписана. Отправители, реализующие DANE по RFC, проигнорируют такую запись. Некоторые - обработают некорректно. Результат непредсказуем. Проверяйте DNSSEC до того, как публиковать TLSA.
• TLSA привязана к полному сертификату (selector 0) при использовании Let's Encrypt. Сертификат обновляется каждые 60-90 дней. Если TLSA содержит хеш старого сертификата, после обновления DANE-валидация провалится. Используйте selector 1 (публичный ключ) или автоматизируйте обновление DNS.
• TLSA на имени домена, а не на имени MX-хоста. Запись _25._tcp.example.com не будет найдена, если MX указывает на mail.example.com. Нужно _25._tcp.mail.example.com.
• Забыли обновить TLSA после смены ключа. Новый сертификат, новый ключ, старый хеш в DNS. Входящие DANE-проверки проваливаются. Для критичных доменов это означает потерю писем от отправителей со строгой DANE-политикой.
• Низкий TTL на TLSA. С одной стороны, низкий TTL позволяет быстрее менять записи. С другой - DANE работает надёжнее при TTL от 1 часа и выше, потому что кеширование снижает зависимость от кратковременных проблем с DNS.

Кто уже использует DANE

В Европе DANE для почты - практически стандарт. Нидерланды, Германия, Чехия лидируют по внедрению. Немецкие провайдеры (mail.de, posteo.de, mailbox.org) проверяют DANE при отправке и публикуют TLSA-записи для входящих. Государственные домены в Нидерландах обязаны поддерживать DANE по стандарту «Comply or Explain». Gmail проверяет DANE при отправке с 2015 года. Comcast - тоже.

На стороне крупных почтовых провайдеров в зоне .ru поддержка DANE пока ограничена. Но если ваш сервер принимает почту от Gmail, Postfix-серверов с DANE или европейских организаций - наличие TLSA-записи непосредственно улучшает безопасность этих соединений.