Skip to Content [alt-c]

June 27, 2014 IPv6 Broken, Buggy DNS to Blame

I've previously discussed the problems caused by buggy DNS servers that don't implement IPv6-related queries properly. The worst problem I've faced is that, by default, F5 Network's "BIG-IP GTM" appliance doesn't respond to AAAA queries for certain records, causing lengthy delays as IPv6-capable resolvers continue to send AAAA queries before finally timing out.

Now is exhibiting broken AAAA behavior, and it looks like an F5 "GTM" appliance may be to blame. is a CNAME for, which is itself a CNAME for (which is in turn a CNAME for another CNAME, but that's not important here). The nameservers for ({ns1-bn, ns1-qy, ns2-bn, ns2-qy}, contrary to the DNS spec, do not return the CNAME record when queried for the AAAA record for

$ dig AAAA ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> AAAA ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44411 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ; IN AAAA ;; Query time: 137 msec ;; SERVER: ;; WHEN: Tue Jun 24 14:59:58 2014 ;; MSG SIZE rcvd: 34

Contrast to an A record query, which properly returns the CNAME:

$ dig A ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> A ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 890 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ; IN A ;; ANSWER SECTION: 30 IN CNAME ;; Query time: 115 msec ;; SERVER: ;; WHEN: Tue Jun 24 15:04:34 2014 ;; MSG SIZE rcvd: 79

Consequentially, any IPv6-only host attempting to resolve will fail, even though has IPv6 connectivity and ultimately (once you follow 4 CNAMEs) has an AAAA record. You can witness this by running ping6 from a Linux box (but flush your DNS caches first). Fortunately, IPv6-only hosts are rare, and dual-stack or IPv4-only hosts won't have a problem resolving because they'll try resolving the A record. Nevertheless, this buggy behavior is extremely troubling, especially when the bug is with such simple logic (it doesn't matter what kind of record is being requested: if there's a CNAME, you return it), and is bound to cause headaches during the IPv6 transition.

I can't tell for sure what DNS implementation is powering the nameservers, but considering that "GTM" stands for "Global Traffic Manager," F5's DNS appliance product, which has a history of AAAA record bugginess, I have a hunch...


Reader Thomas on 2014-11-28 at 15:34:


thanks for this. I realized a few months back a slightly reverse problem. My domain was for ages available via IPv6, back then (and still) I decided to also make it available via a IPv6 NS - and an IPv6 GLUE record. And interestingly when I had an IPv6 GLUE record the Google NS wasn't able to resolve it anymore. I saw requests coming in... it was properly responded, but at the client nothing was returned.

Funny enough, I just tried it and it seems to be working now... *g



PS: Keep up the good work, nice blog, great SSLMate... can't wait to have a look at that configuration management to be released.


Post a Comment

Your comment will be public. To contact me privately, email me. Please keep your comment polite, on-topic, and comprehensible. Your comment may be held for moderation before being published.

(Optional; will be published)

(Optional; will not be published)

(Optional; will be published)

  • Blank lines separate paragraphs.
  • Lines starting with > are indented as block quotes.
  • Lines starting with two spaces are reproduced verbatim (good for code).
  • Text surrounded by *asterisks* is italicized.
  • Text surrounded by `back ticks` is monospaced.
  • URLs are turned into links.
  • Use the Preview button to check your formatting.