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