Three Publishers Can Put a DC's VPN Address in DNS

Three different components on a multihomed domain controller can put the same VPN address into DNS, and they fail independently. Compare what each one publishes rather than trusting the adapter's checkbox, which controls only one of them. The symptom is identical in every case: a client resolves the name, receives the tunnel address, and cannot reach the domain controller. Who published it decides how to stop it.

One setting, one service and one role; three publishers, three switches.

Start With the Record, Not the Checkbox

Query the affected server's full name through the DNS server the clients actually use, and record every address returned. Set every returned address against the server's actual LAN and tunnel interfaces, and against the networks the clients sit on. An address can be perfectly valid locally and unreachable for the clients that matter. Intermittent authentication failures are a common symptom, because clients receive or select different addresses on different attempts.

The machine resolving its own name correctly proves very little. The test that matters runs from the client networks.

The Adapter Is Only One Publisher

The adapter's TCP/IP properties hold a checkbox for registering that connection's address, and unticking it silences exactly one publisher. It does not stop the others, which is why the record can reappear after a reboot. If the domain controller also runs the DNS service, that service has its own listening configuration and its own name server records. Microsoft's multihomed guidance treats the interface behaviour, the DNS service and Netlogon as separate relevant publishers.

Three switches, three owners, and only one of them lives on the adapter's property page.

The DNS Service Has Its Own Addresses

A DNS server told to listen on a VPN address goes on publishing it in its own records, whatever the adapter checkbox claims. Align the service's listening addresses with the intended interfaces, and review the zone's name server entries at the same time. Changing listeners can interrupt clients currently using an address you remove, so establish who depends on each one first. Deleting a listener simply because it is a VPN address can cut off the clients you were trying to help.

Netlogon, and domain-controller discovery generally, also register addresses as part of their own duties. Do not suppress registrations domain-wide, or copy an old remote-access registry workaround without confirming it applies to your version and role.

Ownership Before Cleanup

Fix the publisher before removing the record, or the next registration event puts it back and the exercise repeats. Remove obsolete entries through the DNS owner's process and account for caching and ageing. Check from the client networks, covering domain discovery and whatever application originally failed, then trigger the same VPN event that first produced the address.

What you want at the end is a known set of published addresses and listeners, with everyday domain registration still doing its job. A machine whose name happens to resolve correctly straight after manual cleanup is not that.

Record which publisher was responsible, which records changed and which clients were tested. The next multihomed server will have the same three suspects.