DNS nicht erreichbar für zerossl/letsencrypt ?

kyze · Nov 16th 2022

Hi zusammen,

aktuell möchte ich für eine nicht extern erreichbare Subdomain ein Wildcard-SSL-Zertifikat haben.

Als reverse-proxy und anforderer hierfür ist Caddy mit dem netcup-dns-plugin aktiv.

Nun funktioniert das anfordern und die dns-txt-records scheinbar wunderbar, aber kann von extern nicht validiert werden.

Im Caddy sehe ich, dass mein lokaler Host anscheinen einen timeout beim anfragen von den netcup-nameservern bekommt ?

Code

Nov 16 16:51:30 mono01 caddy[21307]: {"level":"error","ts":1668613890.8654814,"logger":"tls.obtain","msg":"will retry","error":"[*.meinedomain.de] Obtain: [*.meinedomain.de] solving challenges: waiting for solver certmagic.solverWrapper to be ready: checking DNS propagation of \"_acme-challenge.meinedomain.de\": read tcp 192.168.171.2:36928->46.38.225.225:53: i/o timeout (order=https://acme.zerossl.com/v2/DV90/order/w02GF_wNesuRmdgHUYnzGg) (ca=https://acme.zerossl.com/v2/DV90)","attempt":9,"retrying_in":1800,"elapsed":7412.034317054,"max_duration":2592000}

Selber abrufen mit dig an die DNS scheint aber kein Problem zu sein, womit ich ein Netzwerkproblem erstmal ausschließen würde.

Code

[root@mono01 caddy]# dig @46.38.225.225 -t txt meinedomain.de

; <<>> DiG 9.16.33-RH <<>> @46.38.225.225 -t txt meinedomain.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23351
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: e85823d8b42291f70100000063750c63d27896c4a8ae4941 (good)
;; QUESTION SECTION:
;meinedomain.de.            IN    TXT

;; ANSWER SECTION:
meinedomain.de.        300    IN    TXT    "v=spf1 mx a:meinedomain.de ..."

;; Query time: 15 msec
;; SERVER: 46.38.225.225#53(46.38.225.225)
;; WHEN: Wed Nov 16 17:14:27 CET 2022
;; MSG SIZE  rcvd: 168

Display More

Habt ihr dazu eine Idee ?

Danke und Gruß

tom434 · Nov 16th 2022

Eventuell die Wartezeit hoch setzen.

Bei mir und NPM hat es meist mindestens 10-15 Minuten Wartezeite gebraucht (seid Cloudflare DNS geht es mit dem standard wert - meine um die 2-5 Minute. Also ohne Probleme )

H6G · Nov 16th 2022

Quote from tom434

seid Cloudflare DNS geht es Probleme mit DME standard wert

Bitte was?

tom434 · Nov 16th 2022

Quote from H6G

Bitte was?

Kein Plan wie ich mich so verschreiben konnte

Kommt davon wenn man es nicht nochmal durch liest...

Virinum · Nov 16th 2022

Die Zonen werden alle 10 Minuten neu eingelesen. Diese Zeit solltest du also mindestens abwarten.

Quote from tom434

Kein Plan wie ich mich so verschreiben konnte

Und dann auch noch „seid“ und „seit“ verwechseln… SCNR

KB19 · Nov 16th 2022

Ist die private IP-Adresse 192.168.171.2 von Deinem Setup? Da ist also irgendwo eine NAT dazwischen?

Kannst Du von dort aus wirklich den Nameserver erreichen? Über TCP und nicht UDP, denn das wird in der Meldung bemängelt.

kyze · Nov 16th 2022

Ja, die 192.168.171.2 ist der Host, auf dem Caddy lief. Ist hinter einem NAT vom Vodafone-Router, aber denke ich wenig relevant weil dig ja funktionierte. Deswegen hatte ich da etwaige Netzwerkproblemchen erstmal außen vor gelassen, wenn dig da nicht komische Sachen veranstaltet

Aber waren hier schon die richtigen Hinweise: Mit einem erhöhten Timeout bei den Challenges hat es tatsächlich funktioniert!

Wundert mich etwas, weil ich nach dem Aufruf die Einträge bei Netcup direkt sehen und auch abfragen konnte, aber wer weiß wie lang das nach außen braucht.

Jetzt geht es auf jeden Fall und falls jemand interessiert wie der tls-teil im Caddy mit einer Caddyfile dazu aussieht:

Code

*.sub.domain.de {
        tls {
                issuer acme {
                        dns netcup {
                                customer_number 12345
                                api_key derkeyhier
                                api_password daskennworthier
                        }
                resolvers 8.8.8.8 1.1.1.1
                propagation_timeout 30m
                propagation_delay 15m
                }
        }
...
}

Display More

tom434 · Nov 16th 2022

Quote from kyze
Ja, die 192.168.171.2 ist der Host, auf dem Caddy lief. Ist hinter einem NAT vom Vodafone-Router, aber denke ich wenig relevant weil dig ja funktionierte. Deswegen hatte ich da etwaige Netzwerkproblemchen erstmal außen vor gelassen, wenn dig da nicht komische Sachen veranstaltet

Aber waren hier schon die richtigen Hinweise: Mit einem erhöhten Timeout bei den Challenges hat es tatsächlich funktioniert!

Wundert mich etwas, weil ich nach dem Aufruf die Einträge bei Netcup direkt sehen und auch abfragen konnte, aber wer weiß wie lang das nach außen braucht.

Jetzt geht es auf jeden Fall und falls jemand interessiert wie der tls-teil im Caddy mit einer Caddyfile dazu aussieht:
Code
*.sub.domain.de {
        tls {
                issuer acme {
                        dns netcup {
                                customer_number 12345
                                api_key derkeyhier
                                api_password daskennworthier
                        }
                resolvers 8.8.8.8 1.1.1.1
                propagation_timeout 30m
                propagation_delay 15m
                }
        }
...
}
Display More
Display More

NC DNS Server sind nicht die schnellsten .

Kann Cloudflare oder wenn Datenschutz wichtig https://desec.io/ empfehlen.

Damit hat die DNS Challenge immer ohne Probleme funktioniert und das mit der standard zeit.

kyze · Nov 16th 2022

Grundsätzlich hab ich ja kein Problem mit den Netcup-DNS-Servern. Geschwindigkeit ist da ja idr auch nicht wirklich relevant, wenn die Einträge erstmal da sind.

War offensichtlich mit den defaults da jetzt mal ein Problem, aber mit so ein paar Settings das ganze zu umgehen reicht mir erstmal.

Ist mir vorher halt noch nicht entgegengekommen, weil ich immer die normale HTTP-Challenge gemacht habe.

Die Domain die ich nun per DNS mache, ist halt eine die via Zerotier geroutet ist und deswegen fällt hier die HTTP-Challenge einfach raus.

Das ganze nochmal woanders verteilen würde ich somit erstmal weglassen, obwohl das GUI von Netcup auch nicht wirklich schön ist

KB19 · Nov 16th 2022

Quote from kyze

[…] weil dig ja funktionierte […]

Ja, über UDP laut Deiner Ausgabe. Oder hast Du es auch mit dem TCP-Flag getestet?

Quote from kyze

Wundert mich etwas, weil ich nach dem Aufruf die Einträge bei Netcup direkt sehen und auch abfragen konnte, aber wer weiß wie lang das nach außen braucht.

Dann hattest Du Glück, denn die Zonen werden definitiv nur alle 10 Minuten generiert. Erst dann springt auch die Spalte "gültig" im CCP auf "yes". Ich würde sicherheitshalber immer die doppelte Zeit einplanen.

kyze · Nov 16th 2022

Quote from KB19

Ja, über UDP laut Deiner Ausgabe. Oder hast Du es auch mit dem TCP-Flag getestet?

Dann hattest Du Glück, denn die Zonen werden definitiv nur alle 10 Minuten generiert. Erst dann springt auch die Spalte "gültig" im CCP auf "yes". Ich würde sicherheitshalber immer die doppelte Zeit einplanen.

Selbst mit +tcp bei dig kommt er durch, scheint also grundsätzlich schon zu klappen das ganze.

Mit den was die 10 Minuten angeht, guter Hinweis. Ich werde meine delays nochmal auf 25m/30m anpassen, damit auch nichts schiefgehen kann wenns unglücklich starten sollte. Für renews ist es ja dann nicht mehr zeitkritisch.

Tags