Re: Resolution differences for getaddrinfo versus host/dig/delv

2015-11-19 Thread Phil Mayers

On 18/11/15 21:26, Stephane Bortzmeyer wrote:

On Wed, Nov 18, 2015 at 12:19:57PM +,
  Phil Mayers  wrote
  a message of 44 lines which said:


I suspect getaddrinfo isn't parsing the DNS response for some reason.

...

Obviously the *.thing on the RHS of the first CNAME is weird, but is it
illegal?


Yes, for a *host* name (no for a *domain* name). See Tony Finch's
explanation.

In the GNU libc, the relevant code is in resolv/res_comp.c and
includes this function, which tests that a *host* name is
[a-z0-9\.\-]+ :


Thanks for the replies all; I guess the missing bit in my knowledge was 
that glibc and BSD libc apply the hostname-validity rules to CNAME 
targets (entirely reasonably).


FWIW, that hostname resolves OK on Windows (and as someone else noted, 
MacOS X) so here's hoping the lack of resolution never becomes an issue 
- given it "works" on "their" platform I don't see Microsoft being 
persuaded they're doing something wrong, based on past interactions with 
their 365 ops team :o/

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

2015-11-19 Thread Chris Buxton
On Nov 18, 2015, at 3:50 PM, Darcy Kevin (FCA)  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 phrase “iterative service” in the RFC describes 
the way a server handles a query if recursion is either not available or not 
desired.

Regards,
Chris
___
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?

2015-11-19 Thread 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)  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 phrase “iterative service” in the RFC describes 
the way a server handles a query if recursion is either not available or not 
desired.

Regards,
Chris
___
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