Why a server name resolves to its VPN address after dial-in

An office file server answers on its LAN address all morning, then a remote user dials in and the name starts resolving to a tunnel address instead. Nothing was edited in DNS by hand, which is the clue: the record was published by the machine itself. Three conditions decide whether you fix the registrar, the record, or the client's view, and getting the order wrong means the record returns after the next connection.

Two addresses, one name, three conditions

A multihomed Windows server can hold a LAN address, one or more dial-in addresses, and sometimes a second NIC. Each interface may register its own addresses in DNS if dynamic registration is allowed for it. When the PPP adapter registers, the same host name gains an address that only the tunnel peer can reach, and LAN clients receive it as a valid answer.

Three conditions decide the repair. First, is the extra address reachable from the clients that receive it? Second, does any consumer still depend on that registration? Third, is the record dynamic, and therefore able to come back, or static and therefore a deliberate entry?

Answer those before touching anything. If the address is unreachable from the querying network, no amount of client cache clearing fixes it for long. If something does depend on it, such as a management path used by the tunnel peers themselves, removing it breaks that path instead. And a dynamic record deleted without addressing its publisher will reappear at the next registration event.

Read the record before you change the registrar

Query the exact fully qualified name from the network that reports the problem, and compare the answers with the server's actual interfaces and listeners. A single name returning several addresses is normal; the question is whether each one is usable by the client that receives it.

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

The first query uses the local resolver, the second asks a specific DNS server directly, and the third does the same from PowerShell on Windows. Comparing them separates a stale client cache from an authoritative answer. If the direct query already returns the tunnel address, the problem is published data rather than local caching.

Write down the record's timestamp and whether the DNS console shows it as dynamic. That single attribute tells you which of the three conditions above applies, and it is the difference between a five-minute cleanup and a repair that lasts.

Fix the publisher, or fix the record, but know which

If the record is dynamic and unwanted, the durable fix is to stop that interface from registering. Windows exposes per-interface registration settings, and the DNS client service republishes on the next connection or address change. Turning registration off for the dial-in adapter leaves the LAN adapter's registration intact, which is usually what you want.

Be careful with machine-wide switches. A global setting that disables dynamic update affects every interface on that host, including the one whose registration other clients rely on. On a domain controller the same caution applies with more force, because the host may also own service location records that clients depend on for logon.

If the record is static, it was placed there on purpose and the conversation is with whoever placed it. Deleting a static record because it is inconvenient today removes the only evidence of why it exists. In both cases, delete the stale answer only after the publisher is handled, and record what you changed so the next person can tell a deliberate entry from an accident.

Verify from the client network that failed

Verification belongs on the network that reported the symptom, not on the server. Clear the client resolver cache through its supported mechanism, then repeat the original lookup and the original service connection by name.

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

The first command clears the Windows resolver cache, and the second shows whether the name is cached again and which address was stored. A successful connection from the server to itself proves nothing about a LAN client, and removing a route to the unwanted address does not correct what DNS publishes.

Finally, repeat the event that used to introduce the address: reconnect the VPN client, or renew the dial-in session. Check the published name again after that lifecycle change. A repair that only survives until the next connection was a cleanup, not a fix, and knowing which one you performed is the difference between closing the ticket and reopening it next week.