# 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/).