On Nov 26, 2008, at 11:49 AM, David Sparks wrote:
However, if you're concerned, it's pretty easy to set up a more
secure
infrastructure. Put a resolver (resolving name server) at the edge of
your network (in a DMZ, presumably) that knows nothing of internal
domains (nor IP address space). It refuses to send queries to private
addresses, but will answer queries coming from them. Then set up an
internal resolver that knows about your private namespace; for any
outside domains, it forwards to the server on the edge of your
network. Have client machines send queries to the internal resolver,
not to the edge resolver.
That will work but I was hoping for something like:
view "internet" {
filter-rfc1918-responses yes;
...
However I'm not concerned. :)
You can in fact set up the environment I described using views. Just
have the private view forward to the internet view. The following
resolving name server will ignore referrals to private name servers
for outside names; note that it's missing the masters list definition
named "private-auth-servers", plus the options statement, but is
otherwise complete.
acl "private" {
10/8;
172.16/12;
192.168/16;
# does not include 127/8
};
view "private" {
match-clients { private; };
# forward unknown names to the internet view:
forward only;
forwarders { 127.0.0.1; };
# stub, slave, or forward zones for the private namespace:
zone "private.zone" {
type stub;
masters { private-auth-servers; };
file "stub.private.zone";
forwarders { }; # disable forwarding for stub zones
};
};
view "internet" {
server 10/8 { bogus yes; };
server 172.16/12 { bogus yes; };
server 192.168/16 { bogus yes; };
allow-query { 127.0.0.1; };
};
Chris Buxton
Professional Services
Men & Mice
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
