>>Как итог: лучше упорядоченное ведение обратной зоны, некий автомат по автогенерации
>>имен, как собственно у многих и сделано.
>
>lavr, спасибо.
>
>В общем ясно, но всё-же уточню... На опеннете я нашёл как сделать
>так, чтобы для внутренних и внешних запросов велись 2 РАЗНЫХ файла
>зон с именами машин. Внутренний файл - честный, а внешний -
>только то, что я пропишу. Неясно было только, что пожет заглючить,
>если во внешнем файле вообще сопоставления не будет для простых пользователей. bind9 - view для локальной сети и внешней, все как обычно
>Насколько я понял, кроме ns и mx в файле обратной зоны для
>тех, кто спрашивает снаружи, можно НИЧЕГО не прописывать (т.е даже фиктивные
>имена не нужны).
что есть фиктивные имена?
>А насчёт автогенерации прямой и обратной зоны для внутренних запросов - ну
подразумевалось - выделение ip клиенту/PC с генерацией в зонах DNS, например
диапазон PPP адресов, ну например ip=192.168.1.0-254 - ppp.192.168.0.1.domain
>так я DHCP к DNS наверное прикручу. Просто если оставлять у
>провайдера в таком дурацком виде, то я не смогу общаться в
>своей сети по именам с юниксовых машин...
>
>Просто файлов 4 штуки будет - 2 для внутренних запросов и 2
>для внешних, соответственно для прямого и обратного разрешения имён. Насчёт внутренних
>всё понятно было - их надо поддерживать. А вот надо ли
>поддерживать внешнюю пару файлов автоматически было не ясно.
что за внешняя пара?
Если МНЕ ДЕЛЕГИРОВАЛИ права например на 168.192.IN-ADDR.ARPA (только для примера
указана технологическая сеть):
- соответственно я ведущий и авторитарный для 168.192.in-addr.arpa
делаю КАК мне нужно, но чтобы ПРАВИЛЬНО работало
view "internal" {
match-clients { 192.168.100.0/24; реальная_сеть/маска; };
recursion yes;
// root for internal
zone "." {
...
};
// local 127.0.0.1
zone "0.0.127.in-addr.arpa" {
...
};
zone "168.192.IN-ADDR.ARPA" {
type master;
file "pri/192.168";
allow-update { none; };
allow-transfer { 192.168.100.0/24; };
// 192.168.100.6 - my secondary
notify-source 192.168.100.6;
};
zone "zhopa" {
...
file /path/zhopa.internal
};
};
// end of internal
// external
view "external" {
match-clients { any; };
allow-recursion { 192.168.0.0/16; реальная_сеть/маска; };
...
...
// root for external
zone "." {
...
};
zone "zhopa" {
...
file /path/zhopa.external
...
};
};
// end of external
если посмотрим зону zhopa - фиолетово прямая или обратная, данные берет из разных
файлов, в каждом view сделать ограничения видимости:
match-clients { сети; } для internal, сети = мои локальные и реальные
match-clients { any; } для external
для view internal - разрешить рекурсионные запросы: recursion yes;
для view external - запретить recursion yes;
в результате унутри локалки - будут видеть одно, извне - другое.
Можно к примеру использовать директиву include для подключения зон внутри view, например
view internal {
...
include "/path/internal-zone"
include "/path/common-zone"
};
view external {
...
...
include "/path/external-zone"
include "/path/common-zone"
};
в итоге в каждом view будут подгружаться два файла: c различающимися зонами и с зонами
общими для internal и external, если зона "zhopa" должна быть разной для internal
и external, значит она будет в двух вариантах(два файла)
http://www.cymru.com/Documents/secure-bind-template.html
PS. Во всем верхнем возможны апшипки, ачепятки, писано с листа
Вариант для распечатки
OpenNET: Виртуальная конференция (Public)
on 28-Июл-06, 18:21 
