DNS изначально проектировался без всякой защиты: резолвер верит любому ответу, который пришёл с нужного адреса и с нужным ID запроса. Это открывает дорогу подмене ответов и отравлению кеша. В этом уроке мы закрываем дыру криптографией: DNSSEC подписывает данные зоны и строит цепочку доверия от корня, DANE привязывает TLS-сертификат к имени через DNS, TSIG защищает служебные транзакции между серверами, а CAA ограничивает, кто вообще может выпустить сертификат на ваш домен. В конце разберём, как закалить сам резолвер.
Как это работает
DNSSEC не шифрует трафик. Он добавляет к записям подписи, чтобы резолвер мог проверить целостность и подлинность данных. Каждая зона держит пару ключей. ZSK (Zone Signing Key) подписывает обычные наборы записей, KSK (Key Signing Key) подписывает только сам набор DNSKEY. Подписи лежат в записях RRSIG, публичные ключи - в DNSKEY.
Доверие строится снизу вверх. Родительская зона хранит запись DS - это хеш вашего KSK. Резолвер идёт от корня: проверяет DS у родителя, по нему доверяет вашему KSK, тот подтверждает DNSKEY, а ZSK из DNSKEY проверяет RRSIG на конкретной записи. Корневой ключ зашит в резолвер как trust anchor. Если хоть одно звено не сходится, ответ помечается как SERVFAIL с флагом провала валидации.
DANE решает другую задачу. Обычный TLS доверяет любому из сотен CA. DANE через запись TLSA говорит: для этого хоста и порта валиден вот именно такой сертификат или ключ. Работает только поверх DNSSEC, иначе саму TLSA-запись можно подменить. Формат - три числа: usage, selector, matching-type. Для почты по RFC 7672 канон это 3 1 1: DANE-EE (проверяем сам сертификат сервера, без оглядки на CA), selector SPKI (хешируем только публичный ключ, а не весь сертификат), SHA-256.
TSIG - это симметричная подпись транзакций общим секретом. Её ставят на трансфер зоны (AXFR/IXFR), на динамические обновления и на NOTIFY. Сервер и клиент знают один ключ, подпись кладётся в дополнительную секцию пакета. Время в подписи имеет значение: разъехавшиеся часы ломают TSIG.
CAA - простая, но важная запись. Она перечисляет, какие удостоверяющие центры имеют право выпускать сертификаты на домен. Перед выдачей CA обязан её проверить. Это не про DNSSEC напрямую, но это часть той же гигиены доверия.
Команды и примеры
В 2026 в BIND 9.20 ручное жонглирование ключами через auto-dnssec ушло в прошлое. Используем dnssec-policy: BIND сам генерирует ключи, подписывает зону inline и ротирует ключи по расписанию. Дефолтная политика - один CSK на алгоритме 13 (ECDSAP256SHA256).
Установка пакетов:
Код: Выделить всё
# Debian 13 / Ubuntu 24.04
apt install bind9 bind9-dnsutils
# RHEL 10 / Fedora 41+
dnf install bind bind-utilsКод: Выделить всё
zone "example.com" {
type primary;
file "/var/lib/bind/example.com.zone";
dnssec-policy default;
inline-signing yes;
};Код: Выделить всё
rndc dnssec -status example.com
dnssec-dsfromkey -2 Kexample.com.+013+12345.keyКод: Выделить всё
dig +dnssec +multi example.com SOA @1.1.1.1
delv example.com SOA # delv делает полную валидацию локальноГенерируем TLSA для почтового сервера из живого сертификата (3 1 1, SPKI, 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 256Код: Выделить всё
_25._tcp.mail.example.com. IN TLSA 3 1 1 <хеш>CAA-запись в зоне:
Код: Выделить всё
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:security@example.com"Код: Выделить всё
tsig-keygen -a hmac-sha256 xfr-key > /etc/bind/xfr.keyКод: Выделить всё
key "xfr-key" { algorithm hmac-sha256; secret "..."; };
zone "example.com" { ... allow-transfer { key xfr-key; }; };- Забыли отдать DS регистратору. Зона подписана, но родитель про неё не знает - валидирующие резолверы либо не видят защиты, либо при наличии старого DS получают SERVFAIL.
- Сменили алгоритм или KSK, а DS у родителя остался старый. Цепочка рвётся мгновенно - домен пропадает для всех валидирующих резолверов.
- TLSA без DNSSEC бесполезна и опасна: запись можно подменить, проверка превращается в фикцию.
- Обновили сертификат, забыли про --reuse-key - ключ сменился, TLSA указывает на старый, почта по DANE отбивается.
- Разъехались часы на серверах - TSIG валит транзакции с BADTIME, RRSIG считаются протухшими или ещё не вступившими в силу.
- Открытый рекурсивный резолвер наружу - это участие в DNS amplification атаках. Рекурсию пускайте только для своих сетей.
- Поднимите authoritative BIND 9.20 для тестовой зоны lab.local на стенде.
- Включите dnssec-policy default и inline-signing, перезапустите named, дождитесь подписи зоны.
- Командой rndc dnssec -status убедитесь, что CSK в состоянии signing, найдите DNSKEY и RRSIG через dig +dnssec.
- Сгенерируйте DS через dnssec-dsfromkey и вручную пропишите его в родительскую тестовую зону, чтобы замкнуть цепочку.
- Проверьте полную валидацию через delv - добейтесь fully validated.
- Создайте TLSA 3 1 1 для тестового TLS-сервиса и проверьте её dig TLSA.
- Настройте TSIG-ключ и разрешите AXFR только по нему, затем убедитесь, что трансфер без ключа отбивается.
- Чем функционально различаются KSK и ZSK и почему DS у родителя считается именно от KSK, а не от ZSK?
- Какие записи участвуют в цепочке доверия от корня до конечного RRset и в каком порядке их проверяет резолвер?
- Почему для SMTP по RFC 7672 рекомендуют именно TLSA 3 1 1, а usage 0 и 1 не применяют?
- Зачем DANE строго требует работающего DNSSEC и что произойдёт при его отсутствии?
- На какие три типа транзакций ставят TSIG и почему рассинхрон времени ломает проверку?
- Что именно ограничивает запись CAA и в какой момент жизненного цикла сертификата она проверяется?
