named/AAAA/resolver not failing correctly with CNAME

[Eric Hodel]

Starting last week, AAAA queries for domains are not "failing" 
correctly when the domain being looked up is a CNAME for an A record.

Instead of getting back a response indicating there is no AAAA record, 
the resolver continues to look for a AAAA record until a timeout (a 
minute or so), where it then switches to looking for an A record, which 
is found immediately (as a CNAME).

I'm using named (8.3.7, default nameserver) on 4.11, and as far as I 
can tell haven't changed anything that would have caused this behavior.

If I switch resolv.conf to use the ISP's nameserver, I get a "correct" 
response, so the AAAA fails immediately and the resolver moves on to an 
A query, where it connects.

Nothing useful shows up in the named logs, and I'm at a loss of what I 
changed that causes this strange behavior.

To generate these requests, I simply do:

telnet www.43things.com 80

Connecting with a TCP Socket via Ruby does the same thing:

ruby -rsocket -e 'TCPSocket.open("www.43things.com", 80).close'

Note that www.43things.com is a CNAME for 43things.com:

$ host www.43things.com
www.43things.com is a nickname for 43things.com
43things.com has address 65.61.137.67
43things.com mail is handled (pri=10) by mail.43things.com

I have the same problem with, for example docs.freebsd.org but not 
www.freebsd.org.

The only thing I've changed on the nameserver is adding a few unrelated 
zones in named.conf, and an upgrade from 4.10 to 4.11-p2, then to 
4.11-p4.

Clients show the same behavior, the box running the nameserver, the 
rest of the 4.11-p2 machines, and OS X 10.3.9.  (OS X tries an A lookup 
first, then tries a AAAA lookup.  The AAAA has the same multiple 
request problem.)

I've tried both INET6 and INET6-less kernel with no effect (it was one 
of the things that has recently changed), and as far as I can tell, I 
can't disable AAAA lookups with the resolver in libc on 4.x.

Relevent uname/named version output for the machines at the bottom.

Here's a packet trace of the offending behavior.  RUR-1 and 
192.168.1.11 are the same machine.

Using the local nameserver:

11:40:22.970554 RUR-1.coop.robotcoop.com.2525 > 
RUR-5.coop.robotcoop.com.domain:  13450+ AAAA? www.43things.com. (34)
11:40:22.983842 RUR-5.coop.robotcoop.com.domain > 
RUR-1.coop.robotcoop.com.2525:  13450 0/0/0 (30)

... many times until finally:

11:41:38.256714 RUR-1.coop.robotcoop.com.4313 > 
RUR-5.coop.robotcoop.com.domain:  13451+ A? www.43things.com. (34)
11:41:38.257715 RUR-5.coop.robotcoop.com.domain > 
RUR-1.coop.robotcoop.com.4313:  13451 2/13/13 CNAME 43things.com., 
(483)

where the connection completes.

Same with docs.freebsd.org:

14:02:58.325712 RUR-1.coop.robotcoop.com.2264 > 
RUR-5.coop.robotcoop.com.domain:  29045+ AAAA? docs.freebsd.org. (34)
14:02:58.337935 RUR-5.coop.robotcoop.com.domain > 
RUR-1.coop.robotcoop.com.2264:  29045 0/0/0 (33)

...

14:04:13.392256 RUR-1.coop.robotcoop.com.4309 > 
RUR-5.coop.robotcoop.com.domain:  29046+ A? docs.freebsd.org. (34)
14:04:13.393296 RUR-5.coop.robotcoop.com.domain > 
RUR-1.coop.robotcoop.com.4309:  29046 2/13/13 CNAME www.freebsd.org., 
(487)

But with a domain that points to an A:

14:06:12.686424 RUR-1.coop.robotcoop.com.2833 > 
RUR-5.coop.robotcoop.com.domain:  61817+ AAAA? 43things.com. (30)
14:06:12.698061 RUR-5.coop.robotcoop.com.domain > 
RUR-1.coop.robotcoop.com.2833:  61817 0/0/0 (30)
14:06:12.698350 RUR-1.coop.robotcoop.com.gridgen-elmd > 
RUR-5.coop.robotcoop.com.domain:  61818+ A? 43things.com. (30)
14:06:12.699202 RUR-5.coop.robotcoop.com.domain > 
RUR-1.coop.robotcoop.com.gridgen-elmd:  61818 1/13/13 A 
www.43things.com (465)

Using our ISP's nameserver:

11:42:54.267003 192.168.1.11.3502 > dns.sea1.speakeasy.net.domain:  
210+ AAAA? www.43things.com. (34)
11:42:54.279814 dns.sea1.speakeasy.net.domain > 192.168.1.11.3502:  210 
1/0/0 CNAME 43things.com. (48)
11:42:54.279883 192.168.1.11.3096 > dns.sea1.speakeasy.net.domain:  
211+ A? www.43things.com. (34)
11:42:54.294253 dns.sea1.speakeasy.net.domain > 192.168.1.11.3096:  211 
2/0/0 CNAME 43things.com., (64)

and the connection completes immediately.

The client fails with both a kernel without INET6:

$ uname -a
FreeBSD RUR-1.coop.robotcoop.com 4.11-RELEASE-p2 FreeBSD 
4.11-RELEASE-p2 #3: Tue Apr 12 23:37:44 PDT 2005     
root at RUR-1.coop.robotcoop.com:/usr/obj/usr/src/sys/RUR  i386

and a kernel with INET6:

$ uname -a
FreeBSD RUR-1.coop.robotcoop.com 4.11-RELEASE-p4 FreeBSD 
4.11-RELEASE-p4 #4: Mon Apr 25 12:27:21 PDT 2005     
root at RUR-1.coop.robotcoop.com:/usr/obj/usr/src/sys/RUR  i386

The server running named is:

$ uname -a
FreeBSD RUR-5.coop.robotcoop.com 4.11-RELEASE-p4 FreeBSD 
4.11-RELEASE-p4 #2: Fri Apr 22 16:34:41 PDT 2005     
root at RUR-5.coop.robotcoop.com:/usr/obj/usr/src/sys/RUR  i386
$ named -v
named 8.3.7-REL Fri Apr 22 16:07:00 PDT 2005
         root at RUR-5.coop.robotcoop.com:/usr/obj/usr/src/usr.sbin/named

And it breaks even with an INET6 kernel:

$ uname -a
FreeBSD RUR-5.coop.robotcoop.com 4.11-RELEASE-p4 FreeBSD 
4.11-RELEASE-p4 #3: Mon Apr 25 12:44:36 PDT 2005     
root at RUR-5.coop.robotcoop.com:/usr/obj/usr/src/sys/RUR  i386

-- 
Eric Hodel - drbrain at segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E  7C11 332A 551C 796C 9F04