BIND 9 AAAA record problems

[JINMEI Tatuya / 神明達哉]

>>>>> On Wed, 23 Jun 2004 14:36:34 -0500 (CDT), 
>>>>> <wbwither at bobball.uchicago.edu> said:

>> Caching should make the response quicker, not slower, but you might
>> want  to talk to your ISP to see if they are doing anything funky.

> Err, right.  I meant that maybe they were caching the old answer, or
> non-answer as the case may be?  I'm still getting some slow responses when
> I dig @ my ISP's DNS server, and some slow page-load times when I try to
> view the webpage from my Linux machine....
> bash-2.05b$ dig @216.167.161.35 efori.com IN AAAA

It seems to me that the caching server has a strange (unusual) state
about efori.com:

% dig @216.167.161.35 efori.com IN ns

; <<>> DiG 9.3.0beta4 <<>> @216.167.161.35 efori.com IN ns +norec
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58880
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;efori.com.			IN	NS

;; ANSWER SECTION:
efori.com.		140240	IN	NS	dns1.efori.com.

;; Query time: 193 msec
;; SERVER: 216.167.161.35#53(216.167.161.35)
;; WHEN: Thu Jun 24 11:22:56 2004
;; MSG SIZE  rcvd: 46

So, it doesn't have a glue for dns1.efori.com.  I guess that's
probably the reason why you cannot get a response to a query for AAAA
RR of efori.com.  The situation is so called the missing-glue status.
In this case, the caching server should fallback to resolution from an
upper zone (in the extreme case, from the root zone).  Then a gTLD
server will give the caching server the missing glue again, and you'll
get an appropriate response.

I know some implementations do not support the fall back mechanism.
At least it did not work well on a recent version of BIND9 caching
server (I forgot the detailed version - 9.2.3 is probably okay).

BTW: the configuration at the efori.com zone looks also odd.  While a
gtld server provides two NSs for the zone:

% dig @a.gtld-servers.net efori.com

; <<>> DiG 9.3.0beta4 <<>> @a.gtld-servers.net dns1.efori.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16501
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;dns1.efori.com.			IN	A

;; AUTHORITY SECTION:
efori.com.		172800	IN	NS	ns1.efori.com.
efori.com.		172800	IN	NS	ns2.efori.com.

;; ADDITIONAL SECTION:
ns1.efori.com.		172800	IN	A	65.182.78.133
ns2.efori.com.		172800	IN	A	65.182.78.134

ns1 and ns2 send inconsistent responses.  For example, ns1 insists
that there is only one NS for the zone:

% dig @65.182.78.133 efori.com ns +norec

; <<>> DiG 9.3.0beta4 <<>> @65.182.78.133 efori.com ns +norec
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36023
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;efori.com.			IN	NS

;; ANSWER SECTION:
efori.com.		345600	IN	NS	dns1.efori.com.

;; Query time: 183 msec
;; SERVER: 65.182.78.133#53(65.182.78.133)
;; WHEN: Thu Jun 24 11:32:58 2004
;; MSG SIZE  rcvd: 46

and it even returns NXDOMAIN for a query about dns1.efori.com:

% dig @65.182.78.133 dns1.efori.com ns +norec

; <<>> DiG 9.3.0beta4 <<>> @65.182.78.133 dns1.efori.com ns +norec
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28388
;; flags: qr aa ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;dns1.efori.com.			IN	NS

;; AUTHORITY SECTION:
efori.com.		345600	IN	SOA	dns1.efori.com. hostmaster.efori.com. 2004061701 86400 7200 3600000 345600