IP6.ARPA timeouts

[sdgathman]

RDNS queries timeout, unless the NS name is cached.   Then they timeout again after "rndc flush" or TTL expires.  What is going on?  Bind version for client and server is 9.8.2.

[root@cms0 ~]# dig -x 2001:470:8:488::82

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> -x 2001:470:8:488::82
;; global options: +cmd
;; connection timed out; no servers could be reached
[root@cms0 ~]# host ns1.bmsi.com
ns1.bmsi.com has address 68.106.146.44
ns1.bmsi.com has IPv6 address 2001:470:8:488::81
[root@cms0 ~]# dig -x 2001:470:8:488::82

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> -x 2001:470:8:488::82
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38302
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; QUESTION SECTION:
;2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.8.4.0.8.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa. IN PTR

;; ANSWER SECTION:
2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.8.4.0.8.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa. 14400IN PTR spidey2.bmsi.com.

;; AUTHORITY SECTION:
8.8.4.0.8.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa. 4857 IN NS ns1.bmsi.com.

;; ADDITIONAL SECTION:
ns1.bmsi.com.      3596   IN   A   68.106.146.44
ns1.bmsi.com.      3596   IN   AAAA   2001:470:8:488::81

;; Query time: 1484 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri May 17 10:10:48 2013
;; MSG SIZE  rcvd: 182

[root@cms0 ~]# rndc flush
[root@cms0 ~]# dig -x 2001:470:8:488::82

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> -x 2001:470:8:488::82
;; global options: +cmd
;; connection timed out; no servers could be reached
[root@cms0 ~]#

[kasperd]

A packet dump of the traffic between your DNS server and the authoritative servers would make it much easier to figure out, what is going on.

[sdgathman]

When ns1.bmsi.com is not in cache, there is *no* traffic to ns1.bmsi.com.  Once it is in cache (via "host ns1.bmsi.com"), the traffic is normal:

10:50:38.096107 IP6 2001:470:39:119::2.62578 > 2001:470:8:488::81.domain: 3687% [1au] PTR? 2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.8.4.0.8.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa. (101)
10:50:38.174801 IP6 2001:470:8:488::81.domain > 2001:470:39:119::2.62578: 3687*- 1/1/3 PTR spidey2.bmsi.com. (193)

[removed previous post of tcpdump without -n, which was confused by tcpdump itself looking up IPs]

[kasperd]

When ns1.bmsi.com is not in cache, there is *no* traffic to ns1.bmsi.com.

You need to look at all the DNS traffic from your server, not just what is going to that one specific server.

[kasperd]

The gtld servers have outdated glue records for ns1.bmsi.com. The reason you can lookup ns1.bmsi.com by itself is that bmsi.com has two other NS records with functional glue.

The reverse lookups encounter an entry with only a single NS record pointing at ns1.bmsi.com. Once it starts resolving that, it will eventually get the outdated glue records for ns1.bmsi.com. It is quite likely your resolver doesn't consider the other two glue records, since it already knows it needs to use the one for ns1.bmsi.com.

[sdgathman]

Interesting, I updated the registrar a month ago, noticed it didn't get to gtld, they said "it takes a few days".  I forgot to check on it again.  Thanks.

[sdgathman]

Yep, the registrars web app shows the old IPs again.  I updated it again.  Hoping it was just a glitch.

[sdgathman]

Ok, is it a bug in BIND that it won't use an alternate NS when the first one isn't responding?  Should I file a bug report with the bind project?  Or is there a good(/bad) reason for the behaviour?  Oh wait, there *are* no alternates for the ip6.arpa zone.  Duh!  Thanks again.