IPv6 DNS Lookup – How to Perform

domain-name-systemipv6tcpdump

I am trying to prevent a webserver to do IPv6 lookups (AAAA) to the DNS-server. The webserver has no IPv6 addresses set-up on the interfaces. Disabling IPv6 in sysctl.conf had no impact either, the webserver keeps sending both A and AAAA requests for every hostname to the DNS server (I performed a tcpdump).

Can anyone help me with stopping the webserver to send out IPv6 hostname lookups?

Extra information:
This is on my internal network. TCPDump:

webserver.internal.43831 > internaldns.internal.domain: [bad udp cksum 629d!] 63585+ A? someserver.internal. (43)`  
webserver.internal.43831 > internaldns.internal.domain: [bad udp cksum 32dd!] 40337+ AAAA? someserver.internal. (43)

internaldns returns the IP for the A-record and NXDOMAIN for the AAAA, as there isn't set one.

Best Answer

There is no reason to disable IPv6 AAAA lookups (at least none you've given us), so my answer to you is please stop trying to outsmart your system and let it work the way it's intended to.

By disabling IPv6 lookups now you're just setting yourself up for mysterious problems in the future when you add IPv6 to your environment and suddenly some systems aren't working properly.
The negligible cost of a few bytes in a spurious DNS request is far outweighed by the predictability/correctness of your environment in the future.

That said, if you still want to play with this foot-gun the easiest solution (in fact the only one I'm aware of) is to compile and install a resolver which is not IPv6 aware.

If you do such a horrible thing ensure that it is well documented in no fewer than 5 places (Your site's documentation repository, MOTD/issue, SSH banner, a sticker on the machine itself, and in a memo to your boss) so that when it breaks in the future there's a chance someone will be able to fix it quickly, without having to figure out that the machine was lobotomized.

Related Solutions

DNS Resolve Timeout on RHEL 6.3 Behind Firewall – Solution

This happens in dual stack IPv4/IPv6 environments where the machine doing a DNS lookup sends requests for AAAA and A records on the same socket, expecting to receive two replies back. This is default behavior for relatively recent versions of glibc. The Juniper firewall, however, drops the connection after the first reply comes back.

The Juniper knowledge base has an article describing how to configure the firewall to work around this issue.

As @BMDan noted, you can also add the line to /etc/resolv.conf:

options single-request-reopen

This works around the broken firewall behavior by opening two connections to look up the AAAA and A records.

How to prevent delays associated with IPv6 AAAA records

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.

enter image description here

EDIT

Now you're on to something.

Make sure you're capturing traffic for the Microsoft 6To4 adapter, otherwise you won't see IPv6:

enter image description here

Here's the nslookup result for my RDS server. Make note of the IPv6 addresses:

enter image description here

Now here's a snippet of my capture:

enter image description here

And finally, here's a snippet from netstat showing the connection:

enter image description here

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.

Best Answer

Related Solutions

DNS Resolve Timeout on RHEL 6.3 Behind Firewall – Solution

How to prevent delays associated with IPv6 AAAA records

Related Topic