Private DNS Name or Just an IP? Decide Before You Share It

Two questions get mixed together when a private service is opened to remote users. The first is what name clients should use; the second is which sources the service should admit. Answer them in that order, because a correct name behind the wrong admission rule still fails, and a correct rule behind a name that does not resolve never gets tested at all.

Condition one: which resolver path do clients have?

A private name works only if the client's resolver can answer it. That means an authorized remote client must reach a DNS server that holds the zone, either through the tunnel or through a resolver the organization already runs for remote users. The tunnel is a transport, not a directory. It gives the client a path to a resolver, and it does not tell the client which zone to ask for.

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

A public resolver will not learn a private zone because the laptop connected to a VPN.

The suffix deserves the same attention. Use a subdomain of a domain the organization controls, so ownership and certificate planning stay explicit. Avoid .local: the multicast DNS specification ties that suffix to link-local resolution, and a routed tunnel does not reproduce that behavior for you.

Condition two: what source does the service receive?

Admission rules are written against addresses, so the useful question is which address the service sees after routing and translation. For an example service at 10.20.30.40, office clients arrive from 10.20.30.0/24 and remote clients from a separate pool such as 10.99.0.0/24.

If a gateway translates the remote pool, the service sees the translator, and a rule written for 10.99.0.0/24 will not match.

Read this from the service side rather than the client side. A listener log or a packet capture on the service host shows the source that actually arrived; the client's own address is only a guess about what survived the path.

Condition three: is the name tied to a service or to a host?

A name that points at one machine's address couples every client to that machine. A name that points at a load balancer or a stable service address survives replacement of the host behind it. Choose deliberately, because changing this later means changing every client's bookmarks and every certificate subject.

For a single internal service, a direct record is usually fine and simpler to reason about.

For anything that will be replaced, rebuilt or scaled, a stable front end is worth the extra configuration. The test is simple: if you can replace the backend without telling users, the name is attached to the service; if you cannot, it is attached to a host.

Test the two decisions separately

Resolve first, then connect. A resolution test that returns the expected address proves the name path and says nothing about admission. A connection test proves the path and the rule together, so run it only after resolution succeeds.

curl -sv --max-time 5 https://files.corp.example/health

Then test a forbidden source once, and record the result.

Keep the two records separate in your documentation: the name and its zone, the admitted sources and the rule owner. When one changes, the other does not have to.

Where the decision usually goes wrong

The common failure is a service published under a name that resolves only on the office network, with an admission rule that admits only the office range. Remote users then report a broken service that is in fact two separate omissions. The second common failure is the reverse: a wide admission rule added to make a name problem go away, which leaves the service reachable from sources nobody intended. Both are configuration omissions, and from the user's chair they look the same.

Neither mistake is visible from a single successful test. That is why the two decisions deserve separate records and separate tests, even when the same person makes both.

Write both down before the service goes live, because the next change will be easier to reason about. The record is short: one line for the name and its zone, one line for the admitted sources and the rule owner.