Help again please Fwd: please fix your broken DNS server

Kevin Miller kcmiller at
Sat Jul 9 05:28:18 CEST 2005

>>Thus we're getting an SOA for '' when we asked for a AAAA of
>> I suspect this is what's causing SERVFAIL's of every
>>server trying to track down the AAAAs, including the SERVFAILs from
>The respones looks correct to me - we asked for AAAA records for
> and the server said that there were 0 records
>of that type and points us at as being authorititive.
>AFAIK, that's a perfectly reasonable thing to do.
Caching resolvers that query for A records of will receive NS records pointing at, and will cache this. On subsequent queries for AAAA 
requests for, they will query lpitmd-ispX directly, 
and receive the SOA record with a label of This is 
inconsistent, as the NS records would indicate that 
should be a zone apex (and lpitmd should have the SOA for gwise, not 
giving us an SOA for I suspect this is what is causing the 
SERVFAILs to be generated (by the resolvers).

$ dig a

; <<>> DiG 9.2.4 <<>> a
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31628
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2

;            IN      A

;; ANSWER SECTION:     0       IN      A     0       IN      A

;; AUTHORITY SECTION:     60      IN      NS     60      IN      NS

It definitely seems like some sort of DNS load balancing is causing an 
inconsistent presentation of the service.

A dig +trace aaaa demonstrates this nicely. Note that 
+trace will fall back to an 'a' query when it doesn't get an answer for 
AAAA, as it does when querying


More information about the ipv6-ops mailing list