Basic DNS resolving theory

[Kevin Darcy]

Patrick Reany wrote:

> Do I have the correct model of DNS resolving?
>
> Host machine asks for DNS resolution.
> Host's resolver passes request to first DNS
> server (listed in its TCP/IP configuration), a local
> caching server. If it resolves then the IP address
> is returned, else, if it is a name server it passes
> the resolution on to a root server, which passes
> back to the resolver on the host the IP address
> of a top level domain server. The resolver then
> passes the request on to this server, which in
> turn passes back the address of an authoritative
> server. Then the resolver passes the request on to
> the authoritative server, which returns to the
> resolver the resolved IP address, assuming that
> such a resolution exists.
>
> If I got this chain of event and transfers
> right, what role does the name server
> play that the caching server does not?
>
> Am I right that on the enterprise LAN there
> are the
>      host resolvers,
>      caching servers, and
>      name servers;
> and on the Internet there are the
>      root servers,
>      top-level domain servers, and
>      authoritative servers?
>
> What is the analog of "authoritative server to zone,"
> and "name server to domain"?

Well, technically any software which resolves nameservice queries is a
"resolver". That term is often subdivided into "stub resolver" and
"full-service resolver". A stub resolver typically has no cache, and
just has a list of other resolvers to try, i.e. it's basically a
consumer of -- or, if you prefer, a parasite on -- the nameservice
infrastructure resources. The system resolvers of end-user devices are
typically configured as stub resolvers, with a further refinement being
the setting of the list-of-nameservers-to-try via DHCP. When you
configure BIND to do "forwarding", you're essentially demoting it to a
stub-resolver-plus-cache, where the "forwarders" list assumes the place
that the "nameservers" entries in an /etc/resolv.conf file (for
instance) would for a system-wide stub resolver.

A full-service resolver, however, basically follows the path you have
outlined, i.e. following referrals all of the way down from the root if
necessary. A full-service resolver also typically has a cache. The
importance of caching cannot be underestimated here: not only are
"leaf" nodes cached (i.e. the specific answers to the questions asked),
but also "branch" nodes (e.g. what the nameservers for "com" happen to
be). Because of this, it is relatively rare for a full-service resolver
to actually have to query the root servers or TLD servers. What
BIND implements, unless configured with "forwarding", is a full-service
resolver.


- Kevin