Use a real public domain — a subdomain like home.example.com — for your homelab, not .local. A registered domain gives you free browser-trusted certificates and clean DNS; .local gives you neither, and it actively fights your operating system for the same namespace. This is the first decision in any internal HTTPS setup, and getting it wrong quietly poisons everything downstream.
I learned this the annoying way. Years ago I named my whole lab under .local because every tutorial did, and I spent a month blaming my DNS server for random eight-second lookup stalls that were actually macOS trying multicast first. The stakes are real: the TLD you pick decides whether you can ever get a public certificate for these hosts, and you cannot change it later without renaming every service. Choose once, choose right.
Why Can’t You Get an HTTPS Certificate for a .local Domain?
Because public certificate authorities are contractually banned from issuing certificates for internal-only names, and .local is exactly that. The CA/Browser Forum — the body that governs what public CAs may sign — required members to stop issuing certificates for internal server names and reserved TLDs, with all such issuance ending on November 1, 2015. There is no path around it. Let’s Encrypt physically will not sign nas.local.
The reason is ownership. A public CA’s whole job is to verify you control the name before it vouches for you. Nobody can control .local — it belongs to no one and everyone — so no CA can validate it, so none may sign it. Contrast that with nas.home.example.com: you can prove you own example.com by answering a DNS challenge, so a CA is happy to sign any name under it, even one that only ever resolves inside your LAN. The name being internal-only does not matter; the domain being provably yours is what matters.
That single fact is why the entire homelab internal HTTPS strategy hinges on this choice. Pick a real domain and free Let’s Encrypt certificates are on the table. Pick .local and your only route to trusted HTTPS is running your own internal CA and installing its root on every device by hand — a real option, but a much heavier one you took on by accident.
What Actually Goes Wrong When You Use .local?
The .local suffix is reserved for multicast DNS by RFC 6762, so when you also run a normal unicast DNS zone on it, two resolvers fight over the same names. This is not a theoretical conflict — it is a daily source of slow, intermittent, maddening lookups. mDNS is what Apple Bonjour, Chromecast discovery, and network printers use to find each other without a DNS server.
Here is the failure I actually watched. A macOS laptop resolving proxmox.local would first fire a multicast query onto the LAN, wait for the timeout because no device answered by that name over mDNS, and only then fall back to my unicast DNS server. That fallback cost roughly five to eight seconds on every cold lookup. Multiply that across a dashboard full of iframes and the whole page felt broken. Renaming to proxmox.home.example.com removed the multicast path entirely and lookups dropped to milliseconds.
It gets worse on mixed networks. Different operating systems handle .local differently — some route it strictly to mDNS, some try unicast, some are configurable — so a name that resolves instantly on your Linux box stalls on the family iPad. You end up with a network that behaves inconsistently per device, which is the single hardest class of bug to diagnose because it is never reproducible in one place. A real domain resolves the same way everywhere, because it takes the ordinary unicast DNS path on every platform.
How Do You Set Up a Public Domain That Only Resolves Internally?
You use split-horizon DNS: your internal resolver answers home.example.com names with private LAN addresses, while the public internet either gets nothing or a completely separate answer. The services stay entirely inside your network; only the domain registration is public. This is the setup I run, and it is simpler than the name suggests.
The pieces are: a domain you own (a cheap one is fine — this never needs to be your primary domain), a DNS provider whose API your ACME client can use for the challenge, and a local DNS resolver. On my network Pi-hole and AdGuard Home both run — deliberately redundant so a single reboot does not take name resolution down — and each holds local A-records mapping nas.home.example.com to its 192.168.x.x address. A client on the LAN asks the local resolver, gets the private IP, and connects internally. The name never leaves the building.
The certificate comes from the DNS-01 challenge, which never needs the host to be reachable from outside — it only needs a TXT record written through your DNS provider. That is the mechanism I break down step by step in Let’s Encrypt wildcard certs with DNS-01. The elegant result: a service on a no-internet-egress VLAN, resolving only through your local DNS, still carries a certificate every browser on Earth already trusts.
Should the Homelab Domain Be a Subdomain or Its Own Domain?
Use a dedicated subdomain like home.example.com under a domain you already own, or register a cheap throwaway domain just for the lab — both work, and the choice comes down to blast radius. I keep my lab on a subdomain of a domain that does nothing else, so a mistake in the lab DNS can never affect anything that matters.
The wildcard is the reason a subdomain is so tidy. A single *.home.example.com certificate covers nas.home.example.com, ha.home.example.com, and every future service under that label — one certificate, renewed automatically, for the whole lab. Note a wildcard only covers one level: *.home.example.com matches nas.home.example.com but not a.nas.home.example.com. In practice one flat level of hostnames is all a homelab needs, so this is rarely a constraint.
My one hard rule: do not use your primary email or business domain’s apex for lab experiments. If you fat-finger a DNS record or an ACME rate limit while learning, you want the fallout contained to a domain nothing depends on. Segment the domain the same way you would segment a VLAN — the lab gets its own space, walled off from anything you cannot afford to break.
Public Domain vs .local at a Glance
| Factor | Public domain (home.example.com) | .local |
|---|---|---|
| Free public certificates | Yes, via Let’s Encrypt DNS-01 | Never — banned since 2015 |
| Wildcard certificate | Yes, one covers all services | Not possible from a public CA |
| DNS behavior | Consistent unicast on every OS | Fights mDNS; per-OS inconsistency |
| Resolves internally only | Yes, via split-horizon DNS | Yes, but that is the problem |
| Ongoing cost | A domain registration (a few dollars/year) | Free, but costs you certificates |
| Setup effort | Register domain + local DNS records | Zero, then endless friction |
The Mistake That Cost Me a Month
I committed to .local early because it felt like the “proper” internal convention, and I named a dozen services under it before the cracks showed. The tell was sensory: I could hear myself sighing every time a dashboard hung for those few seconds before a name resolved, and I kept restarting my DNS server convinced it was the culprit. It never was. The resolver was fine; the namespace was cursed.
When I finally traced it to the multicast-versus-unicast collision, the fix was a rename — but a rename across a dozen services, their bookmarks, their reverse-proxy config, and every device’s muscle memory. That is the real cost of choosing .local: not that it fails loudly, but that it fails slowly, and unwinding it later is far more work than picking a real domain on day one. If you take one thing from this: register the domain first, before you name a single service.
Frequently Asked Questions
Can I use a domain I already own for my homelab instead of buying a new one?
Yes. The cleanest approach is a dedicated subdomain like home.example.com under a domain you already own, so a single wildcard certificate covers every service. Just avoid using the apex of a domain your email or business depends on, so a lab mistake cannot affect anything important.
Will a public domain expose my internal services to the internet?
No. With split-horizon DNS your internal resolver answers the names with private LAN addresses, and nothing is published or reachable from outside. Only the domain registration is public; the services and their IP addresses stay entirely inside your network.
Is .local ever the right choice for a homelab?
Rarely. The .local suffix is reserved for multicast DNS, so running a normal DNS zone on it causes slow and inconsistent lookups across devices, and public certificate authorities will never issue a certificate for it. If you want browser-trusted HTTPS with minimal effort, a real domain is the better choice almost every time.
What does split-horizon DNS actually mean?
Split-horizon DNS means the same domain name returns different answers depending on who is asking. Your internal resolver returns private LAN addresses for home.example.com, while the public internet gets no answer or a different one. This lets a public domain resolve only inside your network.
What I’d Do Starting Today
Register a cheap domain, or carve a home. subdomain off one you already own, before you name a single service. Add local A-records on your DNS resolver — and run two resolvers if you can, so name resolution survives a reboot — then point every service at a clean service.home.example.com name. That one afternoon of naming discipline unlocks free wildcard certificates and kills the mDNS conflict for good, and it is the foundation the rest of the certificate work stands on.
Further Reading
- Homelab Internal HTTPS Certificates: The Complete Guide
- Let’s Encrypt Wildcard Certs With DNS-01 for Internal Services
- Running Your Own Internal Certificate Authority With step-ca