67a2a6541e
Let's Encrypt hat *.lukasrosier.com und lukasrosier.com ausgestellt (issuer YE1, gueltig bis 11.12.2026), per DNS-01 gegen das eigene BIND, ohne fremden API-Token. Delegiert ist nur _acme-challenge, der Apex samt MX, SPF und DKIM bleibt bei Cloudflare. Der Weg dorthin ging ueber drei Fehlerbilder, die alle dieselbe Ursache hatten, und das ist der eigentliche Merkposten: von innerhalb dieses Netzes ist die Propagationsvorpruefung nicht durchfuehrbar. 1. Systemresolver (Mango) liefert die SOA, auf NS-Abfragen aber nichts -- sein Forwarder bedient NS nicht. lego: "could not determine authoritative nameservers". 2. Eigenes unbound: SERVFAIL. Es rekursiert bis zur Delegation, die auf die oeffentliche Mango-Adresse zeigt, und die ist von innen nicht erreichbar, weil die DNAT-Regeln reflection=0 tragen. 3. Fremder Resolver (Quad9) findet die NS korrekt, aber lego fragt den autoritativen Server danach direkt ab -- und landet wieder auf der oeffentlichen Adresse, wo Mangos eigener Forwarder statt unseres BIND antwortet: "did not return the expected TXT record". Also dnsPropagationCheck = false. Das ist keine Nachlaessigkeit: pruefen kann nur Let's Encrypt von aussen, und genau das passiert. Dass die Delegation von aussen traegt, ist unabhaengig belegt -- Quad9 und Google liefern beide NS, SOA und TXT aus unserem BIND. Wieder einschaltbar, sobald am Mango Hairpin fuer Port 53 aktiv ist. Nebenbefund, ebenfalls im Kommentar: der NS einer delegierten Zone muss mit der Delegation im Elternteil uebereinstimmen. Die Challenge-Zone nannte zuerst ns1.lukasrosier.com, das oeffentlich ueber den Wildcard auf blunix' IPv4 auflaest -- kein Nameserver. Jetzt ipv6-test.0ff.space, derselbe Name wie in der Cloudflare-Delegation, dessen AAAA der mango-dns-Timer nachfuehrt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Aw4viUJyXGP8ANocHiF15q
25 lines
1.2 KiB
Dns
25 lines
1.2 KiB
Dns
; Saatdatei fuer die dynamische Challenge-Zone. Wird per systemd-tmpfiles
|
|
; einmalig nach /var/lib/bind kopiert, falls dort noch nichts liegt, und
|
|
; danach nie wieder ueberschrieben -- BIND schreibt in diese Zone (TXT der
|
|
; ACME-Challenge plus Journal), sie ist also veraenderlicher Zustand und
|
|
; kann nicht im Nix-Store liegen.
|
|
;
|
|
; Die Hauptzone bleibt dadurch unveraendert deklarativ: nur dieser winzige
|
|
; Unterbaum ist beschreibbar, und der TSIG-Schluessel darf laut
|
|
; update-policy in bind.nix ausschliesslich hier TXT-Eintraege setzen.
|
|
$TTL 60
|
|
@ IN SOA ipv6-test.0ff.space. hostmaster.lukasrosier.com. (
|
|
1 ; serial, BIND zaehlt bei dynamischen Updates selbst weiter
|
|
3600 ; refresh
|
|
600 ; retry
|
|
604800 ; expire
|
|
60 ; negative cache TTL
|
|
)
|
|
@ IN NS ipv6-test.0ff.space.
|
|
|
|
; SOA-MNAME und NS nennen absichtlich ipv6-test.0ff.space und nicht
|
|
; ns1.lukasrosier.com. Der NS einer delegierten Zone muss mit der Delegation
|
|
; im Elternteil uebereinstimmen, sonst sucht legos Propagationspruefung den
|
|
; dort genannten Namen -- und ns1.lukasrosier.com loest oeffentlich ueber den
|
|
; Wildcard auf blunix' IPv4 auf, das kein Nameserver ist. Fehlerbild:
|
|
; "could not determine authoritative nameservers".
|