Mani,
That's a very general question, and I don't claim to be an expert on
all aspects of dns security, so hopefully those who are will chime in
on this point. I think most of those who are knowledge about dns
would probably recommend separating your authoritative and caching
servers, especially if you're a big dns shop hosting lots of domains,
but I'm not sure if that's for security reasons or for performance
reasons. If you're a small shop and host relatively few domains
and you want to present the same records for public domains to both
internal and external clients, then I personally don't see that it
would hurt to make one server both authoritative and caching from a
security standpoint. You'd want to be careful about allowing
recursion to only your internal clients, of course, and you'd want to
restrict access to private zones to only your internal clients (see
below). If you want to have public and private views of the same
zones (which is often the case), then it might be just as easy to have
separate authoritative and caching servers.
If you want your abc.com server to be purely authoritative, then
you'll want to restore your original "recursion=no" in the options.
You should also move the "10.168.192.in-addr.arpa" zone to your
caching server. That's private address space, so you don't want to
serve that data to internet hosts. (If you decide to make abc.com
both authoritative and caching, you'll want to add an "allow-query"
statement to that zone restricting it to only internal clients.)
For a caching server, the only zones you should need are the root
hints zone and any zones you may have for internal clients
(like "10.168.192.in-addr.arpa" and internal versions of other zones
like "abc.com"). You'd want "allow-query" and "allow-recursion"
statements in your global options restricting queries and recursion to
your internal clients. (I suppose you could use "recursion=yes"
instead of "allow-recursion { internal-clients; }", but
"allow-recursion" seems safer to me.)
Ben
------------------------------------------------------------------------
*From:* bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] *On Behalf Of *T
MANIKANDAN-PKXR74
*Sent:* Thursday, March 26, 2009 6:57 AM
*To:* bind-users@lists.isc.org
*Subject:* RE: Root Server Simulation Communication Problem
Ben,
In that case if I want an authoritative server and also a
caching name server, is it fine if I place both the
functionalities together as a best practice of implementation, how
about security issues ?,
If I want to introduce one more server for caching functionality
alone how will I separate both in two different servers what are
the changes I will be making in my abc.com server and what
configuration should be there for the new caching name server, so
that my clients can do a external query.
Regards
Mani
------------------------------------------------------------------------
*From:* Ben Bridges [mailto:bbrid...@springnet.net]
*Sent:* Tuesday, March 24, 2009 7:26 PM
*To:* T MANIKANDAN-PKXR74; bind-users@lists.isc.org
*Subject:* RE: Root Server Simulation Communication Problem
Mani,
With recursion enabled, your abc.com server is both authoritative
(for the zones configured in named.conf) and caching. If you want
it to be purely authoritative, you'll need to disable
recursion. But if you want to be able to query it for the root
server (which is why you started this thread), you're going to
have to allow recursion for at least your internal hosts because
the server is not authoritative for ".". Why are you wanting to
be able to query it for the root server? To want to be able
to query a purely authoritative server for something for which it
is not authoritative is a bit of a self-contradiction.
Ben
------------------------------------------------------------------------
*From:* bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] *On Behalf Of *T
MANIKANDAN-PKXR74
*Sent:* Tuesday, March 24, 2009 12:52 AM
*To:* bind-users@lists.isc.org
*Subject:* RE: Root Server Simulation Communication Problem
Hi Ben,
Thanks for reply now my root server (rootns.man) is responding
to abc.com. after enabling the recursion to Yes in abc.com
server, now my question is, Is my abc.com still called
authoritative Name server or a caching name server I was
intend to set up a authoritative name server, and hope by
enabling recursion iam still authoritative server.
Regards
Mani
------------------------------------------------------------------------
*From:* Ben Bridges [mailto:bbrid...@springnet.net]
*Sent:* Friday, March 20, 2009 8:35 PM
*To:* T MANIKANDAN-PKXR74; bind-users@lists.isc.org
*Subject:* RE: Root Server Simulation Communication Problem
You have recursion disabled on your abc.com server, and I
believe that is preventing your query from succeeding. My
understanding is that the contents of the root hints file are
not stored in the server's cache (which means, I think, that
they are not themselves returned in response to queries for
those records). Since you have recursion disabled on abc.com,
it is never using its root hints to query your root server
(rootns.man) for the NS and A records for the root zone (which
sounds obfuscated, but it is done that way because the root
servers themselves have the most current list of servers for
the root zone).
------------------------------------------------------------------------
*From:* bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] *On Behalf Of *T
MANIKANDAN-PKXR74
*Sent:* Friday, March 20, 2009 8:30 AM
*To:* bind-users@lists.isc.org
*Subject:* Root Server Simulation Communication Problem
Hi,
I am trying to set up lab which replicates the root
server also. ( DNS with Root server simulation for Intranet),
Basically I have two servers one abc.com as authoritative
server and the other rootns.man acting as root server.
running BIND 9 on both.
I have done the following things in my named.conf file
options {
directory "/var/named";
recursion no;
};
zone "." {
type hint;
file "root";
};
zone "abc.com" IN {
type master;
file "forward";
};
zone "10.168.192.in-addr.arpa" IN {
type master;
file "reverse";
};
*_My root File (Points to another DNS acting as Root
server let us call rootns.man)
_*
. 86400 IN NS rootns.man.
rootns.man. 86400 IN A 1.2.3.4
*_My Forward and reverse file
_*
$TTL 3600
@ IN SOA abc.com. root.abc.com. (
42 ; serial
3H ; refresh
15M ; retry
1W ; expiry
1D) ; minimum
IN NS abc.com.
abc.com. IN A 192.168.10.12
$TTL 3600
@ IN SOA abc.com. root.abc.com.(
42 ; serial
3H ; refresh
15M ; retry
1W ; expiry
1D) ; minimum
IN NS abc.com.
12 IN PTR abc.com.
*_In the other DNS server rootns.man (acting root server)
_*
zone "." IN {
type master;
file "forward";
};
*_Forward file in roons.man server
_*
$TTL 86400
@ IN SOA rootns.man root.rootns.man (
42 ;
serial (d. adams)
3H ;
refresh
15M ;
retry
1W ;
expiry
1D ) ;
minimum
. IN NS rootns.man.
rootns.man. IN A 1.2.3.4
*Once completing this I have a minor problem that is my
abc.com server is not able to determine the root server
(rootns.man) IP address. attached the DIG output from
abc.com server. can any one please help me in resolving
this issue.*
**
Regards
Mani
------------------------------------------------------------------------
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
