Hello Jared, Thanks for your bug report. It appears the resolver makes a distinction between a record resolves to = a CNAME that points to another record that does not have a AAAA entry, = versus a record that has no AAAA or CNAME at all. This behavior is = consistent with A records as well. To test this, I created these RRs in gumbysoft.com (these are real so = you can test this as well): aaaatest AAAA 2001:4f8:fff6::22 cnametoaaaa CNAME ipv6 cnametononaaaa CNAME carver The IPv6 address is the same as www.freebsd.org so it should respond to = pings. carver is my machine that is IPv4-only. (Note to old bugbase = readers: These records are subject to change without notice to this = bug.) I am going to test from freefall.freebsd.org, which is dual stack, = running a recent FreeBSD 8-STABLE build. FreeBSD freefall.freebsd.org 8.2-STABLE FreeBSD 8.2-STABLE #4 r220774: = Mon Apr 18 13:56:14 UTC 2011 = simon@freefall.freebsd.org:/usr/obj/usr/src/sys/FREEFALL i386 'ping6 aaaatest.gumbysoft.com' and 'ping6 cnametoaaaa.gumbysoft.com' = resolve successfully, but 'ping6 cnametononaaaa.gumbysoft.com', a = dangling CNAME, fails: freefall,pts/9,~,36>ping6 cnametononaaaa.gumbysoft.com ping6: Non-recoverable failure in name resolution and names with no AAAA or simply nonexistent names return: freefall,pts/9,~,37>ping6 blabla.gumbysoft.com ping6: hostname nor servname provided, or not known freefall,pts/9,~,14>ping6 carver.gumbysoft.com ping6: hostname nor servname provided, or not known By comparison, on A records, where cnametoaaaa does not point to an = existent A entry (using telnet -4 so it uses getaddrinfo()): freefall,pts/9,~,42>telnet -4 blabla.gumbysoft.com blabla.gumbysoft.com: hostname nor servname provided, or not known freefall,pts/9,~,43>telnet -4 cnametoaaaa.gumbysoft.com cnametoaaaa.gumbysoft.com: Non-recoverable failure in name resolution Research into the issue seems to come down to a philosophical argument = as to whether to report "danging" CNAMEs as a separate problem from = simply nonexistent records.=20 At this point, though, the reported issue is simply not a bug; an error = is returned on an attempt to resolve an unresolvable address/type = combination. Which error is reported is dependent on the precise failure = mode, but the result is the same: failure to resolve the requested name = to an address.
I hate to disagree with my esteemed colleague, :) however I think in the case where the name server does not return an error (such as servfail or nxdomain) the proper response for getaddrinfo() is EAI_NONAME. The thread at https://lists.isc.org/pipermail/bind-users/2011-April/083542.html has a good discussion about why. 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/
Is this slated for fix in 9.0?
A commit references this bug: Author: ume Date: Mon Dec 21 11:24:14 UTC 2015 New revision: 292539 URL: https://svnweb.freebsd.org/changeset/base/292539 Log: If we end up following a CNAME chain that does not find any data return that instead of internal error. PR: 156684 Obtained from: NetBSD MFC after: 1 week Changes: head/lib/libc/net/getaddrinfo.c
Thank you for your report. I've committed the fix into HEAD. I'll do MFC it after 1 week.
A commit references this bug: Author: ume Date: Mon Dec 28 03:26:16 UTC 2015 New revision: 292824 URL: https://svnweb.freebsd.org/changeset/base/292824 Log: MFC r292539: If we end up following a CNAME chain that does not find any data return that instead of internal error. PR: 156684 Changes: _U stable/10/ stable/10/lib/libc/net/getaddrinfo.c
A commit references this bug: Author: ume Date: Mon Dec 28 03:27:51 UTC 2015 New revision: 292825 URL: https://svnweb.freebsd.org/changeset/base/292825 Log: MFC r292539: If we end up following a CNAME chain that does not find any data return that instead of internal error. PR: 156684 Changes: _U stable/9/lib/libc/ stable/9/lib/libc/net/getaddrinfo.c