Microsoft Windows Domain Controllers dynamically register their own IP addresses as the domain name.

You've come to this page because you've asked a question similar to the following:

My domain is example.com.. The A resource record for that name keeps being overwritten with one containing the IP address of my Microsoft Windows Domain Controller. Why ?

This is the Frequently Given Answer to such questions.

What is happening

Every hour, a Microsoft Windows Domain Controller automatically sends a DDNS update request to register an A resource record for its domain name, that lists its own IP address. This is done by the "NetLogon" service running on the machine. It is also done by the DNS server service if one is present.

Undesirable side effects

One side-effect of this is that in certain circumstances it stops the URL http://example.com./ from working even though the URL http://www.example.com./ works. The particular scenario in which this occurs is as follows:

• Your content HTTP server (that is publishing your web site) is not your domain controller, but is running on another machine with some other IP address (such as 207.46.249.222, for example).

• Your Domain Controller (whose IP address is 10.0.0.1, for example) sends its DDNS updates to your public content DNS server, because that is who it "sees" as being the content DNS server for its domain.

What happens is that whilst initially your DNS database looks like this

example.com.     IN A 86400 207.46.249.222
www.example.com. IN A 86400 207.46.249.222

your domain controller adds to the first resource record when it sends its hourly update, resulting in this

example.com.     IN A 86400 10.0.0.1
example.com.     IN A 86400 207.46.249.222
www.example.com. IN A 86400 207.46.249.222

being published by your public content DNS server, which of course causes problems.

Ideal service fix

In an ideal world, WWW browsers would use SRV lookups to find the content HTTP server that serves up http://example.com./, and wouldn't care one iota about the A resource records for example.com. that are being overwritten by your domain controller.

It is to Microsoft's utter and public shame and embarrassment, considering that it has listed such SRV records in its documentation for the past decade (you can see them here), that its own WWW browser doesn't use SRV lookups to find content HTTP servers. If it did, this whole problem wouldn't be a problem at all.

Local fix #1

To prevent http://example.com./ from being redirected (at least as far as the rest of Internet is concerned), employ "split horizon" DNS service with separate content DNS servers. Your domain controller must be configured to see your "internal" view of the DNS database, as published by your "internal" content DNS server.

Your domain controller will then end up sending its DDNS updates to your "internal" content DNS server, and won't overwrite the resource records published by your "external" content DNS server. (Moreover, it is best practice for your "external" content DNS server to not support dynamic DNS updates at all, in any case.)

However, anyone using your "internal" view of the DNS database will still end up trying to obtain content HTTP service from your domain controller if they use the URL http://example.com./. To ameliorate this, you can use one of two strategies:

• Run a content HTTP server on your domain controller, serving up the pages for the http://example.com./ web site directly.

• Run a proxy HTTP server on your domain controller, configured to fetch http://example.com./ from the actual content HTTP server for that site. (This will require overriding the proxy HTTP server's address-to-name mapping mechanism, in order to prevent it creating a proxy server loop.)

Local fix #2

To stop the DDNS updates from being sent in the first place, edit the registry on the domain controller and restart the system (or the NetLogon and DNS server services), as described in Microsoft KnowledgeBase article #267855 (which refers to Microsoft KnowledgeBase article #246804 for the NetLogon fix).

Note, however, that if you do this you will prevent access to group policy templates, since it will prevent workstations from accessing the "SYSVOL" shared volume. This shared volume is exported by domain controllers. Domain machines access it by using a "well known" UNC name that comprises your domain name: \\example.com.\SYSVOL. If example.com. does not actually map to the IP address of your domain controller, because you have disabled the DDNS updates, the "SYSVOL" volume on your domain controller will not be accessible via that UNC name, and your machines will be unable to access group policy templates.