TSIG

Передачу зоны и удалённые обновления записей нельзя разрешать кому попало. Ограничение по IP-адресу помогает лишь отчасти: адрес бывает общим, а внутри сети его можно подделать. TSIG (Transaction Signature) добавляет к каждому сообщению подпись HMAC, вычисленную секретным ключом, который знают только две стороны. Исходный стандарт — RFC 2845, действующая редакция — RFC 8945.

Подпись включает время отправки, поэтому перехваченное сообщение нельзя повторить через час. Обратная сторона — часы серверов должны быть синхронизированы: при расхождении больше допустимого окна (обычно пять минут) запросы отклоняются с ошибкой BADTIME.

Настройка в BIND

Ключ создают утилитой tsig-keygen, она выводит готовый блок для конфигурации. Затем на первичном сервере разрешают передачу зоны только с этим ключом:

key "transfer-key" {
    algorithm hmac-sha256;
    secret "R3HI8P6BKw9ZwXwN3VZKuQ==";
};
zone "example.ru" {
    type primary;
    file "example.ru.db";
    allow-transfer { key "transfer-key"; };
};

На вторичном сервере тот же ключ указывают для обращений к первичному. Проверить вручную можно командой dig @ns1.example.ru example.ru AXFR -y hmac-sha256:transfer-key:СЕКРЕТ: без ключа сервер ответит отказом. Секрет в примере условный — используйте сгенерированный.

Где ещё применяется

• AXFR и IXFR между основным и вторичными серверами, в том числе у разных провайдеров.
• Динамические обновления через nsupdate: так certbot подтверждает домен через DNS для выпуска сертификата, так роутер обновляет свой адрес.
• Служебные обращения к управляющему интерфейсу сервера имён.

Чем TSIG отличается от DNSSEC

TSIG защищает разговор двух конкретных серверов, знающих общий секрет. DNSSEC подписывает сами записи открытым ключом, и проверить их может любой резолвер в интернете. Это разные задачи, и на серьёзной инфраструктуре используют оба механизма. Слабое место TSIG — сам секрет: его нужно передавать по защищённому каналу, хранить вне общедоступных репозиториев и менять при уходе людей, у которых был доступ.