Root Server Simulation Communication Problem

Ben Bridges bbridges at springnet.net
Thu Mar 26 14:20:08 UTC 2009


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-bounces at lists.isc.org
[mailto:bind-users-bounces at lists.isc.org] On Behalf Of T
MANIKANDAN-PKXR74
	Sent: Thursday, March 26, 2009 6:57 AM
	To: bind-users at 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:bbridges at springnet.net] 
	Sent: Tuesday, March 24, 2009 7:26 PM
	To: T MANIKANDAN-PKXR74; bind-users at 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-bounces at lists.isc.org
[mailto:bind-users-bounces at lists.isc.org] On Behalf Of T
MANIKANDAN-PKXR74
		Sent: Tuesday, March 24, 2009 12:52 AM
		To: bind-users at 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:bbridges at springnet.net] 
		Sent: Friday, March 20, 2009 8:35 PM
		To: T MANIKANDAN-PKXR74; bind-users at 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-bounces at lists.isc.org
[mailto:bind-users-bounces at lists.isc.org] On Behalf Of T
MANIKANDAN-PKXR74
		Sent: Friday, March 20, 2009 8:30 AM
		To: bind-users at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20090326/53fcfe71/attachment.html>


More information about the bind-users mailing list