Empty CNAME chain, should getaddrinfo() return EAI_NONAME or EAI_FAIL?

[Doug Barton]

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/