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.
Best Answer
This question is pretty interesting and I must admit that I've never seen this behavior. In doing some fiddling around to try and understand it better, I took a snippet of nslookup querying for one of my W2K8R2 RDS servers from another W2K8R2 server and I also captured a snippet of an RDP session to the same RDS server from the same test server. Nslookup showed no delay in returning the IPv6 record and the nslookup showed my test server querying for the IPv4 record before querying for the IPv6 record. The time delta in the capture shows no appreciable delay (that I can ascertain) in either query.
EDIT
Now you're on to something.
Make sure you're capturing traffic for the Microsoft 6To4 adapter, otherwise you won't see IPv6:
Here's the nslookup result for my RDS server. Make note of the IPv6 addresses:
Now here's a snippet of my capture:
And finally, here's a snippet from netstat showing the connection:
So clearly, as you've confirmed, DNS resolution isn't the problem. The problem is that the RDP connection prefers IPv6 over IPv4 (which is the default for Windows - Windows prefers IPv6 over IPv4) and because IPv6 isn't functioning properly it's causing the delay (as you've stated) when falling back from IPv6 to IPv4. You could fix this by configuring the clients to prefer IPv4 over IPv6, but I think that would merely be masking the problem. The better solution would be to figure out why IPv6 isn't working and fix that. I don't know enough about IPv6 to help but my guess is that the IPv6 records being returned by DNS are "local" addresses valid only on the subnet where the RDS hosts exist and since the clients are in a different subnet, they can't reach those IPv6 addresses.