== DNS resolution cannot be segmented (and what I mean by that)

Many protocols involve some sort of namespace for resources. For
example, in DNS this is names to be resolved and in HTTP, this is
URLs (and distinct hosts). One of the questions you can ask about
such protocols is this:

> When a request enters a particular part of the namespace, can
> handling it ever require the server to go back outside that
> part of the namespace?

If the answer is 'no, handling the request can never escape', let's
say that the protocol can be *segmented*. You can divide the namespace
up into segments, have different segments handled by a different
servers, and each server only ever deals with its own area; it will
never have to reach over to part of the namespace that's really
handled by another server.

General DNS resolution for clients cannot be segmented this way,
even if you only consider the answers that have to be returned to
clients and ignore _NS_ records and associated issues. The culprit
is _CNAME_ records, which both jump to arbitrary bits of the DNS
namespace and force that information to be returned to clients.  In
a way, _CNAME_ records act similarly to symlinks in Unix filesystems.
The overall Unix filesystem is normally segmented (for example at
mount points), but symlinks escape that; they mean that looking at
_/a/b/c/d_ can actually wind up in _/x/y/z_.

(_NS_ records can force outside lookups but they don't have to
be returned to clients, so you can sort of pretend that their
information doesn't exist.)

Contrasting DNS with HTTP is interesting here. HTTP has redirects,
which are its equivalent of _CNAME_s and symlinks, but it still can
be segmented because it explicitly pushes responsibility for handling
the jump between segments all the way back to the original client.
It's as if resolving DNS servers just returned the _CNAME_ and left
it up to client libraries to issue a new DNS request for information
on the _CNAME_'s destination.

(HTTP servers can opt to handle some redirects internally, but even
then [[there are HTTP redirects which must be handled by the client
../web/DirectoryTrailingSlashes]]. Clients don't ever get to slack
on this, which means that servers can count on clients supporting
redirects. [[Well, usually ../web/FeedReadersAndRedirects]].)

I think this protocol design decision makes sense for DNS, especially
at the time that DNS was created, but I'm not going to try to justify
it here.