Occasional SERVFAILs from "dig NS iq."

[Chris Thompson]

I have noticed that I get occasional (fast) SERVFAIL responses from
"dig NS iq.", e.g.

$ dig ns iq.

; <<>> DiG 9.9.4 <<>> ns iq.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7919
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;iq.                            IN      NS

;; Query time: 413 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Sep 24 15:06:55 BST 2013
;; MSG SIZE  rcvd: 31

but that trying again immediately gives the right result:

$ dig ns iq.

; <<>> DiG 9.9.4 <<>> ns iq.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60361
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;iq.                            IN      NS

;; ANSWER SECTION:
iq.                     86400   IN      NS      nsp-anycast.cmc.iq.
iq.                     86400   IN      NS      sns-pb.isc.org.
iq.                     86400   IN      NS      ns1.cmc.iq.
iq.                     86400   IN      NS      iq.dns.cocca.org.nz.

;; ADDITIONAL SECTION:
iq.dns.cocca.org.nz.    172798  IN      A       203.119.84.235
ns1.cmc.iq.             172798  IN      A       194.117.57.100
sns-pb.isc.org.         74136   IN      A       192.5.4.1
sns-pb.isc.org.         74136   IN      AAAA    2001:500:2e::1
nsp-anycast.cmc.iq.     172798  IN      A       194.117.58.42
nsp-anycast.cmc.iq.     172798  IN      AAAA    2001:500:14:8001:ad::42

;; Query time: 33 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Sep 24 15:06:57 BST 2013
;; MSG SIZE  rcvd: 260

The nameserver at 127.0.0.1 is running BIND 9.9.4 (the same effect was
observed with beta and rc versions earlier, and I can provoke it with
9.9.3-P2 on another server as well).

"iq" is partially signed, in the sense that some of its nameservers
deliver a signed version, and some an unsigned one, but I don't see
how that leads to the effect observed.

-- 
Chris Thompson
Email: cet1 at cam.ac.uk