How to prevent delays associated with IPv6 AAAA records?
- by Nic
Our Windows servers are registering IPv6 AAAA records with our Windows DNS servers. However, we don't have IPv6 routing enabled on our network, so this frequently causes stall behaviours.
Microsoft RDP is the worst offender. When connecting to a server that has a AAAA record in DNS, the remote desktop client will try IPv6 first, and won't fall back to IPv4 until the connection times out. Power users can work around this by connecting to the IP address directly. Resolving the IPv4 address with ping -4 hostname.foo always works instantly.
What can I do to avoid this delay?
Disable IPv6 on client?
Nope, Microsoft says IPv6 is a mandatory part of the Windows operating system.
Too many clients to ensure this is set everywhere consistently.
Will cause more problems later when we finally implement IPv6.
Disable IPv6 on the server?
Nope, Microsoft says IPv6 is a mandatory part of the Windows operating system.
Requires an inconvenient registry hack to disable the entire IPv6 stack.
Ensuring this is correctly set on all servers is inconvenient.
Will cause more problems later when we finally implement IPv6.
Mask IPv6 records on the user-facnig DNS recursor?
Nope, we're using NLNet Unbound and it doesn't support that.
Prevent registration of IPv6 AAAA records on the Microsoft DNS server?
I don't think that's even possible.
At this point, I'm considering writing a script that purges all AAAA records from our DNS zones. Please, help me find a better way.
UPDATE: DNS resolution is not the problem. As @joeqwerty points out in his answer, the DNS records are returned instantly. Both A and AAAA records are immediately available. The problem is that some clients (mstsc.exe) will preferentially attempt a connection over IPv6, and take a while to fall back to IPv4.
This seems like a routing problem. The ping command produces a "General failure" error message because the destination address is unroutable.
C:\Windows\system32>ping myhost.mydomain
Pinging myhost.mydomain [2002:1234:1234::1234:1234] with 32 bytes of data:
General failure.
General failure.
General failure.
General failure.
Ping statistics for 2002:1234:1234::1234:1234:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
I can't get a packet capture of this behaviour. Running this (failing) ping command does not produce any packets in Microsoft Network Monitor. Similarly, attempting a connection with mstsc.exe to a host with an AAAA record produces no traffic until it does a fallback to IPv4.
UPDATE: Our hosts are all using publicly-routable IPv4 addresses. I think this problem might come down to a broken 6to4 configuration. 6to4 behaves differently on hosts with public IP addresses vs RFC1918 addresses.
UPDATE: There is definitely something fishy with 6to4 on my network. When I disable 6to4 on the Windows client, connections resolve instantly.
netsh int ipv6 6to4 set state disabled
But as @joeqwerty says, this only masks the problem. I'm still trying to find out why IPv6 communication on our network is completely non-working.
