Назад | Перейти на главную страницу

Отдельные исключения зоны для каждого вида в BIND

Проблема: разделить зоны по исходной сети запросов и вернуть разные записи для клиентов LAN по сравнению с клиентами WAN.

Я реализовал это дома на небольшом роутере Alix с Bind 9.4. Одно представление называется «lan», а другое - «wan». В представлении "lan" был только файл root.hints и одна зона.

В представлении «wan» было много других зон, включая копию одной зоны из представления «lan», но с другими записями.

Запрос domain1.tld из локальной сети даст мне локальные записи. Запрос domain1.tld из глобальной сети даст мне внешние записи. Запрос domain2.tld из LAN даст мне те же записи, что и из WAN, поскольку он существует только в представлении WAN.

Теперь я пытаюсь повторно реализовать это в большем масштабе, и внезапно мое представление не может запрашивать что-либо вне себя. Это естественно в соответствии со списком пользователей привязки, и они предлагают мне скопировать все мои представления в представление LAN.

Я надеюсь, что у кого-то есть лучшее решение, потому что это означает, что мне придется копировать и поддерживать тысячи файлов зон в нескольких представлениях. Это невозможно.

Моя домашняя конфигурация похожа на эту.

acl lanClients {
 192.168.22.0/24;
 127.0.0.1;
};

view "intranet" {
 match-clients { lanClients; };
 recursion yes;
 notify no;

 // Standard zones
 //
 zone "." {
  type hint;
  file "etc/root.hint";
 };

 zone "domain1.tld" {
  type master;
  file "intranet/domain1.tld";
 };
};

view "internet" {
 match-clients { !localnets; any; };
 recursion no;
 allow-transfer { slaveDNS; };

 include "master.zones";
};

Запросы из LAN для domain1.tld дают локальные записи, запросы из WAN дают удаленные записи. Это отлично работает как дома, так и в моем новом Bind 9.7 в больших масштабах.

Разница в том, что дома мне каким-то образом удалось заставить мою локальную сеть получать удаленные записи из доменов в master.zones, не указывая эти зоны как дубликаты в представлении «интрасеть».

Попробовав это в большем масштабе с Bind 9.7, я не получил никаких результатов, кроме зон, указанных в представлении. Что мне не хватает? Я пробовал такую ​​же конфигурацию для Bind 9.7.

Каждое представление имеет отдельный набор зон, поэтому одно представление не будет отвечать за зоны, указанные только в другом представлении, поэтому ваше поведение в некоторой степени ожидаемо. Но как только все ваши WAN-зоны будут правильно делегированы вашему серверу из родительской зоны, intranet view будет следовать цепочке делегирования, вернется на ваш собственный сервер и запросит у себя эту зону.

Я думаю, у вас проблема либо в том, что вы тестируете свой сервер и еще не делегировали зоны, либо источник ваших запросов BIND попадает в lanClients ACL и таким образом создает бесконечный цикл.

Хитрость в том, чтобы использовать query-source 1.2.3.4;, где 1.2.3.4 IP-адрес внешнего интерфейса, не попадающий в lanClients ACL.

Другой вариант - добавить forward only; и forwarders 1.2.3.4; для вашего представления в интрасети - в этом случае цепочка делегирования не имеет значения, и это будет работать также за NAT.

В любом случае запросы, сделанные самой bind, должны быть исключены из lanClients Посмотреть.