What qualfies a namespace?

[April]

Kevin Darcy wrote:
> 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

Agree with you on the two ... in addition, would it be benifitial for a
large and complex environment, to configure forwarders on the local
servers, to skip tree walking but directly go to the peer branches
directly? Of course in the case assumed not using slaves or stub zones.

Not sure about the "localized hints", do you mean using hints file but
listing in the file the servers you want the server to be referred to,
not the roots?