Names and certificates for a tailnet

Real DNS names and publicly-trusted certificates for your devices on Tailscale, Headscale, Netbird, ZeroTier or plain WireGuard. Included in the base plan.

Overlay networks solve connectivity and leave naming awkward. machine.tail1234.ts.net is hard to remember, tied to one vendor, and its certificates only work with that vendor's tooling. Names under your own label are memorable, trusted by every browser with no client configuration, and they survive you moving from Tailscale to Headscale to bare WireGuard.

1. Set the record

Overlay addresses are stable per device, so this is usually a one-time step and you do not need a DDNS client at all.

set an overlay address

curl -X POST https://api.home.network/v1/hostnames/:id/records \
  -H "Authorization: Bearer $HN_TOKEN" \
  -d '{"type":"A","content":"100.101.4.7","ttl":60}'

100.64.0.0/10 is the shared address space of RFC 6598, which Tailscale and Headscale assign from. Pointing a public name at one is the intended use here, not a mistake.

2. Get the certificate

Exactly the same acme-dns setup as anywhere else. The wildcard *.alice.home.network covers every device on your tailnet, and because issuance is wildcard-only, your device names never appear in Certificate Transparency logs.

Caddyfile

tls {
  dns acmedns {
    username   "6f1c..."
    password   "..."
    subdomain  "b2a4..."
    server_url "https://api.home.network/acmedns"
  }
}

3. Resolving on a phone but not on the tailnet

Some resolvers strip answers in the 100.64.0.0/10 range as rebind protection, and the stacks disagree about it. OPNsense filters the range by default, pfSense does not, and dnsmasq added it in version 2.92, which current OpenWrt ships. An overlay name that worked before an OpenWrt upgrade and fails afterwards is this change, not your configuration.

diagnose

# run both from the machine that cannot resolve it
dig +short nas.alice.home.network @1.1.1.1
dig +short nas.alice.home.network

# address from the first and nothing from the second means local filtering
# nothing from either means the record is missing, not filtered

Resolver	Exception
Unbound on OPNsense	Services → Unbound DNS → Advanced → Private Domains
Unbound on pfSense	private-domain: "alice.home.network"
dnsmasq on OpenWrt	add_list ... rebind_domain='alice.home.network'
FRITZ!Box	Network Settings → DNS Rebind Protection → Add Exception
Pi-hole, AdGuard Home	Nothing to change. Neither strips private answers

The clean setup for an all-Tailscale household

Add a tailnet split-DNS entry (a “restricted nameserver”) for alice.home.network pointing at ns1.home.network’s address. The authoritative server answers for its own zone directly, so you bypass every local rebind filter on every device at once, phones included, where resolver configuration is otherwise painful. Nothing else on your tailnet changes.

What we support, and what we do not

We support your records, the resolution path and certificate issuance. We do not support the overlay network itself: node connectivity, key expiry, ACLs and subnet routing belong to your VPN vendor or its community. Ask us about the first list and you get a fast answer from someone who runs it.