What qualfies a namespace?

Edward Lewis Ed.Lewis at neustar.biz
Fri Oct 20 13:34:12 UTC 2006


At 4:50 -0700 10/20/06, April wrote:
>Is a root a must have?
>
>Without a root, I may call a second level dormain (when there is a
>root) my top domain, is there anything wrong with it?

I love esoteric questions in the morning...they smell like, like, a 
whole day's worth of work.  (see 
http://news.bbc.co.uk/2/hi/entertainment/3362603.stm "I love the 
smell of napalm in the morning." ... "Smelled like... victory.")

A "name space" is a generic concept - a set of name and operators 
defining relationships among them.  But I don't think that is what 
you want to know.
(As said in "Airplane" - "But that's not important now.")

There are a few answers that do apply to your question.

When talking about the DNS protocol, which is basically a 
query/response, client/server protocol, when you ask a question, the 
answer you get back depends on how the server is configured.  If you 
ask a question that a server has the answer for, then hierarchy, 
i.e., having a root, is unimportant.

Then talking about the DNS as a system, having a root is a really 
good idea.  You can have a bunch of domains on a set of core servers 
without ever configuring a root zone.  It can work.  But maintaining 
such a configuration will be very expensive, and hard to train new 
staff to understand.

Each client (recurser, stub, resolver, call them what you want) needs 
a fall-back place to send queries when it doesn't know what to do. 
For a client that is willing to walk the tree (i.e., iterate), it 
wants to know where to begin - that is - where's the start or root in 
DNS terminology of the name space?

The servers listed could have a root zone (".") or they could all 
have a consistent set of other zones from which the name space can be 
walked down.  (The DNS name space is organized as a tree, name spaces 
in general need not be.)

Here's an example of why you want to have a root zone in DNS.  Let's 
say you have 5 core servers and you have 4 domains that folks want to 
get data from.  Let's say the domains are "red." "blue." 
"green.color." and "voip.sip.ietf."  Without a root zone, you have to 
have all four of these zones on all 5 servers.  Note that they don't 
all need to be "TLD" (one label), or that TLD can refer to any domain 
with no parent.

(TLD usually means a domain with one label, like "com.", "net.", 
"org.", but the issues surrounding them also apply to "co.uk.", 
"193.in-addr.arpa." and don't generally apply to arpa.)

Now you want to add "purple." as a new domain.  You have to configure 
"purple." on all 5 servers.  You would have to modify the 5 
named.conf's to carry "purple." everywhere.  This takes some time, 
and more importantly, if not done swiftly could cause some disruption 
as the change is rolled out.

Had there been a root zone on the 5 core machines, then you could set 
up servers for "purple." on any machines you want, the number being 
dependent on the need.  After testing that "purple." servers are up 
and running, you would then put the delegations into the root zone 
and use your zone propagation system (AXFR, rsync or something else) 
to send out updates.  This approach is smooth as you can first test 
the servers (for "purple.") and then in one command update the live 
root zone.  Propagation of the root zone, if designed well, will be 
fast, faster than manually ssh'ing into all the servers, updating 
named.conf (which you would also want to source control...) and 
reconfig'ing (you would not want to reboot the process) the servers. 
Imagine if you made a typo and the config failed.

DNS is designed to have a root zone.  It doesn't need one, but 
without it, the cost of operating a DNS system is higher than not. 
Note that I said "a root" zone.  There are non-technical debates over 
"the root" zone that is published by IANA/ICANN.  That's not a topic 
for this list.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Secrets of Success #107: Why arrive at 7am for the good parking space?
Come in at 11am while the early birds drive out to lunch.



More information about the bind-users mailing list