Using DNS servers to query root servers from WAN
Hi, this is my first post here and I have quite an interesting problem at that!
I have migrated my DNS service from Debian Etch Linux to Sun Solaris 9 running
the Blastwave version of Bind9.
This is a bit hard to explain but basically as default DNS setup in Debian, it
installs root servers in which domains for which the server is not
authoritative for get resolved. Currently the setup works fine from within my
LAN or intranet so? that any queries from 192.168.0.0/23 networks resolve
perfectly ok as they should for WAN queries.
My issue is that I cannot seem to do the same from the other side of my
gateway! The gateway is NAt'ed and I've directed ports 53 for both tcp and udp
connections to the IP of the DNS server.
I have had this working before I decided to use views but now with the views in
place something is blocking lookups for external sources. This is my current
named.conf file:
<--->
// This is the primary configuration file for the BIND DNS server named.
//?
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.???
//
// If you are just adding zones, please do that in
//etc/bind/named.conf.local???
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 "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";
// zone "com" { type delegation-only; };
// zone "net" { type delegation-only; };
};?
// View for external clients
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";
};
// Everyone can view root servers
view "all" {
??? match-clients { any; };
??? allow-recursion {?
??? 192.168.0.0/22;
??? 127.0.0.1;
//? any;??
??? };
??? 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";
??? };
};
//rndc security
?key "rndc-key" {
?? algorithm hmac-md5;
?? secret "XigPbSdF3oVRXPzax+96xA==";
?};
?controls {
?? inet 127.0.0.1 port 953
?? allow { 127.0.0.1; } keys { "rndc-key"; };
?};
<--->
I tried switching the internal zones to a generic 'all' view which can be seen
by everybody but it didn't seem to work and I also had a go at allowing
recursion for 'all' for the hinted zone too which again didn't do anything.
Can anybody help me in allowing external users to be allowed to lookup all URLs
via the hinted zone with the root.db servers file in it??
And at the same time
Re: Using DNS servers to query root servers from WAN
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
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?
?
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Using DNS servers to query root servers from WAN
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
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?
?
__
