Skip to Content [alt-c]

Andrew Ayer

Sections 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...

Hi, I'm Andrew. I'm the founder of SSLMate, which makes SSL certificates easy through automation, great software, and friendly support.

I blog about security, PKI, Linux, and more. If you liked this post, check out my other posts or subscribe to my Atom feed.

My email address is I'm AGWA at GitHub and @__agwa on Twitter.


The comments below are owned by whoever posted them. I am not responsible for them in any way.


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.

| Posted on 2014-11-28 at 15:34:49 UTC by Reader Thomas | Reply to This

Post a Comment

Your comment will be public. If you would like to contact me privately, please email me. Please keep your comment on-topic, polite, and comprehensible. Use the "Preview" button to make sure your comment is properly formatted. Name and email address are optional. If you specify an email address it will be kept confidential.

Post Comment

(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.
  • Text surrounded by *asterisks* is italicized.
  • Text surrounded by `back ticks` is monospaced.
  • URLs are turned into links.