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
CNAME records, which both jump to arbitrary bits of the DNS
namespace and force that information to be returned to clients. In
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
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
CNAMEs 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
(HTTP servers can opt to handle some redirects internally, but even then there are HTTP redirects which must be handled by the client. Clients don't ever get to slack on this, which means that servers can count on clients supporting redirects. Well, usually.)
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.