a question on view [bind9]
per engelbrecht
per at xterm.dk
Tue Oct 18 10:27:19 UTC 2005
Kevin Darcy wrote:
> per engelbrecht wrote:
>
>
>>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.
>
>
> Thanks for the additional clarification, but I still think the root
> cause of your problem may be some NAT'ing you're unaware of, or that the
> source addresses aren't what you expect (e.g. if your "infrastructure
> servers" are multi-homed on multiple address ranges, and you're not
> using "query-source" to force the selection of a particular source
> address, queries may be originating from the "wrong" or perhaps
> accidentally the "right" address). I stick by my original recommendation
> to run a sniffer or at least use the query log as a diagnostic tool...
Hi Kevin
I've had 'query-source' on the ns2' different views as well and I do not
use NAT on the border router, but the next step will be tcpdump.
I'll let you know if I find anything.
Appresiate your input a lot.
/per
per at xterm.dk
>
>
> - Kevin
>
>
>
>
More information about the bind-users
mailing list