Re: does bind depends on system DNS settings for lookup?

[Chris Buxton]

Kevin,

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.

Regards,
Chris

> On Nov 19, 2015, at 1:11 PM, Darcy Kevin (FCA) <kevin.da...@fcagroup.com> 
> wrote:
> 
> Chris,
>   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:cli...@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 sett

RE: does bind depends on system DNS settings for lookup?

[Tony Finch]

Darcy Kevin (FCA)  wrote:

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

Please do, though be aware that the current rough draft is going to be
published as an RFC -
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg14628.html

The plan is to do a follow-up version as a second RFC, so your comments
will be helpful towards making the second version better.

My suggested clarifications to the recursive / iterative definitions
http://www.ietf.org/mail-archive/web/dnsop/current/msg14243.html
were rejected on the grounds that they should be considered for the
second RFC.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
North Utsire, South Utsire: Northerly 5 to 7, becoming cyclonic 4 at times.
Moderate or rough, occasionally very rough. Wintry showers. Good, occasionally
moderate.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: does bind depends on system DNS settings for lookup?

[Darcy Kevin (FCA)]

Chris,
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:cli...@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.da...@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.


Kevin,

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

Re: does bind depends on system DNS settings for lookup?

[Reindl Harald]

Am 18.11.2015 um 05:42 schrieb Dil Lee:

This is probably a dummy question.
My understand of bind in handling non-authoritative queries is:
1) forward mode. It just forward the client queries to an upstream DNS
server, which is defined in "forwarders" directive.
2) recursive mode. It actually start asking from root DNS server, then
2nd level DNS server etc till it finally get an authoritative answer
for the host in question.
Non of these modes seems to depends/relates to the system DNS settings
on the host which bind is running on, e.g. /etc/resolv.conf . AMIRITE?


no beause it would not make sense to do so when /etc/resolv.conf 
contains only 127.0.0.1 which is a common dns-cache setup on inbound 
mailservers




signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: does bind depends on system DNS settings for lookup?

[Darcy Kevin (FCA)]

"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. In order for recursive resolution 
to be successful, the "upstream" resolver must honor recursion for the client; 
it signals its willingness to do so by setting the RA flag in its responses to 
1.

The distinction between the two types of resolution is kind of like the 
difference between hiring people with specific skills (e.g. carpenter, plumber, 
electrician) to work on your house, where you have to do all of the work of 
identifying/locating them, giving them tasks, arranging payment, etc., versus 
hiring a general contractor and letting them take care of all the co-ordination 
and details.

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.

As for the difference between stub resolvers and forwarders; in 
protocol-architecture terms, there isn't any difference. They both generate 
recursive queries and rely on other recursion-honoring DNS nodes to resolve 
names for them. In *system* architecture terms, however, a stub resolver is 
only for the benefit of itself, whereas "forwarder" usually refers to a device, 
server or subsystem that provides DNS resolution to multiple clients. Again, 
the consumer/provider distinction comes into play. As a shared, scaled 
resource, forwarders are more likely to provide "value-add" services (such as 
DNSSEC validation), and to be implemented in a way that maximizes resilience 
and performance (e.g. running on Anycast addresses).

The previous paragraph should not be read as an *endorsement* of forwarding, 
however. Personally, I think forwarding is over-used and abused, and I prefer 
other methods of providing nameservice to clients, e.g. replication, iterative 
resolution, or, if necessary to work around broken delegations, "stub" zones. 
Forwarding should, in my opinion, only be used when one faces hard connectivity 
constraints that can't be accommodated any other way, e.g. needing to resolve 
Internet names, but within security policies and/or routing constraints which 
don't allow direct contact with Internet nameservers.

And don't even get me started on forwarding *chains*. Grrr...


- Kevin

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Reindl Harald
Sent: Wednesday, November 18, 2015 4:42 AM
To: bind-users@lists.isc.org
Subject: Re: does bind depends on system DNS settings for lookup?



Am 18.11.2015 um 05:42 schrieb Dil Lee:
> This is probably a dummy question.
> My understand of bind in handling non-authoritative queries is:
> 1) forward mode. It just forward the client queries to an upstream DNS 
> server, which is defined in "forwarders" directive.
> 2) recursive mode. It actually start asking from root DNS server, then 
> 2nd level DNS server etc till it finally get an authoritative answer 
> for the host in question.
> Non of these modes seems to depends/relates to the system DNS settings 
> on the host which bind is running on, e.g. /etc/resolv.conf . AMIRITE?

no beause it would not make sense to do so when /etc/resolv.conf contains only 
127.0.0.1 which is a common dns-cache setup on inbound mailservers

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: does bind depends on system DNS settings for lookup?

[Stuart Browne]

-Original Message-
> From: bind-users-boun...@lists.isc.org 
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Dil Lee
> Sent: Wednesday, 18 November 2015 3:42 PM
> To: bind-users@lists.isc.org
> Subject: does bind depends on system DNS settings for lookup?

> Hi,
> This is probably a dummy question.
> My understand of bind in handling non-authoritative queries is:
> 1) forward mode. It just forward the client queries to an upstream DNS
> server, which is defined in "forwarders" directive.

I don't think BIND forwards the request on at the packet level but proxies 
(creates a new request stuffing the question et al into the packet), but 
basically, yes.

> 2) recursive mode. It actually start asking from root DNS server, then
> 2nd level DNS server etc till it finally get an authoritative answer
> for the host in question.

This is correct.

> Non of these modes seems to depends/relates to the system DNS settings
> on the host which bind is running on, e.g. /etc/resolv.conf . AMIRITE?

What you are talking about here is a "Stub Resolver"; the OS has sufficient 
libraries to ask a name server for a result. It has no concept of forwarding or 
recursing, just "Give me an answer please!".

I believe any system that has an IP layer (and most likely others) has a stub 
resolver built into the core libraries. The stub resolver doesn't use BIND's 
libraries directly (thus no BIND needs to be installed to do DNS lookups as a 
client).

> Regards,
> Dil

Stuart
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users