Use a .local Address or a Domain on Your Home Network?

Use a .local name for local-link mDNS discovery when all required clients support it. Use ordinary DNS for a home.arpa name served by your home resolver, or for a domain you own. If you also need access away from home, decide whether clients will use a private VPN and DNS or a public service address.
Neither choice makes the server reachable from outside your home, and neither one turns on HTTPS. Home server naming comes down to two questions: which clients have to look up the name, and where does the name have to work?
Which Name Should You Use on Your Home Network?
Pick the name that matches how your devices look up names and where the name must work. A .local name and a domain rely on different systems rather than serving as interchangeable spellings.
| Access needed | Naming option | Additional requirement |
|---|---|---|
| On the same local link | mDNS .local | Compatible clients and service discovery. |
| On the home network | home.arpa through local DNS | Clients use the configured resolver. |
| Away, through your private network | Private DNS over a VPN | Working service routes and access to the private DNS resolver. |
| Public visitors | Public DNS name | A reachable service path, access controls, and HTTPS configuration. |
.local for Compatible Home-Only Discovery
Multicast DNS (RFC 6762) reserves .local for local-link name resolution. Compatible devices ask over multicast rather than consulting a conventional authoritative DNS zone for those names. Both the client and the service must support the intended discovery path.
That makes .local a good fit when the server only needs a name at home and every client that uses it can resolve mDNS names. Judge it by the full list of devices, not the first one that works. Picture a household where a laptop, a phone, and a TV app all open the same server. If the laptop finds server.local but the TV app can’t, the TV app needs a DNS-based name instead. One working device doesn’t prove the rest will work.
Avoid reusing .local as a conventional unicast DNS zone: clients may send those queries to mDNS instead. Use a DNS namespace intended for your setup, and test each device that must connect.
DNS-Based Names: home.arpa or a Public Domain
RFC 8375 reserves home.arpa for residential networks. Names such as server.home.arpa use ordinary DNS and have meaning within the home network’s DNS scope. Configure a local resolver to answer them and make sure clients use it.
The condition is simple. Something on your network has to answer for those names, usually a local DNS resolver that your devices already query. If your resolver is set up to answer for home.arpa, every client that uses that resolver can look up the name, whether or not it supports Bonjour. If nothing answers for it, the name won’t resolve, no matter how it’s spelled.
A domain you register can also use ordinary DNS. Public DNS can publish a service name for visitors, while split DNS can give authorized clients different answers on a private network. Registering a name does not decide whether the service itself is public or private.
Use public DNS when visitors need to resolve the name without joining your private network. For your own devices, a VPN with routes to the service and a reachable private resolver can support private names away from home. Tailscale’s split-DNS guidance describes directing queries for a private domain to an appropriate nameserver. Ordinary routed VPNs do not automatically carry .local multicast discovery.
A Name Does Not Provide Remote Access or HTTPS
Name resolution, connectivity, and HTTPS are separate checks. A DNS answer gives a client an address. The client still needs a working route and permission to connect, and HTTPS requires a TLS-enabled service with a certificate the client trusts for that name.
A publicly resolvable name can still point to an address that a particular client cannot reach. Conversely, a private name may work over a correctly configured VPN. Test the intended client from the actual location and network rather than treating the DNS answer as proof of access.
HTTPS works the same way. A .local name, a home.arpa name, and a public domain can each point to a server that serves only plain HTTP. Encryption comes from the TLS handshake, which only happens if the server is set up to offer it. The name you choose doesn’t add it.
Keeping these layers separate makes problems easier to locate. If a device resolves the name but the page won’t load, the name is doing its job. Look at the connection or the service instead. If the name doesn’t resolve at all, go back to the naming choice above and check whether that device supports mDNS or uses the resolver that answers for your DNS name.
Use Olares’s documented local addresses
For Olares, use the local-access instructions for your client and application. Standard HTTPS app URLs, the documented multi-level .local form, and the single-level community-app form have different requirements. The single-level form is not a general address for system apps. A hosts-file mapping is a per-device override, not a home DNS resolver; pointing any arbitrary hostname at the server is not sufficient.
FAQs
Will a .local or home.arpa Name Work When Away From Home?
They are not published as ordinary public names. A private DNS name such as server.home.arpa may work remotely if the VPN supplies the necessary routes and private DNS configuration. A .local mDNS name usually stays on its local link and will not automatically resolve across a routed VPN. Test the specific method you plan to use.
Do You Need to Buy or Register home.arpa?
No. home.arpa is reserved for home networks, so you do not register it as a public domain. Configure your local DNS resolver and the clients that use it. Remote clients need access to that private resolver and a route to the service if you want the name to work through a VPN.
Can One Public Domain Name Work Both Inside and Outside Home?
Yes, with DNS answers and routes that work in both places. For example, split DNS can return a local address at home and a different reachable address elsewhere. The service must also accept the chosen hostname, and HTTPS needs the matching certificate. DNS configuration alone does not provide remote access.
