af45c30167
Candidate-zone CNAMEs and Unbound local names for dex./head. under domain2, the public-record helper and Dex LDAP env test, plus the matching docs. This work predates this session and went live with the 2026-09-14 switch on pinix. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JGodmgtRqahbT52gApsM8N
127 lines
6.8 KiB
Markdown
127 lines
6.8 KiB
Markdown
# BIND auf pinix: autoritativer DNS fuer lukasrosier.com
|
|
|
|
## Ziel und Aufteilung
|
|
|
|
Nokia stellt Mobilfunk bereit, Mango LAN/Firewall und feste Weiterleitungen,
|
|
pinix autoritativen DNS, Traefik und Anwendungen. Kein externer DNS-Server
|
|
als geplanter Pflichtbestandteil. Registrar und oeffentliche DNS-Hierarchie
|
|
bleiben erforderlich.
|
|
|
|
**Die Zone ist seit 12.09.2026 `lukasrosier.com` (`config.domain2`), nicht
|
|
mehr `0ff.space`.** Grund ist die Aufteilung der beiden Domains:
|
|
|
|
- `0ff.space` bleibt vollstaendig bei Cloudflare und auf blunix. Dort haengen
|
|
XMPP-Foederation und ActivityPub dran; ein DNS-Ausfall kostet dort sofort
|
|
Identitaets- und Foederationszustand, der sich nicht nachholen laesst.
|
|
- `lukasrosier.com` ist der Kandidat, der wirklich delegiert werden kann, und
|
|
damit die Probe fuer den Cloudflare-Ausstieg auf einer Domain, deren
|
|
Ausfall reparabel ist.
|
|
|
|
**Folgenlos ist diese Zone trotzdem nicht.** Sie traegt MX, SPF und DKIM fuer
|
|
Zoho-Mail. Faellt der autoritative Server aus, scheitert die Zustellung
|
|
eingehender Mail -- mildernd ist nur, dass sendende MTAs ueber Tage
|
|
wiederholen, waehrend Foederationsprotokolle sofort degradieren. Wer diese
|
|
Zone delegiert, haengt seine Mailzustellung an die Verfuegbarkeit von pinix,
|
|
dem Mango und dem Mobilfunkanschluss.
|
|
|
|
## Konfiguration
|
|
|
|
- `hosts/pinix/localServices/bind.nix`: autoritativer BIND auf TCP/UDP 53.
|
|
Keine Rekursion, keine fremden Cache-Abfragen, keine Zonenuebertragung,
|
|
keine dynamischen Updates.
|
|
- `listenOnIpv6` ist ausdruecklich **nicht** `"any"`, sondern `::1` plus
|
|
`config.lanIPv6.pinix`. Mit `any` band BIND auch die Tailnet-Adresse und
|
|
jede Link-Local-Adresse; das diente nichts und kollidiert mit dem
|
|
rekursiven Resolver fuer Tailnet-Clients (`unbound.nix`), der denselben
|
|
Port braucht.
|
|
- `networking.resolvconf.useLocalResolver = false` ist zwingend: pinix
|
|
behaelt Mango/DNS64 als eigenen Resolver. Ein autoritativer Server ohne
|
|
Rekursion kann den nicht ersetzen, und ueber DNS64 laeuft pinix' einziger
|
|
Weg zu IPv4-only-Hosts (blunix, Forgejo) per NAT64.
|
|
- `dns/lukasrosier.com.zone`: Inhalt am 12.09.2026 aus der **Cloudflare-API**
|
|
uebernommen, nicht aus oeffentlichen Abfragen. Alle A-Eintraege stehen dort
|
|
auf `proxied=true`, eine oeffentliche Abfrage liefert also Cloudflares
|
|
Edge-Adressen statt des Origins; ein Snapshot aus dem Public View haette
|
|
die Zone auf Cloudflares Proxy zeigen lassen. Die beiden NS-Eintraege auf
|
|
`dns1/dns2.registrar-servers.com` sind nicht uebernommen -- Altlast, die
|
|
der tatsaechlichen Delegation widerspricht.
|
|
- `scripts/configure-mango-dns.sh`: feste IPv6-DNAT-Regel fuer TCP/UDP 53 zu
|
|
pinix, angewandt und geprueft.
|
|
|
|
## Stand 12.09.2026
|
|
|
|
Aktiv auf pinix, Zone wird lokal und oeffentlich beantwortet. Geprueft gegen
|
|
die LAN-ULA und von aussen ueber die Mango-Weiterleitung:
|
|
|
|
| Pruefung | Ergebnis |
|
|
|---|---|
|
|
| SOA / NS | `ns1.lukasrosier.com`, Serial 2026091201 |
|
|
| Apex, `www`, `data` | `23.88.33.137` -- der Origin, nicht Cloudflares Edge |
|
|
| Wildcard | deckt `cal.lukasrosier.com` ab, fuer das es keinen eigenen Eintrag gibt |
|
|
| MX | alle drei Zoho-Eintraege mit Prioritaet 10/20/50 |
|
|
| SPF | zeichengleich mit Cloudflare |
|
|
| DKIM (`zmail._domainkey`) | zeichengleich mit Cloudflare, 232 Zeichen |
|
|
| Rekursion fuer fremde Namen | `REFUSED` -- kein offener Resolver |
|
|
| AXFR | `REFUSED`, `Transfer failed` |
|
|
| `0ff.space` | `REFUSED` -- pinix beansprucht die Domain nicht mehr |
|
|
| Reboot | BIND kommt hoch, `resolv.conf` bleibt Mango (docs/pinix-reboot-probe.md) |
|
|
|
|
Die Delegation liegt unveraendert bei Cloudflare
|
|
(`chin/sevki.ns.cloudflare.com`). Der Kandidat ist oeffentlich erreichbar,
|
|
ohne dass eine Domain von ihm abhaengt.
|
|
|
|
## Vor einer Delegation zu loesen
|
|
|
|
1. **ACME auf blunix umstellen.** `website.nix` und `traefik/cal.nix` holen
|
|
ihre Zertifikate fuer diese Domain per `certResolver = "cloudflare"`, also
|
|
DNS-01 ueber die Cloudflare-API. Nach der Delegation schreibt dieser
|
|
Challenge TXT-Eintraege in eine Zone, die Cloudflare nicht mehr bedient --
|
|
die Erneuerung scheitert dann still, erst rund 60 Tage spaeter sichtbar.
|
|
Entweder auf HTTP-01 umstellen (blunix ist auf 80 oeffentlich erreichbar,
|
|
und fuer Apex/`www`/`cal` braucht es keinen Wildcard) oder RFC2136/TSIG
|
|
gegen diesen Server einrichten, Rechte auf `_acme-challenge` begrenzt,
|
|
Schluessel per agenix.
|
|
2. **IPv4-Erreichbarkeit des Nameservers.** Das ist bei *dieser* Zone kein
|
|
Randthema, sondern der harte Punkt: pinix ist oeffentlich IPv6-only. Ein
|
|
sendender MTA in einem IPv4-only-Netz kann dann den MX-Eintrag gar nicht
|
|
aufloesen und die Mail scheitert dauerhaft. Gegenmittel ist ein
|
|
Sekundaerer auf einer IPv4-Adresse -- blunix ist die einzige weitere
|
|
dauerhaft laufende Maschine und hat mit `23.88.33.137` genau das. Dafuer
|
|
muessen `slaves`/`allow-transfer` geoeffnet werden, die hier bewusst leer
|
|
sind. Kein zweiter Name auf derselben Maschine als angebliche Redundanz.
|
|
3. **Bootstrap-Adresse und Glue.** `ns1` traegt die oeffentliche Adresse des
|
|
Mango, und die rotiert beim Nokia-Reconnect. Der `mango-dns`-Timer fuehrt
|
|
bisher nur `ipv6-test.0ff.space` nach, nicht diese Zone. Eine Zone kann
|
|
ihre eigene unerreichbare Bootstrap-Adresse nicht durch einen Eintrag in
|
|
sich selbst reparieren, also muessen Nachfuehrung und Glue beim Registrar
|
|
vorher stehen.
|
|
4. **Registrar-Anforderungen** an Nameserverzahl, IPv6-Glue und vorhandenen
|
|
DNSSEC-DS pruefen. Die Delegation liegt bei Cloudflare, die Altlast-NS in
|
|
der Zone zeigen auf Namecheap.
|
|
5. **Zone vor der Umstellung erneut gegen Cloudflare vergleichen.** Der
|
|
Inhalt hier ist ein Snapshot; jede Aenderung, die seither in Cloudflare
|
|
passiert ist, fehlt.
|
|
|
|
## Hinweis fuer den neuen Stack auf pinix
|
|
|
|
Der Wildcard `*` zeigt auf blunix. Ein expliziter Name schlaegt den Wildcard,
|
|
also brauchen `head.` und `dex.` eigene Eintraege auf pinix -- sie sind als
|
|
CNAMEs auf `ipv6-test.0ff.space.` in der Kandidatenzone hinterlegt und folgen
|
|
damit der bestehenden Mango-DNS-Nachfuehrung. Ohne diese Namen loesen sie auf
|
|
blunix auf, obwohl der Dienst auf pinix laeuft. Solange die Zone nicht
|
|
delegiert ist, muessen dieselben CNAMEs in Cloudflare angelegt werden, dort
|
|
zusaetzlich: **DNS-only, nicht proxied**, sonst sitzt Cloudflare im Datenpfad.
|
|
Der komplette Bootstrap-/Cutover-Rahmen steht in
|
|
[`pinix-identity-stack.md`](pinix-identity-stack.md).
|
|
|
|
## Deployment und Rueckbau
|
|
|
|
Rsync nach `/home/drone/nixos-config-build`, lokal auf pinix bauen und
|
|
aktivieren. Router-Skript sichert die Firewall unter
|
|
`/root/pinix-dns-firewall-backup.*/firewall`. Zum gezielten Rueckbau nur
|
|
`firewall.pinix_dns` entfernen und die Firewall neu laden; BIND-Import
|
|
entfernen und pinix erneut bauen. Keine alten Komplettbackups ueber spaetere
|
|
SSH- oder andere Firewall-Aenderungen schreiben.
|
|
|
|
Quellen: [BIND autoritativ](https://bind9.readthedocs.io/en/stable/chapter3.html),
|
|
[DNS-01](https://letsencrypt.org/docs/challenge-types/).
|