deleted IPv6 records re-appear in Windows DNS server

We recently took over a domain controller and an Exchange Server, both Windows 2008 R2, with e-mail connectivity problems. We soon found invalid AAAA records in DNS. They were pointing to the IPv6 addresses of the hosts' 6TO4 tunnel adapters, not to the addresses of their physical LAN adapters.
We then deleted the wrong AAAA records on the domain controller's DNS server only to see them re-appear again within a couple of hours, breaking Exchange communication again. Who/what keeps registering these records? How do we keep them off?
("Register in DNS" in LAN connection properties is unchecked; all servers are IPv6-autoconfiguring.)
LVL 3
zolcerAsked:
Who is Participating?
 
Adam BrownConnect With a Mentor Sr Solutions ArchitectCommented:
Exchange doesn't use IPv6, but will function over it if it and IPv4 are available.

You'll want to check all the servers to make sure 6to4 isn't installed, including the DCs and exchange servers. It's not usually there unless one NIC has a public ip assigned, so it was probably misconfigured at some point.

If 6to4 is disabled and IPv6 adapters are set to not register in dns, you should be good.
0
 
Adam BrownSr Solutions ArchitectCommented:
The important question is whether the network is utilizing IPv6 in any significant fashion. If it is not, disable the 6TO4 adapters on the servers.
If IPv6 is in use and any of the servers are set up with a NIC that has a public IP address (or is set up with your ISP's provided IPv6 address), you will want to make sure that the Register in DNS setting on the Public NIC is unchecked as well.

That said, you may want to re-architect the environment to remove the 6TO4 adapters from the servers. Those should only be used in very rare situations. If IPv6 is in use, the 6TO4 adapters should not be used on the servers (Either the Firewall should handle this transition if your ISP only provides IPv4 addresses, or there is no transition necessary because the ISP provides IPv6 addresses for public Internet access and the Internal network uses IPv6). If IPv6 is not in use internally, 6TO4 translation should, again, be done on the firewall, not the servers.
0
 
zolcerAuthor Commented:
We haven't spotted anything that requires IPv6 so far. It doesn't interact with the WAN, either. I reckon the former IT guy just never touched the defaults, so it's been there since installation. We'll go ahead and disable it on the DC. Should that keep the AAAA records from re-appearing?

I hear Exchange uses IPv6 internally, and tampering with IPv6 is therefore discouraged. Are we going to break Exchange if we disable it there, too?
0
 
zolcerConnect With a Mentor Author Commented:
I am good now, at last. (So it seems.)

You were right in all you said, I just misunderstood. I thought unchecking the IPv6 box would take care of the false AAAA entries. It didn't. The 6TO4 adapter kept re-registering in DNS, and it wasn't until I read and applied How to disable IPv6 or its components in Windows that the AAAA records went away. I ran the Easy Fix Wizard to disable IPv6 on all tunnel interfaces only, not touching IPv6 on the physical NIC. That did the trick.

The 6TO4 adapter was created only because the former IT guy failed to choose an RFC 1918 address range for the LAN ... (sigh!)
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.