Я недавно начал переходить на привязку 9.9.7 и столкнулся с неприятным камнем преткновения с привязкой.
Я настраиваю представления в своей среде, чтобы позволить мне различать 4 мои зоны с разными IP-адресами в зависимости от того, откуда хост выполняет запрос. Остальные 36 зон, которые я обслуживаю, не различают IP-адреса, а всегда должны обслуживать один и тот же адрес для каждого хоста. Для этого я создал отдельный список хостов, который затем использовал include директива в named.conf чтобы включить эти записи в обе зоны. Вот краткий пример конфигурации, с которой я работал на одном из моих подчиненных серверов:
Сначала фрагмент моего named.conf
view "sitea" {
match-clients {192.168.1.0/24;};
zone "mydomain.com." IN {
type slave;
masters { 192.168.1.100;};
file "sitea_mydomain.com.db";
};
include "/etc/common_zones.conf";
};
view "siteb" {
match-clients {any; };
zone "mydomain.com." IN {
type slave;
masters {192.168.1.100; };
file "mydomain.com.db";
};
include "/etc/common_zones.conf";
};
И отрывок из common_zones.conf файл:
zone "1.168.192.in-addr.arpa." IN {
type slave;
masters {192.168.1.100;};
file "192.168.1.db";
};
Раньше связывание было совершенно круто с использованием одного и того же файла дважды в конструкции представления, но теперь это не так. Наличие файла зоны, дважды указанного в двух разных представлениях, вызывает ошибку, в которой конкретно говорится, что привязка не допускает эту конфигурацию. В этом случае он сообщает мне, что не запустится, потому что я использовал дублирующийся файл. 192.168.1.db. В частности, сообщение об ошибке:
writeable file '192.168.1.db': already in use: /etc/common_zones.conf
Проблема, с которой я сталкиваюсь, заключается в моем реальном мире, у меня есть более 40 зон (обратных зон), которые, несмотря на вид, из которого они исходят, всегда будут одним и тем же ответом, несмотря ни на что. Возможность использовать общее включение, как показано выше, была прекрасным способом, позволяющим мне выделить несколько хостов для домена "mydomain.com". Теперь я столкнулся с возможной необходимостью входа в 40 зон в каждом представлении, каждая из которых указывает на другой файл, несмотря на то, что данные идентичны.
Есть ли у кого-нибудь умное решение для этого?
Если обновление до Bind 9.10 возможно, инструкция "in-view" решит эту проблему идеально ( http://www.zytrax.com/books/dns/ch7/zone.html#in-view ).
Однако, если это невозможно, я заметил кое-что довольно интересное, чего я не знал, когда смотрел "в поле зрения". Для подчиненных зон параметр "файл" (в приведенной выше ссылке он стоит непосредственно перед словом "in-view") по желанию. Возможно, это именно то решение, которое вы ищете. Я предполагаю, что зона будет существовать только в ОЗУ и будет повторно передаваться каждый раз, когда ведомое устройство перезапускает или перезагружает зону. Стоит попробовать. (Изменить: вам все равно понадобятся 2 версии вашего общего файла, одна для мастеров с именами файлов и одна без - так что это не совсем идеальное решение)
Возможно, с named.conf конфигурация:
view "sitea" {
include "/etc/common_zones.conf";
match-clients {localhost; ...; };
};
view "siteb" {
include "/etc/UNcommon_zones.conf";
match-clients {any;};
};
А потом common_zones.conf это то, что есть сейчас, а в UNcommon_zones.conf вы вводите экспедиторов:
zone "..." IN {
type forward;
forward only;
forwarders { 127.0.0.1; };
};
который, по крайней мере, не дает ошибок при довольно ограниченном тестировании с тестовым virt, вытягивающим главную зону, и другим тестом, выдающим запросы упомянутому тестируемому ведомому NS.