does bind depends on system DNS settings for lookup?
clists at buxtonfamily.us
Mon Nov 23 19:29:53 UTC 2015
I appreciate the thorough response. The usage you describe is somewhat at odds with the usage I’ve been using, which is why I asked the question.
One thing that seems to be confusing matters is the use of the word “resolver" in the text you quote, seeming to refer to the stub resolver in a client device. This makes it sound like a name server offering recursion is not a resolver, which is definitely counter to the usage in the RFCs and therefore wrong. I think this might stem from the usage in Cricket’s O’Reilly books; I used to work with Cricket, and had this debate with him, and he was unable to logically justify his usage. (Saying, “This is what’s in my book, and I’m not changing my book, so I must be right” does not form a logical argument.)
Anyway, I just want to have agreed-upon terminology. If my historical usage is deemed inaccurate or outmoded, I’m willing to adjust. To my thinking, we need solid definitions of the following items:
- Stub resolver
- Resolver (encompassing both a stub resolver and a recursive [or is it iterative?] resolver)
- Recursive name server (or is it iterative?) (because not all resolvers capable of recursion are name servers)
I have found when teaching this material that helping someone understand the distinctions also helps them understand DNS itself. Not having consistent usage, at least among those of us who know this stuff as well as you and I (and plenty of others on this list), leads to confusion among the neophytes.
I will be reading the IETF terminology draft closely. Thanks for pointing it out.
> On Nov 19, 2015, at 1:11 PM, Darcy Kevin (FCA) <kevin.darcy at fcagroup.com> wrote:
> The terms "iterative resolution" and "recursive resolution" appear to be in fairly common use, but they are not "classic" DNS lingo (e.g. don't appear in RFC 1034 or 1035, or any of the major RFCs which followed). RFC 4697, from 2006, is not a "major" DNS RFC, but it defined "iterative resolver" (as part of the composite term "iterative resolver component") via the text "the name server component of a recursive name server receives DNS queries and the iterative resolver component sends queries". That RFC also uses the term "recursive resolution algorithm", but, it appears, only as an umbrella term to include *both* the "name server component" and "iterative resolver component", in the previously-quoted text. So, it's not talking about the client, or the client/server interface, only the algorithm that the server side follows.
> The latest "terminology clarification" attempt (https://tools.ietf.org/html/draft-ietf-dnsop-dns-terminology-05) is informed by the iterative/recursive distinction, inasmuch as it defines the terms "recursive mode", "recursive resolver", "recursive server", "iterative mode" and "iterative resolver". But I think those definitions are still confusing, because they don't squarely address the provider/consumer distinction -- an entity which *provides* resolution for incoming RD=1 queries typically uses (on its *consumer* side) RD=0 queries to get the answer; so, is it "recursive" or "iterative" or *both*? RFC 4697's definition of an "iterative resolver" purely in *consumer* terms ("sends queries"), is distinguished in this new draft only in terms of the *provider* interface ("responds with a referral to another server"). Also, the attempt, in that draft, to clarify "recursive server" talks about it having a "name server side" and a "resolver side", but the term "name server" is never actually defined in the document (amazingly!). I think I'll raise these as problems with the draft.
> Although it may seem like an oversimplification, the easy way to understand and communicate this is that "iterative resolution" uses RD=0 queries and "recursive resolution" uses RD=1 queries. (Whether the resolution attempt is *successful* is another question, of course: sending an RD=1 query to a node that doesn't honor recursion is likely to result in failure, but it can still be said that the client *tried* to use "recursive resolution").
> - Kevin
> -----Original Message-----
> From: Chris Buxton [mailto:clists at buxtonfamily.us]
> Sent: Thursday, November 19, 2015 11:33 AM
> To: Darcy Kevin (FCA)
> Cc: BIND Users
> Subject: Re: does bind depends on system DNS settings for lookup?
> On Nov 18, 2015, at 3:50 PM, Darcy Kevin (FCA) <kevin.darcy at fcagroup.com> wrote:
>> "Iterative" resolution means following the delegation hierarchy (by sending queries with the RD flag set to 0) to get an answer; "recursive" resolution means sending a query off (with the RD flag set to 1) and relying on the other party to get a complete answer back to you.
>> The confusion comes in when it is stated that a DNS node provides "recursive service". What that means, is that, *as*a*provider*, the node receives and honors recursive queries from its clients, but *as*a*consumer*, it typically uses iterative resolution to get the answers. So it's essentially "recursive" on one side (queries come in with RD=1), "iterative" on the other (queries go out with RD=0). Once one understands the provider/consumer distinction, things become a lot clearer.
> Where do these definitions come from? I don’t use those words in quite those ways. I’ve thus far been unable to locate a definition of “recursive resolution” or “iterative resolution” in the RFCs.
> In the usage I’m used to, “iterative resolution” isn’t a thing; this phrase has no defined meaning to me. What you’re describing here is what I’ve been calling “recursive resolution”, or “recursion”.
> What you’re describing as “recursive resolution” is actually just a “recursive query” to my mind, a query asking for the server to perform the recursive algorithm (“RD” = “recursion desired”). Recursion, or recursive resolution, is the recursive algorithm that queries authoritative servers; each iteration of this algorithm involves sending an iterative query.
> I can find references in RFC 1034 to “recursive service”, which matches up with my usage of the phrase “recursive resolution". I can also find “recursion”, again matching my usage. The phrase “iterative service” in the RFC describes the way a server handles a query if recursion is either not available or not desired.
More information about the bind-users