I have a several Windows Server 2008 R2 DC/DNS servers locally, RODC's at the remote office, and a Windows Server 2012 DC/DNS server on Azure with a VPN tunnel established.

Earlier today I moved a webserver, changed the DNS records on one of the local DNS servers, and updated at the registrar. Everything worked as expected.

Then weird issues started popping up, some people being directed to the wrong server, others to the correct one.

After troubleshooting, I checked the local DNS server again and the records were still correct, until I hit refresh, and the old A-Records popped up in conjunction with the new ones.

The way these records are set up, is a forward lookup zone with one static A record using the parent domain for each zone.

So there ended up being two A-Records with different IP's for the URL's that I had changed earlier in the day, and the old records showed back up in DNS manager when I refreshed the screen. (I had checked several times previously without refreshing)

Fortunately this only affected internal users and not all of them at that, all external users were unaffected because the public DNS records are published through a registrar (GoDaddy, independent so unrelated).

What happened? And how can I prevent this from happening again?

  • I'm not sure what to title this, so feel free to make changes. – Matt Bear Dec 3 '13 at 2:02
  • What change did you make at the registrar? Is the registrar perhaps also hosting DNS for you, and is that where you made the change? These functions are separate. Also, what software are you using locally (windows DNS server?)? – Falcon Momot Dec 3 '13 at 2:10
  • Clarified a bit, Windows 2008r2/2012, and the registrar is 3'rd party and unrelated. – Matt Bear Dec 3 '13 at 2:14
  • Is the internal A record static? – Greg Askew Dec 3 '13 at 2:44
  • Yes it sure is. – Matt Bear Dec 3 '13 at 3:13

Nope, that's not what happened. Assuming you're talking about AD Integrated zones, DNS records are objects in AD. Objects have a USN which is essentially a number that increments whenever a change to that object is made. If your tunnel "blipped" the USN would be incremented on your on-prem DCs and not on your Azure-hosted DC. This means that when it came back online, it would see that it had an older copy of the record and update inbound. It wouldn't replicate the old record outbound.

As to why it happened, it's really next to impossible to say without getting deep into your environment.

  • That's what I thought... I'm at a loss for an explanation for what happened then, I'll remove my hypothesis from the question. – Matt Bear Dec 3 '13 at 2:15
  • I changed the IP on the existing A-Record, I didn't delete and create a new one, could that have caused it? – Matt Bear Dec 3 '13 at 2:31
  • It shouldn't. However, my experience with all things sharepoint is that all bets are off. Consider deleting both of them, waiting for replication, and if nothing is there, creating a new one. This might require a change window. – Falcon Momot Dec 3 '13 at 2:57
  • The issue has been fixed, at this point I'm just trying to insure it doesn't happen again. – Matt Bear Dec 3 '13 at 3:14
  • Running ipconfig /registerdns will cause a Windows domain member to register or update its own dynamically registered DNS record(s). – MDMarra Dec 3 '13 at 3:59

Since the old records reappeared in Windows DNS, one of two things are likely to be happening.

It's possible that AD auto-registration put the "old" records back once they were missing. Machines will register all their addresses unless you disable it in the network adapter properties.

If not that, you have some kind of strange replication problem. Replication in this way happens with other AD data, typically, so you can use repadmin to validate. However, simple connectivity problems shouldn't cause this, because every record has a serial and attempts to replicate old records overtop new ones are ignored.

AD replication problems are by far the less likely scenario.

  • The records in question were for SharePoint host-named site collections in a cloud VM, so auto-registration cant of been the cause. – Matt Bear Dec 3 '13 at 2:22
  • It could still be AD replication, I suspect, though I am not sure. – Falcon Momot Dec 3 '13 at 2:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.