Controlling Multi-Homed Microsoft DNS Server Registration. Your eyes can deceive you, don’t trust them.

In the last post we examined how to programatically control DNS dynamic registration on DNS clients. Now we’re going to examine the same problem, but on the DNS server itself. The DNS registration configuration for the DNS server can be misleading, which is why this quote is particularly pleasing.

Let’s recap. When you don’t have the DNS Server role installed – so you’re a workstation or a normal server – DNS dynamic registration is controlled on the interface through the IPv4/IPv6 DNS configuration screen. Additionally, the DNS Client service is responsible for dynamic registration and DNS queries. Once you install the DNS Server role however, this changes. The DNS Server service now takes over local DNS registration and DNS queries.

By default, the DNS Server will bind to all interfaces, IPv4 and IPv6. This is controlled on the DNS Server configuration screen (Right click the Server in DNS Manager, click Properties). Binding to all interfaces means that the DNS Server will listen for and respond to DNS queries on all interfaces. Multi-homed servers – servers that have multiple interfaces – generally do not need to respond to DNS queries on all interfaces. Multi-homed servers are generally multi-homed as they have a Data/Primary/Service interface, and then possibly a Management and/or a Backup interface. In this example, only the Data/Primary/Service interface will need to respond to DNS clients as that’s typically where the clients are. If we were to change this configuration setting on the DNS Server and bind it only to the primary interface then the DNS Server will only listen on this interface, and respond to queries from this interface.

This has two important side effects.

Firstly, as the DNS Server has taken responsibility for performing DNS queries (and not the DNS Client service), we have now limited the DNS Server to only generate queries from the IP address of the primary interface. So if you needed to communicate via a DNS Forwarding configuration to an upstream DNS Server through the management interface, then we’ve just broken that. Whilst the DNS Server will still be able to generate outbound queries on the management interface, it will use the source IP address of the primary interface and due to routing configuration will unlikely receive a reply from the upstream server. I’ll create another post later describing how interface and source IP selection work on Windows and Linux.

Secondly, the DNS Server will only register its own DNS records for interfaces that the DNS Server is bound to. So if you were having problems before with clients accidentally resolving the management or backup interface, then that problem should have resolved itself, if you pardon the pun.

Great. Fixed. Wonderful. We’ve now fixed the DNS dynamic registration issue for the DNS Server. It is now only registering records for the primary interface. However, let’s go back to the example mentioned above. Let’s pretend that the server has two interfaces, a primary interface and a management interface. All of the clients are reachable through the primary interface, yet the upstream DNS server is only reachable through the management interface. If we were to bind the DNS Server to only listen on the primary interface then we would not be able to query the upstream DNS server through the management interface (it is unlikely to know how to return traffic to the IP address of the primary interface).

Luckily for us (and Obi-Wan and Yoda), this fix was not our only hope, there is another.

There is an alternate method of solving this problem. If we were to configure our DNS Server back to its default bind setting, which is to bind to all interfaces, we would have fixed the issue preventing outbound queries on the management interface. However, we’ve now reintroduced the original problem of dynamically registering both the primary and the management interface addresses. This is where we now need to switch to a registry change. If you navigate in the registry to the below key, you will be able to control which addresses should be dynamically registered by the DNS Server.


Here, you can create a new value called PublishAddresses. This is a REG_SZ or String value where you manually enter each IP address that you would like to register. Multiple IP addresses need to be separated by a space. Configure this, restart the DNS Server service and the appropriate self registrations should now be in place. You may still see a couple of spurious A records attached to the DNS domains themselves though – these records generally disappear once the NetLogon service has refreshed the Domain Controller DNS records (if your DNS Server is also a Domain Controller). Restarting the NetLogon service should correct those records.

The Microsoft article describing the registry setting can be found here.

~ Mike

3 thoughts on “Controlling Multi-Homed Microsoft DNS Server Registration. Your eyes can deceive you, don’t trust them.

  1. OMG thank you. I’ve been looking for this for some time now! I have DNS servers that are multihomed due to a migration where I need to keep both new and old IPs in place to allow my company to continue performing DNS queries on the old IPs until they can reconfigure a number of servers/applications. Having both IPs registered in DNS is causing name resolution issues. This should help to solve both.

    1. Update… looks like this only prevents the NS records from registering. The domain’s default A records are still generated when the Netlogon service restarts. Bummer. Hopefully there’s an easy fix for that.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s