Question About Terminology

[Chris Buxton]

In the discussion produced by my original query, I've had reason to  
reread parts of RFC 1034 that I haven't looked at in many years. I  
was surprised to find something approaching a final answer to my  
questions.

- Section 5.3.1 describes a stub resolver as a client-machine  
resolver library that is unable to do its own recursion, relying on a  
name server that is capable of recursion to find information.

- Section 4.3.1 says, "in this mode the name server acts in the role  
of a resolver and returns either an error or the answer, but never  
referrals."

So, what we have straight from the RFC is:

- stub resolver
- authoritative name server
- name server acting as a resolver

That last one is a bit unwieldy, though, so I'm still inclined to go  
with either "resolving name server" unless someone gives me a better  
alternative. "Resolver" by itself is too general; "smart resolver" is  
insufficiently descriptive, since it doesn't show what differentiates  
it from the general concept of a "resolver".

There is one other thing I found in the RFC, and that is a client  
resolver library that is not a stub, but rather is capable of doing  
its own recursion. I've seen such a beast, in one operating system  
(classic Mac OS, whether using the MacTCP stack or the Open Transport  
stack), but it certainly isn't common, nor usually desirable in  
today's world of patchwork quilts of public and private namespaces.  
It's better to consolidate the configuration into a central service.

(MacTCP DNR, which (again) was also used by Open Transport, would  
behave like a stub resolver, sending recursive queries, unless the  
name server it queried returned an iterative response, with the RA  
flag unset. In such case it would fall back on doing its own  
recursion, starting at the point suggested in the iterative response.  
This gave it more power and flexibility without sacrificing the  
ability to play nice in at least a simple combined public/private  
namespace.)

Chris Buxton
Men & Mice

On Jul 26, 2006, at 2:12 PM, Chris Buxton wrote:

> Greetings listers and news-groupies,
>
> This is a fairly long post, so if you're not interested, feel free to
> move on.
>
> I'm working on some reference material and I'm trying to describe the
> various software components that make up the functioning DNS we know
> and love. I'm having some trouble with names.
>
> In RFC's 1034 and 1035, Paul Mockapetris wrote about resolvers and
> name servers. But there are actually three different jobs the way
> things are usually implemented on the modern Internet:
>
> - The client library (+ optional caching service, e.g. DNS Client
> Service on Windows)
> - The authoritative name server, which hosts zones and answers
> iterative queries about them
> - The name server that performs recursion
>
> Mr. Mockapetris' almost 20-year-old RFC's describe recursion as
> mostly the job of the resolver, but it's a bit vague about exactly
> what the resolver is. It's pretty clear that the thing he meant has
> evolved into the library + optional caching service we see on client
> machines, but the words could be argued to apply nearly as well to a
> name server that performs recursion.
>
> My question really is, what do we call the third part of the puzzle,
> the go-between service that looks up names on behalf of client
> machines? Conceptually, it's a proxy, similar to a web proxy server
> or outbound SMTP server.
>
> For a long time, I and some of my colleagues have been calling it a
> "smart resolver". And we've been calling the client library a "stub
> resolver". But I want to know if this is common usage, or if common
> usage is still to refer to the client library as a "resolver"; in
> which case, again, what do we call the name server that performs
> recursion? I definitely don't want to just call it a name server,
> because an authoritative name server is also a name server. And yes,
> I know that both this job and authoritative name service can be done
> by the same process (e.g. named).
>
> I'm looking for a well-reasoned argument, based on the RFC's and on
> the actual meanings of words, to apply reasonable and differentiated
> names to the three components. Unless your name is Mockapetris, I'm
> not interested in an argument based on "because I said so".
>
> Chris Buxton
> Men & Mice
>
>
>