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 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 from working even though the URL works. The particular scenario in which this occurs is as follows:

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

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

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, and wouldn't care one iota about the A resource records for 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 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 To ameliorate this, you can use one of two strategies:

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: \\\SYSVOL. If 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.

© Copyright 2003–2004,2009 Jonathan de Boyne Pollard. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp is preserved.