named/AAAA/resolver not failing correctly with CNAME

Eric Hodel eric at
Mon Apr 25 14:09:32 PDT 2005

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 80

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

ruby -rsocket -e '"", 80).close'

Note that is a CNAME for

$ host is a nickname for has address mail is handled (pri=10) by

I have the same problem with, for example but not

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 

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 are the same machine.

Using the local nameserver:

11:40:22.970554 >  13450+ AAAA? (34)
11:40:22.983842 >  13450 0/0/0 (30)

... many times until finally:

11:41:38.256714 >  13451+ A? (34)
11:41:38.257715 >  13451 2/13/13 CNAME, 

where the connection completes.

Same with

14:02:58.325712 >  29045+ AAAA? (34)
14:02:58.337935 >  29045 0/0/0 (33)


14:04:13.392256 >  29046+ A? (34)
14:04:13.393296 >  29046 2/13/13 CNAME, 

But with a domain that points to an A:

14:06:12.686424 >  61817+ AAAA? (30)
14:06:12.698061 >  61817 0/0/0 (30)
14:06:12.698350 >  61818+ A? (30)
14:06:12.699202 >  61818 1/13/13 A (465)

Using our ISP's nameserver:

11:42:54.267003 >  
210+ AAAA? (34)
11:42:54.279814 >  210 
1/0/0 CNAME (48)
11:42:54.279883 >  
211+ A? (34)
11:42:54.294253 >  211 
2/0/0 CNAME, (64)

and the connection completes immediately.

The client fails with both a kernel without INET6:

$ uname -a
FreeBSD 4.11-RELEASE-p2 FreeBSD 
4.11-RELEASE-p2 #3: Tue Apr 12 23:37:44 PDT 2005     
root at  i386

and a kernel with INET6:

$ uname -a
FreeBSD 4.11-RELEASE-p4 FreeBSD 
4.11-RELEASE-p4 #4: Mon Apr 25 12:27:21 PDT 2005     
root at  i386

The server running named is:

$ uname -a
FreeBSD 4.11-RELEASE-p4 FreeBSD 
4.11-RELEASE-p4 #2: Fri Apr 22 16:34:41 PDT 2005     
root at  i386
$ named -v
named 8.3.7-REL Fri Apr 22 16:07:00 PDT 2005
         root at

And it breaks even with an INET6 kernel:

$ uname -a
FreeBSD 4.11-RELEASE-p4 FreeBSD 
4.11-RELEASE-p4 #3: Mon Apr 25 12:44:36 PDT 2005     
root at  i386

Eric Hodel - drbrain at -
FEC2 57F1 D465 EB15 5D6E  7C11 332A 551C 796C 9F04

More information about the freebsd-questions mailing list