Question About Terminology

[Chris Buxton]

You've got it backwards.

On Jul 26, 2006, at 8:27 PM, Merton Campbell Crockett wrote:

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

The query that the client sends to the resolving name server is a  
recursive query. The RD bit (recursion desired) is set.

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

Forwarding aside, queries sent by a resolving name server to  
authoritative name servers do not have the RD bit set, so they are  
iterative. Iterative queries are used to carry out recursion.

If you don't believe me, read RFC 1034 carefully. You'll find  
interesting information in sections 4 and 5.

Chris Buxton
Men & Mice

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