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 <k...@chrysler.com>
To: bind-users@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?
?
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
