lukas/nixos-config
Archived
1
0
Fork 1
Code Issues Pull requests Releases Wiki Activity
This repository has been archived on 2026-09-17. You can view files and clone it, but you cannot make any changes to its state, such as pushing and creating new issues, pull requests or comments.
nixos-config/docs/pinix-bind.md
pijukka af45c30167 host(pinix): record identity DNS bootstrap for dex and head 
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
2026-09-14 12:55:11 +02:00

6.8 KiB
Raw Permalink Blame History

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.

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, DNS-01.