What qualfies a namespace?

[Kevin Darcy]

April wrote:
> Edward Lewis wrote:
>   
>> At 17:37 -0700 10/20/06, April wrote:
>>
>>     
>>> Thanks Edward for your time and efforts ...
>>>
>>> In the example, I think if we use forward, in addition to delegation,
>>> you can still get by, even without a root.
>>>       
>> You can always get by without a root.  A root is not required.
>>
>> If you are running a name server that is part of a larger system,
>> with someone else running a root zone, then there is no need to have
>> root on your machine.  In fact, you should not have a root zone on
>> your machine.
>>
>> If you are running the entire DNS system (name space for your
>> application), you can use forwarders and other mechanisms to avoid
>> having to have a root zone.  My caution is that setting up and
>> maintaining a system of forwarders and specially crafted root hints
>> files will prove to be complex and costly.
>>
>> But you can, and people do, succeed in running without a root zone.
>>
>>     
>>> In such a no root environment, do we still call it a namespace, or
>>> directly call the individual domains?
>>>       
>> You can call it a name space.  But what you call it does not matter
>> to the operations of DNS, the protocol and software is not concerned
>> with that name.  Ultimately, in DNS all that matters is the
>> arrangement of the domains because that is how data is referenced
>> (the QNAME).
>>
>>     
>>> Then if I only have son.father and grandson.son.father two domains, can
>>> I refer them to my top domain and my subdomain.  As I do not have a
>>> root, so I can care less about the absolute levels from the root, if it
>>> was there.
>>>       
>> Yes, you can do that.
>>
>> If you only have one server and two domains, then having no root can
>> be manageable.  What I said about "complex and costly" applies to
>> large DNS applications.  The cost and complexity of not having a root
>> zone scales (I'd bet) greater than linearly when you have an
>> increasing number of domains, servers, and organization (DNS
>> administrators) involved.
>>
>> --
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>> 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.
>>     
>
> Makes sense, thanks Edward!  With a root it does scale better, and
> forwarding is more suitable for smaller and simpler environments.
>   
I'm a fairly vocal critic/skeptic when it comes to forwarding.

Regardless of the size or complexity of one's environment, I only see 
forwarding as suitable in one of two situations: either a) in "forward 
only" mode, when you have to get around a connectivity problem of some 
sort (e.g. resolving Internet names even though arbitrary servers on the 
internal network are blocked by a firewall from querying Internet 
nameservers directly), or b) in "forward first" mode, for *provable*, 
*demonstrable* savings in query latency, when forwarding to some central 
cache. With respect to (b), a lot of people simply _assume_ that 
forwarding to a central cache will give a performance improvement. But 
the underlying assumption there is that the cache-hit ratio is high, an 
assumption that isn't always warranted. When the hit ratio is low, the 
latency incurred by the extra forwarding "hop" to the central cache 
often erases the advantage that a central cache offers. Plus oftentimes 
the owner/maintainer of the central cache doesn't provision enough 
capacity, so there can be answer delays simply because the box (or set 
of boxes), and/or the part of the network on which it/they reside, is 
overloaded by a lot of clients querying at once (i.e. query-volume spikes).

Lastly, even when a central cache benefits the *average* query latency, 
the extra hop can hurt the *worst-case* latency in some environments, 
and worst-case is oftentimes more important than average, because it can 
make the difference between an application timing out or not timing out. 
The portion of a transaction delay that is caused by a slow lookup is 
usually a fraction of the overall transaction time anyway, so why shave 
a few milliseconds from the average, if the cost of doing so is to run a 
significantly-higher risk of the whole transaction failing under 
worst-case conditions? Doesn't seem like a wise architecture choice to me.

For small, simple environments, you have other choices besides 
forwarding -- slave or stub zones, or just using a localized "hints" 
file. For that matter, with a sufficiently small/simple environment, you 
could even run a master root zone on every nameserver, with some sort of 
custom file-distribution-and-reload mechanism, if you wanted. There are 
certain things that are within reach of a small, simple environment, 
that frankly aren't feasible in our large, complex environments...

                                                                         
            - Kevin