Проблема: разделить зоны по исходной сети запросов и вернуть разные записи для клиентов 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
Посмотреть.