One Homelab Hostname Can Have More Than One DNS Answer

A homelab hostname can stay the same while different clients receive different addresses for it. That can make a self-hosted service convenient on the home network and through remote access, but a DNS answer does not create a route, open a firewall, or sign someone in. Treat the name as one part of the connection rather than a promise that the whole connection works.

Start with who answers the lookup

Consider a private home-server dashboard called dashboard.example.com. The name is illustrative, not a working endpoint. A resolver used at home could answer with the local reverse proxy's address. A remote device could use a different resolver and receive a different answer, or no answer at all. This arrangement is commonly described as split-horizon DNS.

There is a related choice about where queries go. In Tailscale's DNS documentation, a restricted nameserver handles queries for a specified domain; Tailscale calls that split DNS. Selecting a resolver for a domain and maintaining different answers for different audiences are related techniques, but they are not identical configuration tasks. Decide which behavior the household actually needs before choosing a product setting.

A private resolver must also be reachable

A remote laptop cannot use a DNS server at home merely because its address appears in a settings page. There must be an authorized network path to that resolver. Tailscale specifically notes that private DNS servers may require subnet routing to become reachable.

The application has its own path as well. A successful lookup that returns a home LAN address does not demonstrate that a remote client can reach that address. Conversely, a reachable application can still seem broken when its name cannot be resolved. Keeping those two observations separate avoids changing the application's permissions to fix a naming problem.

Planning this design requires control of the relevant DNS settings and knowledge of the existing remote-access arrangement. Changes to a shared resolver or VPN DNS configuration may require an administrator. This article explains the design; it is not a router-specific deployment recipe.

A second resolver is not necessarily a standby

It is tempting to pair a private resolver with a public resolver and label the public one a backup. That description can conceal a functional mismatch: the public resolver may not know the private names at all.

Tailscale documents several resolver-selection behaviors, including parallel queries, performance-based ordering, and load balancing. The effective behavior depends on the operating system and DNS configuration, not just the order in which addresses were entered. If either resolver might answer a private-domain lookup, both need to support the intended result, or the client needs a domain-specific forwarding arrangement.

The desired result is consistency for the relevant names, not simply two reachable DNS servers. An intermittent wrong answer is a different failure from a resolver that never responds.

The browser can make a different naming choice

A system lookup and a browser visit are not always testing the same resolver path. Firefox supports DNS over HTTPS, with behavior that varies by protection mode and network conditions. Mozilla's current explanation describes local-provider handling, fallback behavior, and exceptions.

That does not mean encrypted DNS should be disabled throughout a household. It means a successful operating-system lookup is incomplete evidence for a particular browser. A useful comparison records the client, whether its VPN is connected, the browser's DNS mode, and the intended hostname. Different results can then be explained without assuming the home server has changed.

HTTPS is a separate proof

A local address does not prevent a service from using a publicly trusted certificate for a domain under the operator's control. Let's Encrypt's DNS-01 challenge validates control using a DNS TXT record and can work when the web server is not publicly exposed. It also supports wildcard certificates.

This requires control of the domain's validation records, an appropriate ACME client, and a workable renewal process. It does not turn an arbitrary private name into a publicly certifiable domain. Nor does successful certificate issuance prove that a particular client can reach the application.

DNS API credentials deserve their own protection. Let's Encrypt warns about placing broad DNS credentials on the web server and recommends narrower credentials or separate validation. A convenient renewal setup should not quietly grant an application unrestricted control of the entire DNS zone.

Judge the name and the entrance separately

Before adopting a shared hostname, write down the expected result for each audience:

• At home: which resolver supplies the answer, and which service endpoint should it identify?
• On an authorized remote device: can it reach both the resolver and the returned application address?
• In the browser actually used: does the naming path agree with that design, and is HTTPS valid for the hostname?
• For an unauthorized device: does the network or application policy deny access even if the address is known?

An absent DNS record is not a substitute for that last policy. The useful outcome is a memorable name with predictable behavior, while routing, certificate trust, and authorization each remain explicit responsibilities.