On 04/28/2011 13:16, Chuck Swiger wrote:
On Apr 28, 2011, at 11:52 AM, Doug Barton wrote:
Agreed.  Akamai's EdgeSuite doesn't provide IPv6 AAAA records at
this time, but e3191.c.akamaiedge.net does have an A record.

I understand what you're saying, but I've always referred to such a
thing as an "empty CNAME chain" because it doesn't result in an
address record at the end.  Is there a more proper term for it?

RFC-1034 talks about CNAME chains:

"Of course, by the robustness principle, domain software should not
fail when presented with CNAME chains or loops; CNAME chains should
be followed and CNAME loops signalled as an error.

...and the recursive query algorithm:

"If recursive service is requested and available, the recursive
response to a query will be one of the following:

- The answer to the query, possibly preface by one or more CNAME RRs
that specify aliases encountered on the way to an answer.

- A name error indicating that the name does not exist.  This may
include CNAME RRs that indicate that the original query name was an
alias for a name which does not exist.

- A temporary error indication."

This phrase "name does not exist" appears to best be represented as
EAI_NONAME.

should getaddrinfo() return EAI_NONAME or EAI_FAIL?

RFC 3493 says:

[EAI_NONAME]    The name does not resolve for the supplied
parameters.  Neither nodename nor servname were supplied.  At
least one of these must be supplied.

[EAI_FAIL]      A non-recoverable error occurred when
attempting to resolve the name.

Which means that it should probably return EAI_NONAME; it's the
least bad error code among the ones listed in RFC 3493 for
getaddrinfo(), although one should not be mislead to think that
this means that the DNS said NXDOMAIN.

+1 to this analysis as well.

The original question that started me down the rabbit hole was,
"What error code should 'ping6 www.apple.com' return?"

Well, it appears that some other folks expect EAI_NONAME:

http://www.freebsd.org/cgi/query-pr.cgi?pr=156684

Yes, my discussion with Jared on another list was what prompted me to post here.

...and the MacOSX version of ping6 uses it for this case:

% ping6 www.apple.com ping6: getaddrinfo -- nodename nor servname
provided, or not known

What confuses me here is that the node does actually "exist" in the
sense that there is _an_ address record for it. So attempting to
look at this from the standpoint of a user, the error message I get
back (in our case, "hostname or servname not provided, or not
known") doesn't make any sense. (Although admittedly the "does not
resolve for the supplied parameters" part of the definition does
seem to.) Since for the purpose of ping6 no AAAA record at the end
of the chain is a non-recoverable error, _FAIL ("non-recoverable
failure in name resolution") seems to make more sense.

If the nameserver returned a failure (ie, NXDOMAIN, SERVFAIL), then I
would agree with EAI_FAIL.

However, it didn't fail; you just asked a question which it answered
successfully by providing all of the data which matched the query
type; ie, the CNAMES up to the end of the chain, but not including
the A record which terminates it, since you asked for an AAAA
instead.

Ok, I think that straightens it out for me. The deciding factor should be whether or not there is a name server error, is that right? If so that gives a nice clear, bright line.

Is it possible that what we need is a new error code to designate
"something exists here, just not what you asked for?" If _NONAME is
intended to indicate that it seems overloaded. Alternatively I
think we need to improve the language of our error messages. :-/

As Harvard mentioned, EAI_NODATA?  :-)

Well I was avoiding agreeing with him because I don't know why it was deprecated. :) Anyone here have an idea as to why it was?


Doug

--

        Nothin' ever doesn't change, but nothin' changes much.
                        -- OK Go

        Breadth of IT experience, and depth of knowledge in the DNS.
        Yours for the right price.  :)  http://SupersetSolutions.com/

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

Reply via email to