AXFR

Домен почти всегда обслуживают несколько авторитетных серверов. Записи редактируют на одном из них, основном, а остальные держат копии. Чтобы копии совпадали, вторичный сервер периодически сверяет серийный номер в SOA-записи. Если номер вырос, он запрашивает зону заново. Полный перенос и называется AXFR — Authoritative Zone Transfer.

Передача идёт по TCP, потому что зона может быть большой и не помещается в один UDP-пакет. Основной сервер может сам поторопить вторичные уведомлением NOTIFY, чтобы изменения разошлись за секунды, а не по таймеру. Для больших зон, где меняется пара записей, полный перенос расточителен — поэтому существует IXFR, передающий только разницу.

Почему открытый AXFR — проблема

Если сервер отдаёт зону любому желающему, посторонний получает полный список имён домена: тестовые поддомены, адреса админок, внутренние сервисы, забытые staging-копии сайта. Это готовая карта для атаки. Поэтому перенос разрешают только адресам своих вторичных серверов, а для надёжности подписывают ключом TSIG.

Пример настройки BIND и проверки

zone "example.com" {
    type primary;
    file "/etc/bind/db.example.com";
    allow-transfer { 192.0.2.53; };
    also-notify { 192.0.2.53; };
};

Проверка снаружи: dig AXFR example.com @ns1.example.com.

В старых версиях BIND вместо primary пишут master. Если сервер настроен правильно, команда dig с чужого адреса вернёт «Transfer failed». Если же в ответ посыпались все записи зоны, доступ стоит закрыть.

Когда с этим сталкивается владелец сайта

Чаще всего — при подключении вторичного DNS у другого провайдера. Он попросит разрешить перенос зоны с его адресов. Если DNS полностью обслуживает регистратор или хостинг, настраивать ничего не нужно: доступ к переносу там уже ограничен.