Question About Terminology

[Doug Barton]

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.

... and there is an interesting irony. :)

> 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.

That's an interesting line of thought.

> 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? 

In the FreeBSD development community "stub resolver" or usually just
"resolver" are the terms used to refer to the part of the puzzle that
resides on the operating system/device/etc. In my experience, this
terminology is pretty well accepted in other circles as well.

> 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. 

Here things get more muddy, since different people have different ways of
looking at this issue, mostly depending on what part of the world they are
seeing it from. I have always used the term "resolving name server" to
describe the piece of the puzzle that the stub resolver will communicate
with. My reason for doing so is that this terminology is reflective of
what's in the RFCs, and descriptive of the function. For this same reason I
have never liked the terms "caching" or "cache-only name server" because
they don't always fit the guidelines I mentioned above.

To make your job even more complicated, there is another term that I might
use depending on the circumstances, "recursive name server." When is a
resolving name server not recursive you ask? When it is configured to
forward-only. Thus if you are talking about the piece of the puzzle that is
doing the actual work of looking up an answer for a client, you can safely
use that term in all cases. If you are talking about the bit that the stub
resolvers talk to directly, that's not always possible.

In short, I hope I've demonstrated at least two things. First, you may not
get a "clean" answer to this question, since the question itself isn't
always straightforward. Second, correspondingly, it's worth possibly being
over-precise in your language to make sure your point is clearly understood.

hth,

Doug


-- 

	If you're never wrong, you're not trying hard enough