Now that we’ve covered the theoretical intersection of DNS and HTTPS and the benefits that come from each, it’s time to plan a solid DNS strategy. Before you go spinning up containers or editing configuration files, you need a design.
In production environments, engineers don’t start typing - they start with a design. They decide on naming conventions, redundancy requirements, and scalability patterns. If you start adding records without a plan, you’ll eventually hit a wall - inconsistent naming, broken certificates, and fragile routing.
This is where theory turns into decisions. While reading, keep one thing in mind – you don’t need enterprise complexity, you need consistency and a system that’s simple to maintain.
Start With the End State
Start with the outcome and work backward. A well-designed DNS setup should achieve four things:
Clean Naming: You can guess a service’s URL without checking anything.
Flexibility: Moving a service requires changing one record, not ten bookmarks.
HTTPS Compatibility: Works seamlessly with automated certificate authorities.
Scalability: Works the same at 3 services or 300.
The Foundation: Using a Real Domain
The most important decision: use a real domain. Use a real domain you own. While it costs a few dollars a year, owning a public domain provides massive technical advantages:
Real Certificates: Public CAs will not issue certificates for .lan or .home.
Let’s Encrypt Integration: Certificate issuance and renewal can be fully automated.
Public/Private Split: You can isolate your lab under a dedicated subdomain.
Avoid using .local at all costs. The .local TLD is reserved for mDNS (Multicast DNS/Bonjour,) so if you try to use it for a standard DNS server, you’ll run into unpredictable resolution issues on macOS and Linux machines.
Naming Conventions
Next is defining a naming convention. There are two primary approaches – service-based and role-based.
Service-Based
This is the most intuitive approach. You name the DNS record after the software running on it:
- docmost.lab.domain.com
- portainer.lab.domain.com
- grafana.lab.domain.com This approach makes it incredibly clear what the service is, but breaks down if you frequently replace tools.
Role-Based
This approach focuses on function over implementation:
- docs.lab.domain.com
- containers.lab.domain.com
- monitoring.lab.domain.com
This makes it easy to swap out the underlying software without changing the URL you use to access it – but it’s slightly less obvious at a glance.
My Recommended Approach: A Records vs. CNAMEs
Hosts get A records. Services get CNAMEs. To keep your DNS structure clean, you should avoid pointing every single service directly to an IP address. Instead use a combination of A records and CNAMEs.
The “Host and Alias” Strategy
Create A records for your physical/virtual hosts:
- server01.lab.domain.com 192.168.122.10
- server02.lab.domain.com 192.168.122.20
Create CNAMEs for your services that point to those hosts:
- docmost.lab.domain.com server01.lab.domain.com
- portainer.lab.domain.com server01.lab.domain.com
- grafana.lab.domain.com server02.lab.domain.com
If server01’s IP address changes, you only need to update a single A record. All of the services (CNAMEs) pointing to that server will automatically follow it to the new IP, reducing change risk significantly.
Redundancy Matters: The “DNS Blackout”
DNS is a single point of failure. If your only DNS server crashes, your entire lab becomes unreachable by name. Running multiple DNS servers is not optional for a stable lab. Clients can be configured with primary and secondary DNS servers. If the primary doesn’t respond, they secondary takes over, ensuring that you aren’t locked out of your own lab because a BIND instance is experiencing an issue.
The Bigger Picture: DNS, Proxies, and HTTPS
DNS is just the directory - it tells you where to go. It tells the browser where the server is, but it doesn’t handle the traffic. At this point, you have the pieces needed to design your system: a real domain, a dedicated namespace with structured naming, a clean A/CNAME architecture, an understanding of the importance of high availability, and reason to integrate a reverse proxy and use HTTPS when ready. Once the design is clear, it’s time to build!
Access Your Homelab from Anywhere.
A good DNS design makes everything on top of it easier to manage, move, and trust. That becomes even more important when you start accessing your environment remotely.
Tools like Twingate depend on that foundation - see how this carries outside your network.
Understanding DNS Records
The Anatomy of DNS Zones: Roles and Functions
DNSSEC and DNS’ Fundamental Flaw