bin/156684: getaddrinfo returns improper error

[Doug White]

The following reply was made to PR bin/156684; it has been noted by GNATS.

From: Doug White <dwhite at gumbysoft.com>
To: bug-followup at FreeBSD.org,
 jared at 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     =
 simon at 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.