f5cd320433
Initial documentation of the hubris Proxmox homelab as a cross-linked markdown wiki. Per-node pages, cross-cutting infrastructure pages, an investigation log, and an operations cheatsheet. Each node and topic ends with a Changelog section so changes can be tracked in-place going forward. Refreshed against live state on 2026-04-28 — 14 active LXCs (109 syncthing currently stopped) + 1 VM (108 haos). Reflects post-A/B-test state of the 2026-04-21 hubris crash-loop investigation.
87 lines
5.5 KiB
Markdown
87 lines
5.5 KiB
Markdown
# DNS — split-horizon `*.hubris.network`
|
|
|
|
LAN clients resolve `*.hubris.network` to the [Caddy reverse proxy](../containers/121-caddy.md) (`192.168.8.175`). Public clients resolve to the IONOS VPS (`82.165.190.79`) via an IONOS wildcard, where they hit the [VPS traefik public ingress](ingress.md).
|
|
|
|
There is **no wildcard on the LAN side**. Every subdomain needs an explicit entry.
|
|
|
|
## Components
|
|
|
|
- **Authoritative public DNS:** IONOS. `*.hubris.network → 82.165.190.79` (was `74.118.126.4` until 2026-04-22).
|
|
- **LAN authoritative for `hubris.network` records:** dnsmasq on [authentik (124)](../containers/124-authentik.md), `192.168.8.180:53` and `127.0.0.1:53`. Config at `/etc/dnsmasq.d/hubris-split.conf`. Forwards everything else to `1.1.1.1` and `8.8.8.8` (`no-resolv`, `server=...`).
|
|
- **PVE host** (`192.168.8.77`): resolver is the local Netbird daemon at `100.122.38.109:53`, which forwards to the LAN/upstream and learns hubris.network answers via that path. `netbird status` says "Nameservers: 0/0 Available" — confirming netbird does NOT manage a hubris.network zone; it just caches whatever the system resolver returns.
|
|
- **Some LXCs** keep router DNS (`192.168.8.1`) or Tailscale MagicDNS (`100.100.100.100`), both of which return the public IONOS A record. Those LXCs need either a `/etc/hosts` override or local dnsmasq — see [mesh migration](mesh.md) for which technique applies where.
|
|
|
|
## Live entries (as of 2026-04-28)
|
|
|
|
```
|
|
address=/auth.hubris.network/192.168.8.175
|
|
address=/git.hubris.network/192.168.8.175
|
|
address=/media.hubris.network/192.168.8.175
|
|
address=/paperless.hubris.network/192.168.8.175
|
|
address=/books.hubris.network/192.168.8.175
|
|
address=/home.hubris.network/192.168.8.175
|
|
address=/cloud.hubris.network/192.168.8.175
|
|
address=/matrix.hubris.network/192.168.8.175
|
|
address=/proxmox.hubris.network/192.168.8.175
|
|
address=/docker.hubris.network/192.168.8.175
|
|
address=/jellyseerr.hubris.network/192.168.8.175
|
|
address=/qbit.hubris.network/192.168.8.175
|
|
address=/sab.hubris.network/192.168.8.175
|
|
address=/blog.hubris.network/192.168.8.175
|
|
address=/photos.hubris.network/192.168.8.175
|
|
address=/artifacto.hubris.network/192.168.8.175
|
|
```
|
|
|
|
## Why split-horizon
|
|
|
|
The IONOS wildcard points at the VPS for public ingress (per-host routers in [VPS traefik](ingress.md)). The VPS only routes hostnames it knows — anything else 404s. So LAN clients pointing at the public IP are a dead end for any service that isn't explicitly published. The dnsmasq override on LXC 124 keeps LAN traffic on the home Caddy.
|
|
|
|
## The gotcha that cost a debug session (2026-04-22)
|
|
|
|
Creating a new Caddyfile site block is necessary but **not sufficient**. Without the LXC-124 dnsmasq entry, LAN queries fall through to upstream, get the public IONOS answer, and time out. Symptom: "subdomain doesn't load" even though Caddy config + cert are fine.
|
|
|
|
## Recipe — adding a new subdomain
|
|
|
|
1. Edit `/etc/caddy/Caddyfile` on [caddy (121)](../containers/121-caddy.md), commit + push to `dtoro/caddy-conf`. Webhook reloads caddy. See [auto-deploy](auto-deploy.md).
|
|
2. Append to `/etc/dnsmasq.d/hubris-split.conf` on [authentik (124)](../containers/124-authentik.md):
|
|
```
|
|
address=/<new>.hubris.network/192.168.8.175
|
|
```
|
|
3. `pct exec 124 -- systemctl restart dnsmasq` — reload/SIGHUP may not pick up the new `address=` line; hard restart is the reliable path.
|
|
4. Verify: `dig @192.168.8.180 +short <new>.hubris.network` → `192.168.8.175`.
|
|
5. On macOS clients, flush: `sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder`.
|
|
|
|
> The dnsmasq config is **not** tracked in git. If you stand up a `dtoro/dnsmasq-conf` repo, wire it like `caddy-conf` (webhook on LXC 124).
|
|
|
|
## Public path — what does and doesn't follow the LAN map
|
|
|
|
- Hostnames published in [VPS traefik dynamic config](ingress.md) (currently `artifacto.hubris.network`, `blog.hubris.network`) reach a real backend over the netbird mesh.
|
|
- Anything else with a `*.hubris.network` URL hits the VPS but isn't routed anywhere — returns 404.
|
|
- `netbird.hubris.network` is its own thing — TCP passthrough at the VPS, served by netbird-proxy. Doesn't follow the file-provider router pattern.
|
|
|
|
## Long-term plan
|
|
|
|
Either:
|
|
- Move split-horizon DNS to the LAN router so `*.hubris.network → 192.168.8.175` is answered for every LAN client. Eliminates per-LXC overrides.
|
|
- Or, once the [Tailscale → Netbird migration](mesh.md) completes, every LXC's resolver becomes the netbird daemon, which already learns hubris.network answers via the system resolver chain.
|
|
|
|
## Related
|
|
- [Caddy (121)](../containers/121-caddy.md) — every LAN entry points here
|
|
- [Ingress (VPS traefik)](ingress.md) — public-side counterpart
|
|
- [Mesh migration](mesh.md) — per-LXC DNS workarounds during the transition
|
|
- [Authentik (124)](../containers/124-authentik.md) — host of the split-horizon dnsmasq
|
|
|
|
## Changelog
|
|
|
|
### 2026-04-28 — wiki entry created
|
|
Initial documentation. 16 active entries.
|
|
|
|
### 2026-04-22 — IONOS wildcard moved 74.118.126.4 → 82.165.190.79
|
|
Public path now lands on the VPS traefik, not the old yunohost. Necessary for the [public ingress](ingress.md) pattern. The LAN dead-end semantics didn't change — public DNS still doesn't help LAN clients reach LAN-only services.
|
|
|
|
### 2026-04-22 — three caddy sites without DNS entries (jellyseerr, qbit, sab)
|
|
Caddy + certs were working but LAN resolution failed because the dnsmasq lines weren't added. Lesson recorded; entries added later that day.
|
|
|
|
### 2026-04-21 — dnsmasq stood up on LXC 124
|
|
Co-located with Authentik. Initial entries cover everything routed through Caddy.
|