Question About Terminology

[Merton Campbell Crockett]

In your original message you referred to the name resolution process  
on the client system as recursive.  It's function is to formulate  
queries to send to a name server.  This is an iterative rather than  
recursive process.  The name resolution process uses irs.conf,  
nsswitch.conf, and resolv.conf to select which name services (WINS,  
NFS/NIS, DNS) to use and the order in which the name services should  
be used to query for the name.

For each iterative query from the client, the DNS name server will  
query its cache for the answer and then, unless artificially  
restricted, recursively query other DNS name servers to resolve the  
iterative query from the client.  "Forward only;" and "recursion  
none;" would be examples of options that artificially restrict normal  
operation of the name server.

Obviously, I'm ignoring how the name server populates its cache, i.e.  
is it populated by loading a local zone file, transferring a zone  
from another name server, or by answering queries from clients.

Merton Campbell Crockett






On 26 Jul 2006, at 17:03 , Chris Buxton wrote:

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

Merton Campbell Crockett
m.c.crockett at adelphia.net