The following reply was made to PR bin/156684; it has been noted by GNATS. From: Doug White <dwh...@gumbysoft.com> To: bug-follo...@freebsd.org, ja...@puck.nether.net Cc: Subject: Re: bin/156684: getaddrinfo returns improper error Date: Wed, 27 Apr 2011 18:23:12 -0700
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 = si...@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. _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
