a question on view [bind9]
Kevin Darcy
kcd at daimlerchrysler.com
Tue Oct 11 22:55:00 UTC 2005
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
More information about the bind-users
mailing list