a question on view [bind9]

[per engelbrecht]

Brad Knowles wrote:
> At 11:59 AM +0200 2005-10-04, per engelbrecht wrote:
> 
>>  Note: "DNS and BIND" + "DNS & BIND Cookbook" both advertises the use of
>>  'recursion no;' for external view, while bind9arm uses 'allow-recursion
>>  { internals; externals; };' for external view.
>>  The 'externals' has an acl of 'any;' giving 'recursion yes;' ....
>>  However, if I use 'recursion no;' nothing works.
>>  "Well set it to yes then, stupid" you might think, but I don't like the
>>  idea of having recursion yes; for the public.
>>  Maybe I've read it wrong, but 'recursion no;' gives a non-working result
>>    no matter what.
> 
> 
>     You want recursion set to "no" for any IP address coming from 
> outside your network.  You want to be able to give them answers for the 
> domains you own, but nothing else.
> 
>     Recursion should be set to "yes" for all internal IP addresses, if 
> you're going to mix both functions on the same machine.
> 
> 
>     IMO, this is not safe, and you should at least run a totally 
> separate instance of BIND listening to the internal network (and 
> allowing recursion), with the other instance of BIND listening to the 
> external network (and not allowing recursion).  Or, run BIND on two 
> totally separate machines.
> 


Hi Brad and others
Sorry for the late response (almost a week ago) but here goes:

The recursion part is in place.
I run my setup on two seperate (public) nameservers [FreeBSD 4.11 / BIND 
9.2.3 / i386]

We have a /18 on which we run:
- a /20 for customers (dedicated serverhosting)
- a /24 for infrastructure servers
A few infrastructure servers are running on the /20 as well!!


Now I'm "adding" view.
The MASTER named.conf looks like this:


##################################################################

acl "ip" {
	127.0.0.1;
	<master_ip>;
};

acl "trusted" {
	127.0.0.1;
	<master_ip>;
	<slave_ip>;
	<a_few_remote_ip>;
};

acl "company" {
	127.0.0.1;
	<a_/24_net>;
	<a_few_ip_from_the_/20_net>;
	<a_few_remote_ip>;
};

// "company" incl. the masters (only) ip
// "company" incl. the slave second ip for the second view

acl "junk" {
	0/8;
	1/8;
	2/8;
	192.0.2/24;
	224/3;
	169.254/16;
	10/8;
	172.16/12;
	192.168/16;
	219.138.131/24;
};

// yes I know it's radical, but that part of CHINANET == trouble

options {
	directory "/etc/namedb";
	listen-on { ip; };
	version "Respect privacy please";
	blackhole { junk; };
	dump-file "dump";
	interface-interval 0;
	zone-statistics yes;
};

key "rndc-key" {
	algorithm hmac-md5;
	secret "xxxxxxxxxxxxxxxxxxxxx";
};

controls {
	inet * port 953
	allow { trusted; } keys { "rndc-key"; };
};

view "internal" {
	match-clients { company; };
	recursion yes;
	include "zone_internal";
};

view "external" {
	match-clients { any; };
	recursion no;
	include "zone_external";
};





<snip from zone_internal>
zone "." in {
	type hint;
	file "named.root";
};

zone "0.0.127.in-addr.arpa" in {
	type master;
	file "localhost.rev";
	allow-update { none; };
};

zone "aaaa.com" in {
	type master;
	file "master/a/aaaa.com.internal";
	allow-transfer { any; };
};

zone "xxx.xxx.xxx.in-addr.arpa" in {
	type master;
	file "master/x/xxx.xxx.xxx.rev.internal";
	allow-transfer { any; };
};
</snip from zone_internal>





<snip from zone_external>
zone "." in {
	type hint;
	file "named.root";
};

zone "0.0.127.in-addr.arpa" in {
	type master;
	file "localhost.rev";
	allow-update { none; };
};

zone "aaaa.com" in {
	type master;
	file "master/a/aaaa.com";
	allow-transfer { <slave_ip; };
};

zone "xxx.xxx.xxx.in-addr.arpa" in {
	type master;
	file "master/x/xxx.xxx.xxx.rev";
	allow-transfer { slave_ip; };
};
</snip from zone_external>

################################################################3

(setting the zone_external allow-transfer option to { none; }; does not 
change anyhthing)




THE PROBLEM IS:
- everybody listed in the acl "company" and anybody ourside our network, 
can resolve against the server correctly.
- customers on the /20 can not ... ?

also:
-comming from within the "company" range I can resolve PTR in the 
"internal" view but not A records from the same view ... ?

The files named $i.internal are placed in same directory structure / 
same directories as their $i counterpart (and are basicially just copies 
of $i with some changes of RR).



If you need further documentation from the SLAVE' setup, let me know. So 
fare I would like to solve the problem on the master.
As of now I've rolled back to the old non-view setup and everybody is 
happy, but I'm not.
If you can crack this on Brad (or others) it would mean the world to me. 
Thank you.

/per
per at xterm.dk