> Assuming a case where there is an empty CNAME chain, but no
> error, [...]
...
> ;; ANSWER SECTION:
> www.apple.com. 281 IN CNAME www.isg-apple.com.akadns.net.
> www.isg-apple.com.akadns.net. 60 IN CNAME www.apple.com.edgekey.net.
> www.apple.com.edgekey.net. 17295 IN CNAME e3191.c.akamaiedge.net.
...
As a matter of terminology, in the quoted example, I see a chain
of three CNAME records. That's not what I would call an empty
CNAME chain.
What I do see, though, is a CNAME chain of three CNAME records,
but where the ultimate target of the CNAME chain exists, but does
not have any data of the requested type. Therefore, in the DNS
you get a NOERROR status code, and an answer section which does
not contain any records of the requested type.
Now...
> 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.
Between RFC 2553 and its follow-on RFC 3493, it appears that the
EAI_NODATA error code was deprecated. I've not been able to find out
why -- this change may have come from the POSIX side. I would have
thought that it would have been better to use that error code in this
case, since the name does exist, it just doesn't have any records of
the asked-for type(s). "Oh, well."
Best regards,
- Håvard
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
