Print

[maestro]

Hi, I am having issues with a website being very slow from an IPv6 host. The site only runs under IPv4.

I have found that one of their main server names is not resolving correctly in DNS. When I query the AAAA record it fails to respond, but when I query the A record it responds quickly. This is causing their website to be very slow as my system will sit and wait for timeouts for the AAAA record from both their servers (sequentially) before trying for the A record.

I am trying to liase with their helpdesk people (which is interesting as a bank's hepldesk staff have no idea about DNS, let alone AAAA records) but I was wondering what exactly the standards say about this.

Does anyone know the RFC (and section if possible) that specifies the following...
1) A dual stack IPv4/6 machine MUST always attempt to connect via IPv6 before via IPv4.
2) A DNS server faced with an unknown record type (eg, AAAA) must return with no answer (rather than refuse to respond at all)

For anyone interested, the URL which fails to resolve via AAAA is "www.my.commbank.com.au". Interestingly enough, "static.my.commbank.com.au" resolves correctly (instant reply with no answer) for a AAAA query and is served by the same two DNS servers.


Thank you

[k1mu]

This is unfortunately common behavior for a number of "load balancer" products. The "engineers" of those products didn't consider IPv6 and don't know how to handle AAAA requests.

These products are unsuitable for use on the Internet, but they're still popular, unfortunately.

I had one site accuse me of "hacking" their DNS servers when I supplied them DIG output demonstrating the erroneous response to AAAA queries.
Of course, it's probably still broken.

[kasperd]

Do you still see a problem? Both DNS servers respond instantly when I query them.

[maestro]

Do you still see a problem? Both DNS servers respond instantly when I query them.

Yes, I still see the problem. The A record still returns quickly while the AAAA record still times out.

I have tried this on my system as well as web-based nslookup tools with identical results.

When it responded instantly, were you performing an A query, or an AAAA query?

[Jim Whitby]

Tried from USA:

ipv6
;; QUESTION SECTION:
;www.my.commbank.com.au.                IN      AAAA

;; Query time: 223 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)

and

;; QUESTION SECTION:
;www.my.commbank.com.au.                IN      AAAA

;; Query time: 235 msec
;; SERVER: 2620:0:ccd::2#53(2620:0:ccd::2)

[maestroevolution]

Responds promptly for me too, also in US, querying HE's anycast DNS server.

joel@maestro:~$ dig @2001:470:20::2 aaaa www.my.commbank.com.au.

; <<>> DiG 9.7.3 <<>> @2001:470:20::2 aaaa www.my.commbank.com.au.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51612
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.my.commbank.com.au.      IN   AAAA

;; Query time: 35 msec
;; SERVER: 2001:470:20::2#53(2001:470:20::2)
;; WHEN: Fri Dec  9 09:17:16 2011
;; MSG SIZE  rcvd: 40


Your original statement was correct, of course... DNS servers should respond that way.  However, as some are broken, or incomplete, and some enterprises drop aaaa requests to ensure their hosts use IPv4 connectivity, this is why I see so many websites that are IPv6 capable, but disable it or provide a special URL for the main page, so the website does not appear to be slow to end users.

[kasperd]

I have found that one of their main server names is not resolving correctly in DNS. When I query the AAAA record it fails to respond, but when I query the A record it responds quickly.

Are you sure it is the authoritative DNS server, which is causing the problem, and not the recursive resolver you are using?

Be aware that on some networks all DNS lookups are hijacked and send to the provider's own recursive resolver regardless of which IP you send them to. I have seen networks where even DNS requests send to completely bogus IP addresses would receive a reply.