Есть DNS с несколькими файлами зон. Для одной из зон нужно чтобы во внутреннюю сеть отдавались внутренние адреса, а для внешних адресов - внешние.
Делается это как я понял с помощью оператора view.
Создаем два файла для одной зоны: один для внутренних адресов, другой для внешних. Создаем например view internal и view external и в каждом из них указываем соответствующие файлы для нужной зоны.
А вот что касается других зон, по которым все остается без изменений, нужно ли их указывать в обоих view или нет?
В книжке Крикета Ли и Пола Альбица "DNS и BIND" пишут: "если создан хотя бы один оператор view, все операторы zone должны быть явно включены в один из видов."
Если мы явно включим все операторы zone например в view internal а в view external их не укажем, какие адреса будут отдаваться клиентам view external по этим зонам?
Я так понимаю нужно перечислять все zone в обоих view. Или я ошибаюсь?
> А вот что касается других зон, по которым все остается без изменений,
> нужно ли их указывать в обоих view или нет?Укажите их в третьей view (common).
> Укажите их в третьей view (common).в таком случае что нужно указать в match-clients для view common?
acl "internals" {192.168.10.0/24; 192.168.20.0/24; 127.0.0.1/32};
view "internal" {
match-clients {"internals";};
zone "local.myzone.com" {
type master;
file "master/local.myzone.com.conf";
};
};view "external" {
match-clients {"any";};
zone "myzone.com" {
type master;
file "master/myzone.com.conf";
};
};view "common" {
match_clients {"???"}
zone "zone1" {
type master;
file "master/zone1.conf"
};...
zone "zoneN" {
type master;
file "master/zoneN.conf"
};
};
И в каком порядке должны следовать view?
в таком случае что нужно указать в match-clients для view common?any
> И в каком порядке должны следовать view?
В порядке, который обеспечивает подстановку определений, типа
acl "internals" {192.168.10.0/24; 192.168.20.0/24; 127.0.0.1/32};
и своевременность считывания inсlude файлов.
> в таком случае что нужно указать в match-clients для view common?
> any
>> И в каком порядке должны следовать view?
> В порядке, который обеспечивает подстановку определений, типа
> acl "internals" {192.168.10.0/24; 192.168.20.0/24; 127.0.0.1/32};
> и своевременность считывания inсlude файлов.Хм... Мне всегда казалось, что попав под первый view с match-clients (any), последующие view не рассматриваются.
У меня через include подцепляются общие зоны как в view "internal", так и external.
Или я ошибаюсь?
> Хм... Мне всегда казалось, что попав под первый view с match-clients (any),
> последующие view не рассматриваются.Не надо включать зоны из view common в другие view.
Первоисточник посмотрите.
http://www.isc.org/software/bind/documentation
http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.htm...
>> Хм... Мне всегда казалось, что попав под первый view с match-clients (any),
>> последующие view не рассматриваются.
> Не надо включать зоны из view common в другие view.
> Первоисточник посмотрите.
> http://www.isc.org/software/bind/documentation
> http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.htm...Уважаемый DN. По приведенным вами ссылкам для моей версии BIND 9.6.1 нашел следующее:
The order of the view statements is significant — a client request will be resolved in the context of the first view that it matches.
То-есть клиент по match-clients "any" будет обработан в view external и до view common не дойдет. Соответственно клиент из локальной сети будет обработан в view internal и тоже дальше не пойдет и не получит информацию о зонах которые не включены в view internal.
Какой ответ получит клиент из локальной сети запросивший адрес из зоны не включенной в view internal?
> Какой ответ получит клиент из локальной сети запросивший адрес из зоны не
> включенной в view internal?Поделите множество клиентов "any" на непересекающиеся подмножества клиентов.
Количество непересекающихся подмножеств клиентов - это и будет количество
необходимых view.
Each view statement defines a view of the DNS namespace that will be seen by a subset of clients.В каждое view помешаете те зоны и с тем их содержанием, которое считает нужным.
Кажется, должно быть так.По поводу попадания или не попадания клиента в acl .
http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.htm...
>> в таком случае что нужно указать в match-clients для view common?
>> any
>>> И в каком порядке должны следовать view?
>> В порядке, который обеспечивает подстановку определений, типа
>> acl "internals" {192.168.10.0/24; 192.168.20.0/24; 127.0.0.1/32};
>> и своевременность считывания inсlude файлов.
> Хм... Мне всегда казалось, что попав под первый view с match-clients (any),
> последующие view не рассматриваются.тут порядок правил не важен.
используется более точное совпадение ИП (по длине маски) во всех acl. any = маска /0 = любое значение всех 32-х битов в ИП. если под более точную маску из другого acl не попало (например 192.168.0.1 255.255.255.0 = 192.168.0.1/24), то в конце концов попадет сюда.> У меня через include подцепляются общие зоны как в view "internal", так
> и external.
> Или я ошибаюсь?
Коллеги, у меня в настройках BIND 9.6.-ESV-R5-P1 (FreeBSD 8.3-RELEASE-p3) следующие:acl internal_network { x.x.142.0/24; !any };
acl external_network { !x.x.142.0/24; any; };// x.x.142.0/24; - NAT, этим пользователям я могу выдавать RFC1918 записи.
view "internal" {
match-clients { internal_network; };
include "working/allviews.template.conf"; // тут у меня общие зоны и рутовые сервера//Обратные приватные зоны ну и т.д.
zone "222.7.10.in-addr.arpa" in {
type master;
};
zone "domain.com" in { // ответы для зоны могут отличаться в зависимости от SRCip, и я соответственно разделил их в разные view.
type master;
file "master/int/domain.com";
// skip
}// skip
}view "external" {
match-clients { external_network; };
include "working/allviews.template.conf";
zone "domain.com" in {
type master;
file "master/ext/domain.com";
}}
Из ответа участника форума с ником "DN" я сделал следующий вывод, что можно сделать общую зону common, т.е.
acl internal_network { x.x.142.0/24; !any };
acl external_network { !x.x.142.0/24; any; };
acl common_network { any; };
view "internal" {
match-clients { internal_network; };//Обратные приватные зоны ну и т.д.
zone "222.7.10.in-addr.arpa" in {
type master;
};
zone "domain.com" in {
type master;
file "master/int/domain.com";
// skip
}
}view "external" {
match-clients { external_network; };
zone "domain.com" in {
type master;
file "master/ext/domain.com";
}
}view "common" {
match-clients { common_network; };
include "working/allviews.template.conf";
}Иными словами я общие зоны как для "internal", так и для "external" выношу в "common" и со слов "DN" сначала SRCip попадает под ACL internal_network, далее не попадаем под ACL internal_network и снова попадаем под acl common_network.
У меня была уверенность в том, что попав под ACL internal_network последующие view уже не рассматриваются (подобно CISCO acl). Правда настраивал BIND я уже давно и по мере выхода обновлений конфигурационные файлы просто копировались. Может действительно в новых версиях поведение поиска в view изменилось и собственно из-за этого возник мой вопрос.
> Из ответа участника форума с ником "DN" я сделал следующий вывод, что
> можно сделать общую зону common, т.е.В документации BIND сказано, что разделение на view делается по
адресам клиентов или/и адресам BIND сервера, на которые поступает запрос.
Понятно, что полное множество адресов клиентов можно разделить на несколько
множеств, как пересекающиеся, так и нет, и т.д.
Each view statement defines a view of the DNS namespace that will be seen by a subset of clients.
http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.htm...Как Вы назовете эти view (common,external,internal,users1) - это дело десятое.
В match-clients { address_match_list }; важен порядок обработки списка.
http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.htm...> У меня была уверенность в том, что попав под ACL internal_network последующие
> view уже не рассматриваются (подобно CISCO acl). Правда настраивал BIND яЯ всегда делаю непересекающиеся множества в списках для различных view.
acl internal { 127.0.0.1; 192.168.0.0/24; };
acl others { ! "internal"; };Мне кажется, что попадание или не попадание клиента во view определяет только
порядком обработки списка для этого view. Если клиент попал в список для view,
то он будет обслужен только этим view. Если запрашиваемой зоны во view не
окажется, то положительного ответа от BIND не последует.
Не уверен, что клиент будет обслужен другим view, у которого есть запрашиваемая
зона и клиент тоже попадает в его список.Попробуйте или посмотрите исходники.
> уже давно и по мере выхода обновлений конфигурационные файлы просто копировались.
> Может действительно в новых версиях поведение поиска в view изменилось и
> собственно из-за этого возник мой вопрос.
>[оверквотинг удален]
>> Хм... Мне всегда казалось, что попав под первый view с match-clients (any),
>> последующие view не рассматриваются.
> тут порядок правил не важен.
> используется более точное совпадение ИП (по длине маски) во всех acl. any
> = маска /0 = любое значение всех 32-х битов в ИП.
> если под более точную маску из другого acl не попало (например
> 192.168.0.1 255.255.255.0 = 192.168.0.1/24), то в конце концов попадет сюда.
>> У меня через include подцепляются общие зоны как в view "internal", так
>> и external.
>> Или я ошибаюсь?Коллеги, Вы почему-то совсем игнорируете возможность указывать ! в acl. в применении > (больше) 2-х интерфейсов.
и к тому же даже с относительно старым биндом: man его:view string optional_class {
match-clients { address_match_element; ... };
match-destinations { address_match_element; ... };
match-recursive-only boolean;
key string {
algorithm string;
secret string;
};
итд
[root@local etc]# named -v
BIND 9.5.0-P2попадание во view не ограничивется только возможностями acl.
PS
это же не SQL-логика-с-NULL - это просто классические логические операции - простая булева алгебра.
> Есть DNS с несколькими файлами зон. Для одной из зон нужно чтобы
> во внутреннюю сеть отдавались внутренние адреса, а для внешних адресов -
> внешние.
> Делается это как я понял с помощью оператора view.
> Создаем два файла для одной зоны: один для внутренних адресов, другой для
> внешних. Создаем например view internal и view external и в
> каждом из них указываем соответствующие файлы для нужной зоны.
> А вот что касается других зон, по которым все остается без изменений,млять!!!! (простите за грубость модераторы)!
ты про дерективу include не слышал? почитай в man. воткни в файл все что не изменяется, include его в ллюбую зону, флаг те в руки и отстань если логику работы сервиса понять не можешь
> нужно ли их указывать в обоих view или нет?
> В книжке Крикета Ли и Пола Альбица "DNS и BIND" пишут: "если
> создан хотя бы один оператор view, все операторы zone должны быть
> явно включены в один из видов."
> Если мы явно включим все операторы zone например в view internal а
> в view external их не укажем, какие адреса будут отдаваться клиентам
> view external по этим зонам?
> Я так понимаю нужно перечислять все zone в обоих view. Или я
> ошибаюсь?PS
для себя считаю вопрос закрытым.