Using DNS servers to query root servers from WAN

samankaya at netscape.net samankaya at netscape.net
Thu Jul 2 00:48:44 UTC 2009


 Many thanks again Kevin!

The reason I decided to use views in the first instance is that I wanted to separate clients who are in my local internal subnet and clients or are requesting information from the public internet.

Since I have defined the local subnet 192.168.0.0/23 currently for my wired and wireless networks I don't want them to see what is on the 'outside' of my NAT (my public IP address), and hence I used the same thinking behind the public internet that I didn't want them to see local information.

I two completely different database files for this reason, the internal which contains dns addresses for everything within the network including switches, routers, wireless access-points and print servers etc. These are all currently defined within the 192.168.1.0/24 range. 

The external view incorporates the WAN database file so everything is mapped to my public address. Since I only have one public address all my records whether it be A, MX, or PTR get mapped there, as I have internal mechanisms for distributing http, smtp and other information that usually requires separate public IP addresses.

This is the main reason why I'm using views. So my reasoning is that everybody internally sees 192.168.1.0/24 where all servers and other bits and pieces are in and everybody else sees the public information which is a highly cut down version of the internal one.

As stated before in my previous posting, my network will grow soon and without using VPN's I would like to be able to incorporate external sites. However I cannot put them onto the internal view otherwise they would see the 192.168.1.0/24 subnet and since they are coming in from outside won't be able to connect. But also I would like to have these external 'branches' of my network be able to resolve google.com and all other 'outside' based sites like I am able to do inside which is what the hinted zone containing the root servers allows me to do which means I would either need to put them onto the external view and use recursion for the trusted sites only. eg. if the public IP addresses of the remote sites were 1.1.1.1, 1.1.1.2 and 1.1.1.3 just to keep things simple then:


view "external" { 
match-clients { any; !192.168.0.0/22; !127.0.0.1; }; 
allow-recursion { 127.0.0.1;  1.1.1.1; 1.1.1.2; 1.1.1.3; };?


include "/etc/opt/csw/bind/named.conf.external";?


?


zone "." {?
type hint; 
file "/etc/opt/csw/bind/db.root"; };?


}; 


 
something like that??

I did actually play around with not having views before but then whenever I did any lookups from 'outside' my network I could see all the internal IP addresses as well which is not what I want at all!

I am sorry if what I am trying to achieve is not how it would be normally done professionally but the whole point that it is currently in a test lab environment is that I'm trying to learn about this so that I can make all my mistakes and not understand now so that later when I come to implement this properly I will know exactly what I'm doing!! Please do not think like I'm trying to waste your time or anything!!! I just want to identify how to approach a situation like this and implement it. It doesn't really help either that every environment that I will deal with will be NAT'ed so I have to take extra care with that also!

Regards,

Kaya


 

-----Original Message-----
From: Kevin Darcy <kcd at chrysler.com>
To: bind-users at lists.isc.org
Sent: Thu, Jul 2, 2009 2:36 am
Subject: Re: Using DNS servers to query root servers from WAN









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?
?


 



 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20090701/ec45acd0/attachment.html>


More information about the bind-users mailing list