forwarding algorithm and timeouts

Kevin Darcy kcd at
Wed Mar 28 01:46:26 UTC 2001

Brad Knowles wrote:

> At 7:03 PM -0500 3/27/01, Kevin Darcy wrote:
> >  Well, *technically* the term "resolver" covers any software program
> >  or component which acts as a client to extract DNS information.
>         I see.  You're going to force me to quote.  Very well.  From
> <> (reformatted slightly
> for readability):
> 1. Introduction
> The Berkeley Internet Name Domain (BIND) implements an Internet name server for
> BSD-derived operating systems.  The BIND consists of a server (or ``daemon'')
> called named and a resolver library.  A name server is a network service that
> enables clients to name resources or objects and share this information with
> other objects in the network.  This in effect is a distributed data base system
> for objects in a computer network.  The BIND server runs in the background,
> servicing queries on a well known network port.  The standard port for UDP and
> TCP is specified in /etc/services.  The resolver is a set of routines
> residing in
> a system library that provides the interface that programs can use to
> access the
> domain name services.
>         Admittedly, this is a bit old, but it's the most official
> documentation I can find under <>, and
> at least the terms that it defines almost certainly haven't changed
> since the BIND 4.9.x days.

Um, Brad, are you aware that many of the resolver routines are *linked*into* the
"named" program, e.g. res_ninit(), res_nmkquery(), res_nameinquery(), etc.? So
nothing you quote above contradicts my claim that there is a resolver embedded in
"named" (although admittedly, the *forwarding* mechanism of "named", in
particular, doesn't simply punt to resolver-library routines; it uses its own,
specially-crafted code instead).

But even if that were not true, even if not one machine instruction from
resolver-library code was linked into "named", just because the BIND blurb says
that "The resolver" (meaning the part of BIND which is officially designated as
"the resolver") is a set of library routines, doesn't change the underlying
reality that some of the code in "named" *functions* as a resolver, according to
the accepted definitions of that term used in RFC's and elsewhere. If it walks
like a duck, and quacks like a duck, it's a duck.

(To tell the truth, I think someone just forgot to put the word "library" after
"The resolver" in the sentence in question. It reads more sensibly that way, since
earlier in the paragraph BIND was described as consisting of "a server (or
'daemon') called named and a resolver library".)

(I also find the phrase "A name server is a network service ..." laughably
imprecise. A server may *offer* or *provide* or *implement* a service, but it *is*
not a service, in and of itself, since the very term "service" implies not only
someone or something doing the serving, but also someone or something being
served. Perhaps it should have been worded "DNS is a network service ...").

For a more authoritative (and coherent) definition of "resolver", see RFC 1034:

> RESOLVERS are programs that extract information from name
>      servers in response to client requests.  Resolvers must be
>      able to access at least one name server and use that name
>      server's information to answer a query directly, or pursue the
>      query using referrals to other name servers.  A resolver will
>      typically be a system routine that is directly accessible to
>      user programs; hence no protocol is necessary between the
>      resolver and the user program.
Note that the resolver embedded in "named" is not the "typical" case mentioned
above (apparently PVM considered OS-integrated stub resolvers more "typical" than
nameserver-embedded resolvers). Nevertheless, it was quite clearly anticipated
that resolvers (or resolver code/algorithms) would be embedded in nameserver
programs. See, for example, Step 5 of the nameserver query-resolution algorithm
(RFC 1034 Section 4.3.2): "Using [sic] the local resolver or a copy of its
algorithm (see resolver section of this memo) to answer the query".

- Kevin

More information about the bind-users mailing list