ESXi hosts generating IPv6 AAAA DNS records

[snowmizer]

While troubleshooting another issue on my Windows 2008 R2 domain controller I noticed that in my wireshark capture there are packets from my ESXi 4.1 U2 hosts for DNS queries using IPv6 (they show up as "Standard query AAAA <domain controller FQDN>+domain again (e.g. mydc.mydomain.com.mydomain.com)". After this query comes back unsuccessfully I see a packet that is the normal IPv4 "Standard query A <domain controller FQDN>" which resolves successfully.

The hosts are registered in AD. I checked my ESXi hosts and have IPv6 disabled on all hosts. Why would my hosts be doing these lookups?

Thanks.

[rickardnobel]

snowmizer wrote:

The hosts are registered in AD.

With registred, do you mean that you have enabled Active Directory authentication on the hosts?

I checked my ESXi hosts and have IPv6 disabled on all hosts. Why would my hosts be doing these lookups?

Does the DNS lookup come from the management address of the ESXi host? It is a bit strange of course, but it might be that the ESXi dns resolver has a default behavior of doing both IPv6 (AAAA) and IPv4 (A) lookups of names.

[snowmizer]

Sorry, yes I mean that I have enabled Active Directory authentication on the ESXi hosts. Also, the source IP address on the DNS requests is the management IP for the ESXi host. I'd like to totally disable IPv6 DNS lookups at this time. However if I couldn't I'd be ok with this if I could prevent it from appending the "mydomain.com" at the end of the server's FQDN. Any ideas where I could find out why this is happening? I've never dealt with IPv6 and haven't seen anywhere that this is configured.

Thanks.

[rickardnobel]

snowmizer wrote:

However if I couldn't I'd be ok with this if I could prevent it from appending the "mydomain.com" at the end of the server's FQDN.

It is certainly strange and the FQDN+domain name seems like a bug, however in some way it might help you - since it will never be able that resolve that incorrect name you should not need to worry about the IPv6 dns lookups either. :smileyhappy:

[snowmizer]

Yeah that's true except that it makes my boss question what it's coming from and then wants them fixed so they either don't show up or show up correctly. :smileyhappy:

[rickardnobel]

Do you see any other indications of this expect while doing a wireshark sniff at udp/53?

It might be a default behavior that nobody actually has ever looked at.

[snowmizer]

Only the fact that it shows up in our DNS debug logs from our domain controllers. That's what initially brought it to our attention. Then yesterday I was investigating another DNS query and noticed these records in my Wireshark capture and remembered this was something else I needed to figure out. It doesn't cause us any issues...it's just something in our logs and I need to be able to explain. :smileyhappy:

[rickardnobel]

snowmizer wrote:

.. it's just something in our logs and I need to be able to explain. :smileyhappy:

I do not have a 4.1 host available to test at the moment, but if I should guess then I think this is always done, but since very few organizations use IPv6 and ever fewer look at the DNS logs in detail, then it is not noticable.

That might or might not help you. :smileyhappy:

Note that even if you do not have IPv6 enabled on the ESXi host then the dns resolver could be programmed to do what ever dns lookups, i.e. it could try to resolve the MX record for the domain name, even if it can do nothing with the result.

[snowmizer]

Well thanks for the help. It might be worth opening a ticket with VMWare in case the appending of the domain name to the FQDN name is a bug. I will post any updates after I receive them.

[rickardnobel]

snowmizer wrote:

It might be worth opening a ticket with VMWare in case the appending of the domain name to the FQDN name is a bug. I will post any updates after I receive them.

Yes please post an update if you get any answer from VMware support, it will be interesting to know if this is an expected behavior.

[dbmartin00]

I am experiencing precisely the same problem with VMware fusion 5.  I have three guest vms: two centos linux and one windows 7.  They all have five second timeouts on IPv6 AAAA DNS queries.

Any resolution to this?

[snowmizer]

I've been working with support on this since I first posted this. At first VMWare wanted to upgrade to ESXi 5.0 and see if that fixed the issue but it hasn't. When I get a solution to this I'll post an update.

Glad to hear I'm not the only one seeing this error.

[admin]

This is by spec according to the ietf:

http://tools.ietf.org/html/draft-li-dnsext-ipv4-ipv6-02#section-1.2

per the spec during the "transition time" between v4 and v6 AAAA records should be queried first followed by A records if there is no answer.  From the above doc:

"Due to large-scale applicable for IPv4, it will take a long time to
 fully transit from IPv4 to IPv6. During the transition period, IPv4
 network and IPv6 network will coexist.In most cases, the host will
 not know whether the address of the other side is IPv4 or IPv6.
 According to current practices, the host will send an AAAA query
 first. If there no IPv6 address has been retrieved, then an A query
 will be issued."

Unfortunately dns clients are not smart enought to know if IPv6 is turned on or off - so the above will always be followed.

Regards,

C. Paxson

[snowmizer]

I don't have a problem with the AAAA query as long as the domain name it's looking up is not formatted like my.domain.com.mydomain.com. That's the issue I've been trying to resolve. I can see the AAAA record for my.domain.com and am ok with that.

[admin]

That seems to be a bit different from your original post.  Remove all search domains from the host and test.  This should fix it.  Let us know what the outcome is.

http://pubs.vmware.com/vsphere-51/topic/com.vmware.vsphere.networking.doc/GUID-54FAFA3C-7A84-43CA-9461-ED06513B9C16.html