DNS Records for a Homelab Domain: A/CNAME Setup Explained
12 min read
2,212 words
What Are the Essential DNS Records for a Homelab Domain?
If you’re running self-hosted apps like Plex, Nextcloud, or a personal wiki from home, DNS records are how the rest of the internet (and your local network) finds them. The two most common record types you’ll use are A records (which point a domain or subdomain to an IP address) and CNAME records (which alias one domain to another). For a homelab domain DNS setup, you typically need a mix of both—plus a wildcard record to save yourself from adding a new entry every time you spin up a container. This guide walks you through exactly which records to create, how to handle public vs. local DNS, and the common mistakes that trip up beginners. This guide breaks down dns records for homelab domain in practical terms.
This guide assumes you already own a domain name (e.g., yourlab.com) and have it pointed to a DNS provider like Cloudflare, Namecheap, or your own authoritative server. If you don’t have a domain yet, grab one—it costs $8–$15/year and makes remote access much cleaner than typing an IP address.
DNS Record Types Every Homelabber Needs
Before you start adding records, you need to understand what each type does and when to use it. The wrong choice can break your reverse proxy, SSL certificate renewal, or internal routing.
A Record vs CNAME for Homelab Subdomains
An A record maps a hostname directly to an IPv4 address. For example, plex.yourlab.com → 203.0.113.5. A CNAME record maps a hostname to another hostname, like plex.yourlab.com → yourlab.com. The CNAME then relies on the A record of the target to resolve the IP.
| Record Type | What It Does | Best For |
|---|---|---|
| A Record | Points a hostname to an IP address | Your root domain, your reverse proxy’s public IP, or any service with a fixed IP |
| CNAME Record | Points a hostname to another hostname | Subdomains that should follow the same IP as another record (e.g., all apps behind a single reverse proxy) |
| Wildcard Record | Matches any subdomain not explicitly defined | Automatically handling new app subdomains without manual DNS entries |
For a homelab domain DNS setup, the best practice is to use one A record for your reverse proxy’s public IP (or Cloudflare Tunnel endpoint) and then use CNAME records (or a wildcard CNAME) for every app subdomain. This keeps your DNS clean and makes IP changes trivial—you update one A record, and all CNAMEs follow.
Never point a CNAME to your root domain’s A record if the root domain also has other record types (MX, TXT, etc.). DNS standards say CNAMEs cannot coexist with other records at the same name. Instead, create a dedicated A record like proxy.yourlab.com and point all app CNAMEs to that.
Wildcard Records: The Homelab Time-Saver
A wildcard DNS record—written as *.yourlab.com—matches every subdomain that doesn’t have an explicit record. If you add *.yourlab.com as a CNAME pointing to proxy.yourlab.com, then nextcloud.yourlab.com, jellyfin.yourlab.com, and grafana.yourlab.com all resolve automatically without individual entries.
This is a huge win when you’re experimenting with Docker containers. Spin up a new service, configure your reverse proxy to listen for that subdomain, and it works immediately—no waiting for DNS propagation.
Public DNS vs Local/Split DNS: Which Should You Use?
When setting up DNS for self-hosted apps, you have two name resolution paths to manage: the public internet and your local network. How you handle both determines whether your services work seamlessly from inside and outside your home.
Public DNS: Pointing to Your Reverse Proxy or Tunnel
For remote access, your public DNS records (managed by your domain registrar or a service like Cloudflare) must point to an address reachable from the internet. You have two main options:
Direct Reverse Proxy
- Your A record points to your home’s public IP (e.g.,
proxy.yourlab.com→203.0.113.5) - You need port forwarding (80/443) on your router
- SSL certificates validate against your domain
Cloudflare Tunnel
- Your A record points to Cloudflare’s tunnel endpoint (e.g.,
*.yourlab.com→ CNAME toyour-tunnel-id.cfargotunnel.com) - No port forwarding needed
- Cloudflare handles SSL termination automatically
Both approaches work, but the tunnel method is safer for beginners because it hides your home IP and eliminates open ports. If you go the direct route, make sure your reverse proxy (Nginx Proxy Manager, Traefik, Caddy) handles SSL certificates via Let’s Encrypt or Cloudflare Origin CA.
Local/Split DNS: Keeping Traffic on Your LAN
Without local DNS, when you access plex.yourlab.com from inside your home, your request goes out to the public DNS, resolves to your public IP, then routes back in through your router—a “hairpin” that adds latency and can break on some ISP gateways. The fix is split DNS (also called split-horizon DNS): configure your local router or DNS server (Pi-hole, AdGuard Home, Unbound) to resolve your domain’s subdomains to your reverse proxy’s local LAN IP (e.g., 192.168.1.10) instead of the public IP.
On your local DNS server, add A records for each subdomain pointing to your proxy’s LAN IP. Or use a wildcard: *.yourlab.com → 192.168.1.10.
Configure your router to hand out your local DNS server’s IP via DHCP. Clients will query it first for your domain and fall back to public DNS for everything else.
Run nslookup plex.yourlab.com from a local machine. It should return your LAN IP, not your public IP.
Split DNS also simplifies SSL certificate renewal. Your reverse proxy can validate against the public DNS (which always resolves to your public IP or tunnel), while local clients use the LAN IP. As long as your proxy serves the same certificate to both paths, there’s no conflict. Just ensure your local DNS never serves stale records that break the ACME challenge.
Connecting DNS to Your Reverse Proxy’s SSL Certificates
SSL certificate issuance (via Let’s Encrypt) relies on DNS working correctly. When your reverse proxy requests a certificate for nextcloud.yourlab.com, it must prove domain ownership. The two common validation methods are:
- HTTP-01 challenge: The CA (Certificate Authority) accesses
http://nextcloud.yourlab.com/.well-known/acme-challenge/and expects a specific token. This requires the domain to resolve to your proxy’s public IP at validation time. - DNS-01 challenge: The CA looks for a specific TXT record in your domain’s DNS zone. This works even if your proxy is behind a firewall or NAT, but requires your DNS provider to support API-based record updates.
For homelabs, DNS-01 is more reliable because it doesn’t depend on your home network being reachable during renewal. Cloudflare, Namecheap, and many registrars support this via API tokens. You configure your reverse proxy (or a tool like acme.sh) to automatically add and remove the TXT record during validation.
If you use a wildcard certificate (e.g., *.yourlab.com), you must use DNS-01 validation. HTTP-01 cannot validate wildcard domains because the CA only checks the exact hostname, not subdomains under it.
Common Beginner Mistakes in Homelab DNS Setup
Even experienced homelabbers trip over these issues. Here’s what to watch for:
Forgetting to Update DNS After a Public IP Change
Most residential ISPs change your public IP periodically. If you’re using a direct A record pointing to your home IP, that record becomes stale the moment your IP changes. Your apps appear offline externally. The fix is either using a dynamic DNS client (ddclient, Cloudflare DDNS) that automatically updates your A record, or switching to a Cloudflare Tunnel which uses a static tunnel endpoint regardless of your home IP.
If your ISP changes IPs frequently, consider routing through a cheap VPS as a reverse proxy—your home server connects to it via WireGuard, and the VPS holds a static IP. This adds roughly $5/month but eliminates IP-change headaches.
TTL Confusion During Testing
DNS records have a Time-To-Live (TTL) value—how long resolvers cache the record before re-querying. If you change a record and expect instant results but your local machine still resolves the old IP, you’re hitting cached data. Common TTL mistakes:
- Default TTL too high: Many registrars set TTL to 3600 seconds (1 hour) or more. During testing, lower it to 60–120 seconds so changes propagate quickly.
- Local DNS cache: Your browser, OS, and router all cache DNS separately. Run
ipconfig /flushdns(Windows),sudo dscacheutil -flushcache(macOS), orsudo systemd-resolve --flush-caches(Linux) after changes. - Browser cache: Chrome and Firefox cache DNS too. Open a private/incognito window or clear the browser cache to force a fresh lookup.
Mixing CNAMEs with Other Records at the Same Name
As mentioned earlier, a CNAME record cannot coexist with any other record type (A, MX, TXT, etc.) at the same hostname. If you try to add a CNAME for mail.yourlab.com but already have an MX record there, the DNS zone will reject the CNAME. Always check for conflicts before adding a new CNAME.
Which DNS Approach Should You Choose for Your Homelab?
The best homelab domain DNS setup depends on your comfort level with networking and how many services you run. Here’s the bottom-line recommendation:
Simple Setup (Beginner)
- Use Cloudflare as your DNS provider
- Create one A record for your tunnel endpoint (not your home IP)
- Add a wildcard CNAME (
*.yourlab.com) pointing to your tunnel - Set up Cloudflare Tunnel on your reverse proxy
- Enable local split DNS via Pi-hole or your router to avoid hairpin routing
Advanced Setup (DIY)
- Run your own authoritative DNS server (BIND, PowerDNS) on a VPS or Raspberry Pi
- Use A records for your proxy’s public IP with dynamic DNS updates
- Create individual CNAMEs for each app (or wildcard if you prefer)
- Implement split DNS with Unbound for local resolution
- Use DNS-01 validation for wildcard SSL certificates
For 90% of homelab users, the simple Cloudflare Tunnel path is the right call. It costs nothing extra, eliminates public IP tracking, and handles SSL certificates automatically. As you grow, you can migrate to a more custom setup without breaking your existing subdomains.
Your DNS setup directly impacts your power bill if you’re running a separate DNS server 24/7. A Raspberry Pi 4 running Pi-hole or Unbound draws about 3–5W, adding roughly $3–$6/year at average electricity rates. If you already have a NAS or server running, just run DNS as a Docker container on that hardware instead—check our guide on reducing NAS power consumption to keep the total draw low.
Frequently Asked Questions
What’s the difference between an A record and a CNAME?
An A record maps a hostname directly to an IPv4 address—for example, proxy.yourlab.com → 192.168.1.10. A CNAME record maps a hostname to another hostname, like plex.yourlab.com → proxy.yourlab.com. The CNAME then follows the A record of the target to get the final IP. Use A records for your core infrastructure (reverse proxy, tunnel endpoint) and CNAMEs for individual app subdomains. This way, if your proxy’s IP changes, you update one A record and all CNAMEs automatically resolve to the new address.
Do I need a real domain to self-host apps at home?
Yes, for production-like remote access and valid SSL certificates. While you can use a free subdomain from services like DuckDNS or a local-only setup with self-signed certificates, a real domain ($8–$15/year) gives you control over DNS records, wildcard certificates, and professional-looking URLs. It also simplifies reverse proxy configuration because you can use a reliable DNS provider with API access for automated SSL renewal. For local-only testing, a fake domain like .home.arpa works, but it won’t get publicly trusted SSL certificates.
What is a wildcard DNS record and why does it help?
A wildcard DNS record—written as *.yourlab.com—matches any subdomain that doesn’t have an explicit record. If you create a wildcard CNAME pointing to your reverse proxy, then every new app subdomain (e.g., homeassistant.yourlab.com, gitea.yourlab.com) resolves automatically without adding individual DNS entries. This is a huge time-saver when you’re experimenting with Docker containers. Just configure your reverse proxy to accept any subdomain and route based on the hostname, and you never touch DNS again for new services.
Why isn’t my new subdomain working after I added it?
Most often, it’s DNS caching. Even after adding the record, your local machine, router, and browser may still resolve the old data. First, flush your local DNS cache (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS). Then check the record’s TTL—if it’s set to 3600 seconds, wait up to an hour for full propagation. Use a tool like nslookup or dig to query your DNS provider directly (e.g., dig @8.8.8.8 newapp.yourlab.com) to see the authoritative answer. If that works but local resolution doesn’t, your split DNS configuration may be missing the new subdomain or overriding it with a stale entry.
Last verified: July 10, 2026. DNS record behavior based on RFC 1035 and RFC 2181. Cloudflare Tunnel and Let’s Encrypt ACME validation confirmed against current documentation.
🛡 Shop Recommended Hardware
Prices and stock verified regularly by our affiliate partners. As an affiliate, HomeLabCost may earn a commission on qualifying purchases at no extra cost to you.
Browse Hardware Picks →
homelabcost
HomeLabCost editor covering NAS builds, hardware selection, and homelab server setup guides.