headscale DNS: decide names, certificates and cutover behavior for tailnet aliases #242

Open
opened 2026-10-16 17:14:45 -04:00 by jfraeys · 2 comments
Owner

Follow-up to the research issue #213. Decisions needed before records are written.

Questions

  1. Names. <node>.ts.jfraeys.com exists already (MagicDNS). Do aliases live under it (git.ts.jfraeys.com) or in a separate suffix? .local is out (mDNS); .internal has no public certificates.
  2. Certificates. Traefik can get Let's Encrypt certificates for a name under jfraeys.com through the DNS challenge, even if the name only resolves on the tailnet. Do any tailnet-only services need browser-trusted TLS, or is the WireGuard tunnel enough?
  3. The OVH cutover. MagicDNS names follow the Headscale node name. After the name swap in docs/runbooks/provider-migration-ovh.md (services and web become the OVH nodes) services.ts.jfraeys.com points at the OVH node automatically. Aliases with fixed tailnet IPs would not. Prefer aliases that are CNAMEs to node names, or generated from the inventory, over hardcoded addresses.
  4. The move from Cloudflare to deSEC. If tailnet-only names sit under jfraeys.com, the DNS-01 challenge provider changes with it; confirm the challenge still works for them.
  5. Servers resolving names. Servers run with --accept-dns=false. Turning it on lets them resolve each other, but override_local_dns: true would send all their lookups through 1.1.1.1; decide whether that is acceptable or whether split DNS (only ts.jfraeys.com) is enough.
  6. Resilience. Headscale is the resolver for tailnet names. If it is down the tunnels keep working but new names stop resolving on clients that restart. Acceptable for now?
  7. Homelab later. The homelab will want wildcard records and probably its own resolver (AdGuard Home / Technitium / dnsmasq) with Tailscale split DNS pointing only the private suffix at it. Keep the suffix choice compatible with that.

Output

A short decision recorded here (suffix, which services get aliases, alias form, whether servers accept DNS), then the implementation issue.

Follow-up to the research issue #213. Decisions needed before records are written. ## Questions 1. **Names.** `<node>.ts.jfraeys.com` exists already (MagicDNS). Do aliases live under it (`git.ts.jfraeys.com`) or in a separate suffix? `.local` is out (mDNS); `.internal` has no public certificates. 2. **Certificates.** Traefik can get Let's Encrypt certificates for a name under `jfraeys.com` through the DNS challenge, even if the name only resolves on the tailnet. Do any tailnet-only services need browser-trusted TLS, or is the WireGuard tunnel enough? 3. **The OVH cutover.** MagicDNS names follow the Headscale node name. After the name swap in `docs/runbooks/provider-migration-ovh.md` (`services` and `web` become the OVH nodes) `services.ts.jfraeys.com` points at the OVH node automatically. Aliases with fixed tailnet IPs would not. Prefer aliases that are CNAMEs to node names, or generated from the inventory, over hardcoded addresses. 4. **The move from Cloudflare to deSEC.** If tailnet-only names sit under `jfraeys.com`, the DNS-01 challenge provider changes with it; confirm the challenge still works for them. 5. **Servers resolving names.** Servers run with `--accept-dns=false`. Turning it on lets them resolve each other, but `override_local_dns: true` would send all their lookups through 1.1.1.1; decide whether that is acceptable or whether split DNS (only `ts.jfraeys.com`) is enough. 6. **Resilience.** Headscale is the resolver for tailnet names. If it is down the tunnels keep working but new names stop resolving on clients that restart. Acceptable for now? 7. **Homelab later.** The homelab will want wildcard records and probably its own resolver (AdGuard Home / Technitium / dnsmasq) with Tailscale split DNS pointing only the private suffix at it. Keep the suffix choice compatible with that. ## Output A short decision recorded here (suffix, which services get aliases, alias form, whether servers accept DNS), then the implementation issue.
Author
Owner

Constraint (operator, 2026-10-16): Traefik stays the reverse proxy, here and for the homelab later; no Caddy or other proxy. What follows from it: (1) certificates for private names come from Traefik's DNS-01 resolver; the repo already supports the cloudflare and desec resolvers (traefik_certresolver), so a name under jfraeys.com can get a Let's Encrypt certificate even if it only resolves on the tailnet, and the move to deSEC only changes the resolver. (2) A homelab wildcard such as *.home.jfraeys.com is one DNS-01 certificate on one Traefik. (3) If Cloudflare proxying ever returns, Authenticated Origin Pulls are a Traefik tlsOption per router (FUTURE_IMPROVEMENTS.md), not a network rule.

Constraint (operator, 2026-10-16): Traefik stays the reverse proxy, here and for the homelab later; no Caddy or other proxy. What follows from it: (1) certificates for private names come from Traefik's DNS-01 resolver; the repo already supports the cloudflare and desec resolvers (traefik_certresolver), so a name under jfraeys.com can get a Let's Encrypt certificate even if it only resolves on the tailnet, and the move to deSEC only changes the resolver. (2) A homelab wildcard such as *.home.jfraeys.com is one DNS-01 certificate on one Traefik. (3) If Cloudflare proxying ever returns, Authenticated Origin Pulls are a Traefik tlsOption per router (FUTURE_IMPROVEMENTS.md), not a network rule.
Author
Owner

Related 2026-10-17: access to the tailnet is being tightened (tracking issue #251): admin devices come from headscale_admin_users, other devices reach web:443 only. Aliases for tailnet services should therefore be decided with that in mind: an alias for an admin port is only reachable from admin devices.

Related 2026-10-17: access to the tailnet is being tightened (tracking issue #251): admin devices come from headscale_admin_users, other devices reach web:443 only. Aliases for tailnet services should therefore be decided with that in mind: an alias for an admin port is only reachable from admin devices.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
jfraeys/infra#242
No description provided.