Сетевые средства Debian/BIND/Обслуживание вторичных копий зон

Настройку BIND как вторичного сервера для зоны рассмотрим на следующем примере описания зоны example.net. (Отметим, что здесь мы вновь обращаемся к файлу /etc/bind/named.conf.local.)

zone "example.net" {
    type slave;
    masters {
        2001:db8:42::53:53;
        192.0.2.53;
    };
    file "/var/cache/bind/cache/example.net";
    allow-transfer { localhost; };
};

Как видно, настройка обслуживания вторичной копии зоны не в пример проще настройки обслуживания первичной. (Связано это, очевидно, с отсутствием необходимости настройки таких аспектов зоны, как динамические обновления или цифровые подписи DNSSEC.)

Использующиеся в определении опции определяют список IP-адресов первичного сервера (masters) и файл, в котором будет сохранена копия зоны (file.) Сохранение копии зоны в файле позволит вторичному серверу начать обслуживание зоны сразу же после запуска, не ожидая завершения необходимого в противном случае AXFR-запроса (а также позволит использовать после запуска более экономный IXFR-запрос.)

Предполагая, что данный сервер не будет, в свою очередь, использоваться другими серверами в качестве вышестоящего для этой зоны, мы вновь ограничиваем доступ к AXFR-запросу только лишь данной системой (localhost.)

Отдельно отметим, что при использовании ключей транзакций (что рекомендуется), они могут быть настроены как указано в разделе «Ключи транзакций» — за тем лишь исключением, что ключ не генерируется заново, но подлежит копированию с первичного DNS-сервера с использованием защищенного протокола (например, SSH.)

При необходимости определить несколько вторичных зон, имеющих общий первичный сервер, адреса последнего могут быть вынесены в отдельный блок masters, подобно:

masters "betby" {
    2001:db8:42::53:53;
    192.0.2.53;
};

zone "example.net" {
    type slave; masters { "betby"; };
    file "/var/cache/bind/cache/example.net";
};

Актуализовать внесенные изменения вновь можно командой # rndc reload .