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