Using DNS servers to query root servers from WAN

Wed Jul 1 23:36:07 UTC 2009

Well, first of all, do you really need views at all? If the namespace 
you use internally is *distinct* from what you present externally, e.g. 
example-internal.com versus example-external.com, then you may not need 
to use views at all. Just use allow-query to control who can query what, 
and allow-recursion to control who can recurse. Make sure you lock down 
who can access cached data though (you might need a relatively-modern 
version of BIND for fine-grained control of that, i.e. allow-query-cache).

But, assuming you need to use views at all, why do you think you need 
more than 2 views?

You need one view for the "trusted" clients. This view is allowed to 
recurse and needs a "hints" zone.

You need another view for the "untrusted" clients. This only serves 
authoritative data, so it doesn't recurse and the source of the root 
zone in that view is irrelevant (you could just not define it at all, in 
which case it'll default to the compiled-in version).

Where is the need for the third view? What value does it add?

For simplicity, I'd define the "trusted" view first, with match-clients 
set to the specific ranges you trust (which you can expand over time, of 
course). Then the "untrusted" view can be "match-clients { any; };" to 
catch anything not matched by the prior view.

                              - Kevin

samankaya at netscape.net wrote:
> Hmm.... many thanks Kevin for that!
>
> What I am trying to establish is something more like an ISP DNS server 
> set, of course they would probably be doing exactly what you suggested:
>
> "If you want to allow a *limited* set of clients on the other side of 
> your NAT to query Internet names, then add them to the "internal" 
> view. Optionally, change the name of the "internal" view to something 
> which more accurately reflects its intent, e.g. "trusted_ranges" or 
> whatever. "
>
> I don't know about the root dns servers themselves if they are 
> provisioned like this but really it's just an open end experiment in 
> my test lab.
>
> I did include the root "." zone in the external view before which 
> didn't work either so I guess if I can get that particular zone to 
> work with any public IP address then I can later create a 
> "trusted_wan" zone in which certain public IP addresses are accepted 
> for recursive lookup for root servers.
>
> For example if I added:
>
> zone "." {
> type hint; 
> file "/etc/opt/csw/bind/db.root"; 
> };
>
> to both external and internal views would that work??
>
> so if I did something more like this:
>
> acl internals { 
> 127.0.0.0/8;
> 192.168.0.0/22;
> }; 
> include "/etc/opt/csw/bind/named.conf.options"; 
>
> // View for internal clients 
>
> view "internal" { 
> match-clients { internals; }; 
> allow-recursion {  192.168.0.0/22;  127.0.0.1;  };
>
> // be authoritative for the localhost forward and reverse zones, and for 
> // broadcast zones as per RFC 1912 >
>
> zone "." {
> type hint; 
> file "/etc/opt/csw/bind/db.root"; 
> };
>
> zone "localhost" { 
> type master; 
> file "/etc/opt/csw/bind/db.local"; 
> };
>  
> zone "127.in-addr.arpa" { 
> type master; > // file "/etc/opt/csw/bind/db.127"; 
> };
>  
> zone "0.in-addr.arpa" { 
> type master; > // file "/etc/opt/csw/bind/db.0"; 
> };
>  
> zone "255.in-addr.arpa" { 
> type master;
> file "/etc/opt/csw/bind/db.255"; 
> }; 
>  
> include "/etc/opt/csw/bind/named.conf.local"; 
>
> };
>
> view "external" { 
> match-clients { any; !192.168.0.0/22; !127.0.0.1; }; 
> allow-recursion { 127.0.0.1;  };
> include "/etc/opt/csw/bind/named.conf.external";
>
> zone "." {
> type hint; 
> file "/etc/opt/csw/bind/db.root"; 
> };
>  
> };
>
> Then later I could build another view once my network grows over the 
> internet without taking into consideration VPN's for the moment:
>
> view "trusted_wan" {
> match-clients { IP1; IP2; !192.168.0.0/22; !127.0.0.1; }; 
> allow-recursion { 127.0.0.1;  };
> include "/etc/opt/csw/bind/named.conf.external";
>
> zone "." {
> type hint; 
> file "/etc/opt/csw/bind/db.root"; 
> };
>
> };
>
> and slot this view after the "internal" view! What do you think?
>
> Kaya
>
>
> -----Original Message-----
> From: Kevin Darcy <kcd at chrysler.com>
> To: bind-users at lists.isc.org
> Sent: Wed, Jul 1, 2009 2:23 am
> Subject: Re: Using DNS servers to query root servers from WAN
>
> The first view matched is the one which is selected. 
>  
> External clients are matching the "external" view, but they are not 
> allowed to recurse. Therefore they can only see the root zone and/or 
> whatever authoritative zones you've defined in that "include" file. 
>  
> Note that the "all" view is *never* matched, since everything will 
> have already matched "internal" or "external" before getting that far. 
>  
> The bigger security question is: why would you want arbitrary external 
> clients to be able to query arbitrary names through you? That makes 
> you an "open recursor" and ripe for cache poisoning, etc. 
>  
> If you want to allow a *limited* set of clients on the other side of 
> your NAT to query Internet names, then add them to the "internal" 
> view. Optionally, change the name of the "internal" view to something 
> which more accurately reflects its intent, e.g. "trusted_ranges" or 
> whatever. 
>  
>     - Kevin 
>  
>
>
> ------------------------------------------------------------------------
> *An Excellent Credit Score is 750. See Yours in Just 2 Easy Steps! 
> <http://pr.atwola.com/promoclk/100126575x1222377075x1201454393/aol?redir=http://www.freecreditreport.com/pm/default.aspx?sc=668072%26hmpgID=62%26bcd=JuneExcfooterNO62>* 
>