DNS for Self-Hosters: Subdomains, Records, and Split DNS

DNS is the layer that quietly decides whether your self-hosting project feels professional or accidental. Anyone can back a service with an IP, but the moment you configure a reverse proxy you also need stable hostnames, and that means real DNS: a domain you control, subdomains per service, correct A and AAAA records, and ideally split DNS so machines at home and on the go reach the same names. Getting these choices right up front saves you from a tangled mess of IP bookmarks and split-brain behavior later.

A Subdomain Per Service

The reverse proxy pattern in this series leans on one subdomain per service, and DNS should follow that plan exactly. Reserve each name early, before you need it, so the mapping is deliberate. A sensible scheme is a base domain like example.com with app.example.com, git.example.com, and notes.example.com, each an A record pointing at your edge IP — or an AAAA record if you run IPv6. Adding a service later is then just one DNS entry plus one proxy rule.

Wildcards Versus Explicit Records

A wildcard record like *.example.com is tempting because it future-proofs everything at once. The catch is that wildcards make mistakes invisible: a typo silently resolves and hits the same catch-all, and you lose the ability to gate specific subdomains with distinct records. For a homelab the pragmatic middle ground is an explicit record for every named service, plus one wildcard only if your proxy genuinely routes anything you add. Explicit beats magic when you are debugging.

Split DNS for Home and Away

The awkward case is a service that the outside world reaches through your public IP while your own devices reach the same name across the LAN. Without split DNS, internal clients often bounce traffic out to the internet and back (hairpin NAT), which adds latency and can break because some routers do not handle it. Split DNS lets your internal resolver answer the same name with the private IP while public resolvers answer with the public one.

# example: local resolver returns LAN address for a service
addn-hosts=/etc/dnsmasq.d/split.conf

# /etc/dnsmasq.d/split.conf
address=/app.example.com/192.168.1.10
address=/git.example.com/192.168.1.10

With dnsmasq (or a similar local resolver) serving these entries, devices pointed at your router's DNS get the internal address for those names and everything else resolves normally. Block the public route for those names at the firewall so the internal path is the only path.

Keep TTLs and Tutorials Sanity-Checked

DNS caches aggressively, so a TTL you set too high turns every change into a "why did it take four hours" incident. Keep TTL short (300 seconds is a common starting point) for records you expect to change while you are setting up, then relax them once stable. When you change an IP or move a service between hosts, waiting out the TTL before your clients see it is normal, not a fault.

A Records, AAAA Records, and Mail

Two record types deserve a moment each. An A record maps a name to an IPv4 address and an AAAA record to IPv6; publish both when your host has both, so clients on each stack reach you without guessing. If you ever receive mail on the domain, a couple of extra record types matter enormously: an MX record names your mail server, and SPF/DKIM/DMARC records tell other servers which hosts are allowed to send mail for you. Messing these up is how your outbound mail lands in spam even though the rest of DNS is perfect.

app.example.com.  A      203.0.113.10
app.example.com.  AAAA   2001:db8::10
example.com.      MX     10 mail.example.com.
example.com.      TXT    "v=spf1 mx -all"

That snippet is a realistic zone fragment: an A plus a matching AAAA for the service, an MX pointing mail at the mail subdomain, and an SPF record restricting senders. The habit is to add the mail-era records deliberately, not discover them after your first email bounces for everyone.

Takeaway

Design your DNS before your fleet grows: one subdomain per service, explicit records you can audit, and split DNS so home and away resolve cleanly. The result is a stack whose names are stable even when the underlying IPs move. Pair that durable naming with a Netbay VPS in Lucknow and re-point records rather than re-teach people IPs — provision it at netbayhosts.in.