Tut bei euch der Login im Scp?
Ja, der Login funktioniert, und zeigt auch die Statistiken für den Zeitraum an, d.h. der Hypervisor war wohl nicht komplett am Arsch.
Beiträge von filmroellchen
-
-
Auch hier. Logs und Metriken sagen 16:18 o.ä., Autostart ist an. Keine Dateisystemschäden (BTRFS).
-
Zitat
Netcup will hier allerdings den Schlüssel und keinen Fingerprint des Schlüssels (DNSKEY Record). Werden dir die Daten angeboten bei deinem Provider?
Das war auch schon die Vermutung meiner Administrator*in. Aktuell gibt es dafür kein öffentliches Interface, sie kümmert sich aber in nächster Zeit darum. Danke für den Hinweis jedenfalls!
ZitatED25519 wird bei .de Domains nicht unterstuetzt. Wie das bei .eu aussieht, weiss ich nicht.
Generell ist ED25519 in RFC8624 nur RECOMMENDED, nicht MUST. Ich wuerde einen "MUST" Algorithmus nehmen.
Die 25519-Kurve wird bei .eu unterstützt, ansonsten wäre sie ja wohl nicht in der Liste von Netcup bezüglich dieser TLD und man könnte sie (hoffentlich) in der Maske nicht auswählen. Warum sie bei DE nicht unterstützt wird: Laut Aussage einer befreundeten DENIC-Mitarbeiterin ist der Algorithmus seit 2015 im Backlog und sie kommen aus [NDA]-Gründen nicht dazu. (Also eigentlich sollte das dann mal passieren.) Was der RFC sagt ist mir ziemlich egal, bekanntlich ist die Kurve genauso sicher wie RSA (d.h. sicher unter der Annahme der Schwierigkeit des diskreten Logarithmus, und damit auch nicht post-quantum-sicher) bei kürzeren Schlüssellängen, also immer RSA vorzuziehen.
-
Mein DNS-Provider ist ein experimenteller Service (servfail.network), wobei DNSSEC dort bekanntermaßen mit anderen Domain-Providern funktioniert. Die DNSSEC-Daten, die ich erhalte, sehen so aus:
Insbesondere handelt es sich eben um eine .eu-Domain und nicht um .de. Bei mir taucht das Hashtype-Feld nirgendwo auf.
Ich habe den korrekten Algorithmus, hier 15, sowohl in servfail (siehe Screenshot) als auch in Netcup eingetragen. Das sollte nicht das Problem sein. Genauso handelt es sich hier nicht um einen Zone-Signing-Key bzw. Key-Singing-Key, daher sollten die Flags mit 0 korrekt sein.
Auf Verisign kann man auch erkennen, dass der DNS-Provider die DNSSEC-Konfiguration korrekt vorgenommen hat, nur ist diese eben nicht von .eu aus verifiziert.
-
Für meine bei Netcup gekaufte Domain ist seit gestern ein externer Nameserver zuständig, und normales DNS funktioniert. Allerdings scheint DNSSEC nicht zu kooperieren. Der externe Nameserver gibt mir drei verschiedene öffentliche Schlüssel für die Hashtypes 1, 2 und 4. Allerdings weiß ich nicht, welchen Hashtype Netcup jetzt möchte, und es gibt auch keine Möglichkeit, diesen in der DNSSEC-Konfiguration für externe Server einzutragen. Ich habe gestern Abend (vor mehr als 12 Stunden) beide Schlüssel für Hashtype 2 und 4 eingetragen und laut Verisign/dnsviz fehlt nur noch der DS-Record, den Netcup an die .eu Nameserver weitergeben muss.
Jedenfalls wäre meine Frage, welchen Hashtype Netcup möchte? Oder ob das eigentlich egal sein sollte und DNSSEC in Netcup anderweitig kaputt ist. Hab im Forum und auf den Supportseiten (z.B. hier) nichts gefunden.
Ich verwende übrigens Algorithmus 15 (ED25519), weil dieser mit Abstand am besten von allem nicht-post-quantum-sicheren ist. (Warum unterstützt Netcup überhaupt so verflucht unsichere Dinge wie DSA und RSASHA1?)
-
Entschuldige die lange Pause. Ich hab jetzt noch mindestens einmal eine Zertifikatserneuerung gemacht und es scheint alles zu funktionieren. Keine Ahnung, was da beim ersten Mal los war.
-
Betrifft das dann nur deine Domain example.com oder auch Subdomains? Arbeitest du mit Wildcards im DNS? Magst du vielleicht einmal einen Screenshot deiner DNS-Einstellungen posten? Gerne auch in zensierter Form.
Das betrifft scheinbar nur example.com, das kann aber auch daran liegen, dass die anderen Domains bisher noch nicht abgefragt wurden und somit in keinen Caches liegen. Wildcards sind vorhanden, so wie es auch der Standard vorgibt (ich würde auch gerne Subdomains mittels meines Proxys beliebig hinzufügen können, ohne dass ich dafür am DNS-Eintrag oder an den Zertifikaten etwas ändern muss).pasted-from-clipboard.png
-
Das klingt spannend. Zumindest hier im Forum habe ich davon noch nie was gelesen.
Habe ich das richtig verstanden, dass das auch passiert, wenn du TXT-Einträge über das CCP erstellst? Wie lange ist in dem Fall dann die IPv4 falsch?
Oder könntest du mal einen beispielhaften Ablauf mit Zeiten daneben erstellen? Dann könnte ich versuchen das mal nachzustellen.
Die IP ist *schätzungsweise* 20 Minuten bis zu eine Stunde falsch. 20-30 Minuten dauert es auch in der Regel, bis netcups DNS-Einträge durch die Caches propagieren (das certbot-Plugin wartet 20min und sieht danach den TXT-Eintrag erfolgreich, und ich habe an den Standardeinstellungen zur TTL und so weiter nichts geändert).
In der Tat ist das Verhalten identisch zwischen CCP manuell und API.
Der Ablauf heute Morgen war in etwa wie folgt, aber leider sind die Zeiten sehr grob geschätzt.
9:35 - doas certbot certonly --force-renewal --authenticator dns-netcup --dns-netcup-credentials /path/to/api/secrets --dns-netcup-propagation-seconds 1200 --keep-until-expiring --expand --non-interactive --server https://acme-v02.api.letsencrypt.org/directory -d '*.example.com' -d example.com auf dem Server
10:00 - Kurzer Test der Website, die jetzt auf den Domainpark zeigt; Adresse via Ping wurde dann auch getestet. Danach war ich etwa zwei Stunden anderweitig beschäftigt.
12:00 - Erneuter Test der Website und Haupt-Domain, die sich jetzt erholt haben, während ich den Orginalbeitrag geschrieben hatte.
Certbot und das Plugin laufen direkt auf einem bei netcup gehosteten Arch Linux vServer. Die DNS-Konfiguration ist größtenteils wie die Standardeinstellung, ich habe lediglich einen AAAA-Eintrag zur IPv6-Adresse des Servers eingerichtet und alle IPv4-Einträge einschließlich A auf die IPv4-Adresse des Servers eingerichtet.
Bei aktiviertem DNSSEC gabs schön öfter komische Probleme. Getestet habe ich es in letzter Zeit nicht...
DNSSEC ist bei mir aktuell aus.
-
Da ich ein Letsencrypt-Zertifikat auf *.example.com und example.com registriere, muss ich eine DNS-Challenge verwenden, die man ja praktischerweise mittels dem Netcup-API-Plugin mit certbot umsetzen kann. Das tut auch grundsätzlich, allerdings ist mir ein seltsames Verhalten der DNS-Einträge aufseiten von Netcup aufgefallen: Wenn man TXT-Einträge vornimmt, so wie es die DNS-Challenge tut, wird zumindest der A-Eintrag (d.h. IPv4) zumindest temporär auf eine Platzhalterseite von Netcup gesetzt, sodass der Domainpark im Browser erscheint. Wenn ich wenige Minuten nach der Challenge allerdings im CCP nachschaue, sind alle Einträge wieder korrekt, und der TXT-Eintrag verschwunden. Die falsche IPv4 hält sich allerdings einige Zeit in den Caches; wenn ich eine bisher noch nicht gecachte Unterseite meiner Domain aufrufe, kommt die korrekte IP-Adresse zurück.
Dieses Verhalten habe ich auch, wenn ich manuell im CCP TXT-Einträge vornehme. Dort hat auch letztes Mal die Speicherung im Webinterface scheinbar nicht richtig funktioniert und ich musste das CCP neu laden. Der TXT-Eintrag war ohne manuelle Löschung verschwunden.
Ist dieses Verhalten bekannt, normal, oder habe ich irgendetwas übersehen? Viele Grüße
