a question on view [bind9]

per engelbrecht per at xterm.dk
Wed Oct 12 00:20:57 UTC 2005


Kevin Darcy wrote:
> 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


Hi Kevin

(Your first comment is somewhat of a relief)

About src/dst:

           |               |
       carrier0        carrier1
           |               |
            \             /
           __\___________/__
          |                 |
          |    multihomed   |
          |     (our AS)    |
          |_________________|
              |         |
              |         |
             /20       /24
              |         |
            - ns2       |_______________
            - few own(*)                |
            - customers                 |
                                      - ns1
                                      - infrastructure servers


(*) few own = infrastructure servers on the /20
(I hope my ultra simple ascii diagram is readable and understadable)

'dig' is my tool and all queries are done against our ns1 server/master
.
I've attached a box on the /20 with an ip from the customers pool for 
testing.




INTERNAL VIEW ISSUES:
0 - I can resolve any public TLD's RR correctly from within our /24 
servers and /20 servers in same 'acl'

1 - I can resolve any of our own (usual) TLD's RR correctly from within 
our /24 servers and /20 servers in same 'acl'

2 - I can resolve any of our own TLD's new/ekstra PTR records correctly 
from within our /24 servers and /20 servers in same 'acl'

3 - I can NOT resolve any of our own TLD's new/ekstra A records 
correctly from within our /24 servers and /20 servers in same 'acl'



EXTERNAL VIEW ISSUES:
0 - customers from our /20 can NOT resolve anything.
Since not listed in the 'acl' giving access to "internal" view, they 
should be ranked alongside the public and should be guided towards the 
"external" view with the { any; }; clause, but they only recieve a list 
of root-servers on any give query.

1 - public queries (i.e. outside our /18) recieve a correct answer.


Thank you for joining in.

/per
per at xterm.dk


> 
> 
> 
> 



More information about the bind-users mailing list