a question on view [bind9]
per engelbrecht
per at xterm.dk
Tue Oct 11 14:17:50 UTC 2005
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
More information about the bind-users
mailing list