a question on view [bind9]

[Kevin Darcy]

per engelbrecht wrote:

>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.
>
Offhand, it seems like what you had should have worked. The only thing 
I'd throw into the discussion is to double-check that the source 
addresses you were getting were the same as what you expected to get -- 
with multi-homed hosts, load-balancers, NATs, etc., sometimes it's not 
as trivial as it used to be to verify what the source address of a given 
query should be. You could run a sniffer for further verification, or, 
if you're running BIND 9.3(.x), you could take advantage of its neat 
query-logging feature to see what view is being matched for each query...

                                                                         
                                                - Kevin