# DNS / Tailscale / TLS Design Slice

Date: 2026-06-07

## User decisions captured

- First slice: design/spec first, before mutating infrastructure.
- Internal DNS direction: dedicated DNS service, not ad hoc per-service exceptions forever.
- TLS question: reverse proxy is desired/acceptable as the central TLS/routing component.

## Clarification: reverse proxy vs certificates

A reverse proxy is part of the TLS solution, but it is not the whole certificate/trust solution.

- **DNS** decides where names such as `vw.dropcutstud.io` point.
- **Reverse proxy** accepts HTTPS for those names and routes traffic to backend services.
- **Certificate authority / issuance method** decides whether browsers trust those HTTPS certificates.

Recommended model: dedicated DNS service points service names at a central Nginx reverse proxy; Nginx terminates TLS and proxies to backend services.

## Target architecture

### Components

1. **Dedicated internal DNS service**
   - Proxmox LXC preferred.
   - Candidate products: Technitium DNS, AdGuard Home, Pi-hole + Unbound/CoreDNS.
   - Purpose: authoritative/internal override records for homelab service names.
   - Initial zone/records: `dropcutstud.io` service records used internally.

2. **Central Nginx reverse proxy service**
   - Proxmox LXC preferred unless compatibility requires a VM.
   - Receives LAN/Tailscale HTTPS traffic on 443.
   - Routes by hostname to internal backend IP:port.
   - No public port forwarding by default.

3. **Backend services**
   - Vaultwarden remains on VM 102 at `192.168.0.238`, service bound behind its local Nginx/bootstrap setup for now.
   - SearxNG remains on LXC 103 at `192.168.0.133:8080`.
   - Nextcloud remains on VM at `192.168.0.110:8080`.
   - Nimrod LXC remains LAN/admin-only; no public web service by default.

4. **Tailscale**
   - Tailscale should provide remote private access, not public exposure.
   - Long-term goal: Tailscale clients use the same service names where practical.
   - Likely method: configure Tailscale DNS settings to use the internal DNS service for `dropcutstud.io`, or run the DNS service on a Tailscale-reachable node.

## Naming convention

Use simple service names under `dropcutstud.io`:

- `vw.dropcutstud.io` -> Vaultwarden
- `search.dropcutstud.io` -> SearxNG
- `nc.dropcutstud.io` -> Nextcloud
- `nimrod.dropcutstud.io` -> Nimrod admin/service name if/when exposed beyond SSH
- `proxy.dropcutstud.io` -> reverse proxy host/admin reference if needed
- `dns.dropcutstud.io` -> internal DNS service admin reference if needed

Default exposure: LAN + Tailscale only.

## DNS model

### MVP

- Deploy a dedicated internal DNS service.
- Add service records as A/AAAA records or local overrides.
- LAN DHCP/router should hand out the dedicated DNS service as resolver, either directly or via OPNsense forwarding.
- Service names that are routed through the central reverse proxy should resolve to the reverse proxy IP.
- Service names that remain direct/backdoor admin endpoints may resolve directly to backend IPs, but this should be documented.

### Recommended service record pattern

For proxied web apps:

```text
vw.dropcutstud.io      -> <reverse-proxy LAN IP>
search.dropcutstud.io  -> <reverse-proxy LAN IP>
nc.dropcutstud.io      -> <reverse-proxy LAN IP>
```

For infrastructure/admin endpoints that should not be proxied:

```text
nimrod.dropcutstud.io  -> 192.168.0.222  # if approved
pve.dropcutstud.io     -> 192.168.0.88   # optional; management-sensitive
```

## TLS approach options

### Option A — Internal CA MVP

Create a private homelab CA and install the root CA on trusted/admin devices.

Pros:
- Works without public DNS provider automation.
- Good for LAN-only services.
- Compatible with Nginx.

Cons:
- Every trusted device must trust the CA.
- Mobile/client trust setup can be tedious.
- Needs careful CA private-key storage.

### Option B — Let's Encrypt DNS-01

Use DNS API credentials to issue publicly trusted certificates for internal names without exposing services.

Pros:
- Browser trust works automatically.
- Clean long-term UX.

Cons:
- Requires DNS provider/API automation and careful secret handling.
- User previously deferred DNS provider automation.

### Option C — Tailscale certs

Use Tailscale certificates for tailnet names.

Pros:
- Nice for Tailscale-only hostnames.
- Avoids public exposure.

Cons:
- Does not directly solve `dropcutstud.io` LAN names.
- Less suitable as the only homelab naming/TLS standard.

## Recommendation

Use this phased plan:

1. **Design/approve central architecture** — this artifact.
2. **Deploy reverse proxy LXC** with Nginx and a temporary/internal CA certificate path.
3. **Deploy dedicated DNS service** or decide exact product first, then point one service name at the reverse proxy.
4. **First proxied service:** SearxNG or Vaultwarden.
   - SearxNG is lower risk.
   - Vaultwarden is higher value but backup/restore is now verified.
5. **Choose final cert method:**
   - MVP: internal CA.
   - Long-term preferred if DNS provider automation is acceptable: Let's Encrypt DNS-01.
6. **Integrate Tailscale DNS** after LAN DNS works.

## Suggested first implementation slice

Deploy central Nginx reverse proxy LXC and proxy SearxNG first:

- New LXC: `reverse-proxy`.
- No public exposure.
- LAN IP by DHCP initially; later reserve/static.
- Nginx route: `search.dropcutstud.io` -> `http://192.168.0.133:8080`.
- TLS: temporary self-signed or internal-CA certificate for MVP.
- DNS: add `search.dropcutstud.io` record pointing to reverse-proxy IP in the chosen dedicated DNS service once available.

Alternative if DNS service must come first: deploy Technitium DNS LXC, create records, then deploy reverse proxy.

## Open decisions before implementation

- Which dedicated DNS product should be used?
  - Recommendation to evaluate first: Technitium DNS for full DNS-server features and web UI.
  - Simpler ad-blocking-oriented alternatives: AdGuard Home or Pi-hole.
- Should reverse proxy and DNS be separate LXCs?
  - Recommendation: separate, because DNS is foundational and reverse proxy is app-routing.
- Should the first proxied service be SearxNG or Vaultwarden?
  - Recommendation: SearxNG first for low-risk proxy/TLS smoke test.
- Should MVP certificates be internal CA or self-signed-per-service?
  - Recommendation: internal CA if the user is willing to install trust on clients; self-signed only for temporary testing.

## Safety notes

- Do not expose services publicly without explicit approval.
- Do not move Vaultwarden behind a new proxy until current access is verified and rollback is clear.
- DNS changes can break access; keep direct IP fallback documented during transition.
- Reverse proxy should have backup/runbook/update expectations before being considered standard.