Question About Terminology

[Chris Buxton]

Thank you, Doug, that is exactly the kind of answer I wanted.

I've been thinking this problem over for years now (I'm no newbie in  
DNS, though I haven't spent much time on this list), and I even  
discussed it once with Cricket (back when he worked for us). His  
answer was unsatisfactory.

I agree that "caching-only name server" is too limited, since I want  
to be able to refer to a server's lookup role regardless of whether  
it is also an authoritative name server. And "recursive name server"  
or "recursion server" is too limited because of global forwarding -  
I'm trying to find etymology that will work for all of the name  
servers that receive recursive queries and react to them in ways that  
result in sending useful answers back to stub resolvers.

I am glad to have confirmed that "stub resolver" is acceptable use,  
though I am not at all surprised that "resolver" by itself is still  
used to refer to this component. Even with that, general acceptance  
of the phrase "stub resolver" suggests that "resolver" is  
sufficiently unspecific to allow for other types of resolvers. But  
I'm not convinced that use of the term "smart resolver", as we have  
been doing internally, is warranted.

Your use of "resolving name server" is a good blend of the terms  
"resolver" and "name server". This type of name server is not a  
"resolver", not quite fitting the use of that term in the RFC, and  
yet it fills part of the role originally seen as being mainly the  
purview of the resolver.

Are there others that agree with this usage? Or disagree?

Chris Buxton
Men & Mice

On Jul 26, 2006, at 3:42 PM, Doug Barton wrote:

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