How does one configure BIND to communicate with the root serv ers?

Joe Kattner joe.kattner at adelphia.com
Thu Mar 28 19:25:20 UTC 2002


Brian,

DNS is a distributed database, but it is hierarchy that is delegated, rather
than working bi-directionally as you describe. The root name servers only
provide delegation (a referral) to name servers looking up information for a
particular domain. They do not hold the answers to those queries, only where
to ask next to get them. Your server does not provide the answers upward to
the root name server.

The registry populates the proper the TLD name server with the delegation to
the name servers for that zone. Through recursive queries, other name
servers then follow the chain of delegation for the actual answers, and they
cache the information themselves. The answers are cached by the name server
that is doing the query, based on TTL's specified in that zones
configuration. Note that this is an example, there may be many levels of
delegation to follow until an authoritative name server is found to provide
an answer.

e.g., someone wants to lookup www.body1.com, the clients resolver asks their
name server for www.body1.com. We'll assume it doesn't already have the
answer in it's cache, nor does it know anything about the com zone at this
point, so it must ask a root name server, which replies that it has no
knowledge of www.body1.com, but that it does know to ask a TLD server which
is authoritative for the com zone and provides the NS records for the com
server. It then uses those NS records and asks that name server for
www.body1.com. The TLD server responds that it has no knowledge of
www.body1.com, but that it does know to ask auth01.ns.harvard.net which is
authoritative for body1.com and provides the NS records. The name server
then asks auth01.ns.harvard.net for www.body1.com which responds that it can
be found at 64.55.93.6, and caches that information so the next time it is
asked, it will provide the answer itself (until the TTL expires).

That is the basic way it works, this is what it looks like in real life:

# dig www.body1.com +trace

; <<>> DiG 9.2.1rc1 <<>> www.body1.com +trace
;; global options:  printcmd
.                       325110  IN      NS      B.ROOT-SERVERS.NET.
.                       325110  IN      NS      C.ROOT-SERVERS.NET.
.                       325110  IN      NS      D.ROOT-SERVERS.NET.
.                       325110  IN      NS      E.ROOT-SERVERS.NET.
.                       325110  IN      NS      F.ROOT-SERVERS.NET.
.                       325110  IN      NS      G.ROOT-SERVERS.NET.
.                       325110  IN      NS      H.ROOT-SERVERS.NET.
.                       325110  IN      NS      I.ROOT-SERVERS.NET.
.                       325110  IN      NS      J.ROOT-SERVERS.NET.
.                       325110  IN      NS      K.ROOT-SERVERS.NET.
.                       325110  IN      NS      L.ROOT-SERVERS.NET.
.                       325110  IN      NS      M.ROOT-SERVERS.NET.
.                       325110  IN      NS      A.ROOT-SERVERS.NET.
;; Received 292 bytes from 24.48.58.222#53(24.48.58.222) in 7 ms

com.                    172800  IN      NS      A.GTLD-SERVERS.NET.
com.                    172800  IN      NS      G.GTLD-SERVERS.NET.
com.                    172800  IN      NS      H.GTLD-SERVERS.NET.
com.                    172800  IN      NS      C.GTLD-SERVERS.NET.
com.                    172800  IN      NS      I.GTLD-SERVERS.NET.
com.                    172800  IN      NS      B.GTLD-SERVERS.NET.
com.                    172800  IN      NS      D.GTLD-SERVERS.NET.
com.                    172800  IN      NS      L.GTLD-SERVERS.NET.
com.                    172800  IN      NS      F.GTLD-SERVERS.NET.
com.                    172800  IN      NS      J.GTLD-SERVERS.NET.
com.                    172800  IN      NS      K.GTLD-SERVERS.NET.
com.                    172800  IN      NS      E.GTLD-SERVERS.NET.
com.                    172800  IN      NS      M.GTLD-SERVERS.NET.
;; Received 463 bytes from 128.9.0.107#53(B.ROOT-SERVERS.NET) in 132 ms

body1.com.              172800  IN      NS      AUTH01.NS.HARVARD.NET.
body1.com.              172800  IN      NS      AUTH02.NS.HARVARD.NET.
;; Received 119 bytes from 192.5.6.30#53(A.GTLD-SERVERS.NET) in 42 ms

www.body1.com.          345600  IN      A       64.55.93.6
body1.com.              345600  IN      NS      auth01.ns.harvard.net.
body1.com.              345600  IN      NS      auth02.ns.harvard.net.
;; Received 135 bytes from 140.239.140.239#53(AUTH01.NS.HARVARD.NET) in 93
ms


Hope that helps you understand the process a little better. The O'Reilly DNS
and BIND book is an excellent reference for understanding the resolution
process, as well as the nuts and bolts of operation and maintenance of a
BIND name server.

--Joe

-----Original Message-----
From: Brian Guild [mailto:Brian at body1.com]
Sent: Thursday, March 28, 2002 1:08 PM
To: 'bind-users at isc.org'
Subject: How does one configure BIND to communicate with the root
servers?


Guys, 

We are setting up our own internal DNS for an upcoming project.  We are
using BIND.  I was wondering if one of your DNS gurus could answer one
question for me....

How does a given DNS server communicate its information to the root servers
at-large?  I figure it makes sense that my server should be passing its
information to other DNS servers around the world so that each time someone
requests my site, it doesn't have to check with my BIND server first....that
is, the information will be cached on other DNS servers out there.

Does BIND do this automatically based on the TTLs and expiry dates I set
within my zone files, or is there something else I have to configure within
named.conf to allow for updates to be passed to the root servers...

Also, if someone could clarify the process for changing DNS for my
particular website, I would much appreciate it.  The way I understand it now
is as follows:

1) Make the change at the Registry level (specify first, second, third DNS,
etc.)
2) Make sure the DNS server you specified at the Registry level has properly
configured zone files and make sure that DNS server is also propogating its
changes to the root servers.

Thanks, 

Brian 


Brian Guild
Network Manager
Body1, Inc.
Business: 617-576-9400
Fax: 617-576-9430
Body1, Inc.  "Where HealthCare and Technology Meet"
Preview "eForums" Online Meeting tools at: http://www.Body1.com/demo.cfm
<http://www.Body1.com/demo.cfm>  
Receive a free bimonthly health "e" letter:
http://www.body1.com/inside/index.cfm?action=2
<http://www.body1.com/inside/index.cfm?action=2>  
http://www.Body1.com <http://www.Body1.com>  
http://www.Wounds1.com <http://www.Wounds1.com>    
http://www.MedTech1.com <http://www.MedTech1.com>  
http://www.Veins1.com <http://www.Veins1.com>     
http://www.Knee1.com <http://www.Knee1.com>     
http://www.Shoulder1.com <http://www.Shoulder1.com>      
http://www.Doctors1.org <http://www.Doctors1.org>      
Body1, Inc.   
125 CambridgePark Drive 
Cambridge, MA 02140 USA



Brian Guild
Network Manager
Body1, Inc.
Business: 617-576-9400
Fax: 617-576-9430
Body1, Inc.  "Where HealthCare and Technology Meet"
Preview "eForums" Online Meeting tools at: http://www.Body1.com/demo.cfm
<http://www.Body1.com/demo.cfm>  
Receive a free bimonthly health "e" letter:
http://www.body1.com/inside/index.cfm?action=2
<http://www.body1.com/inside/index.cfm?action=2>  
http://www.Body1.com <http://www.Body1.com>  
http://www.Wounds1.com <http://www.Wounds1.com>    
http://www.MedTech1.com <http://www.MedTech1.com>  
http://www.Veins1.com <http://www.Veins1.com>     
http://www.Knee1.com <http://www.Knee1.com>     
http://www.Shoulder1.com <http://www.Shoulder1.com>      
http://www.Doctors1.org <http://www.Doctors1.org>      
Body1, Inc.   
125 CambridgePark Drive 
Cambridge, MA 02140 USA





More information about the bind-users mailing list