»Cloudflare-Alternative:
19 Cloudflare-Alternativen im Überblick«
Hat jemensch von euch Erfahrung mit eines diesen Alternativen oder gar sogar mit einer nicht aufgeführten? Wenn ja, welches könnt ihr aus welchen Argumente und Gründen empfehlen?
(Ich zweifle immer noch welches am "sichersten" und "daten sparsam" ist)
"DNSSEC Bootstrapping allows the child zone operator to publish a signed copy of the child’s CDS/CDNSKEY records under a different name that has an existing chain of trust."
Montag. #DANE-Fehler "Server certificate not trusted." Wie vor 60 Tagen schon mal.
Also Anruf beim Dienstleister. "da müssen wir manuell nachjustieren." seufz
"Für eine permanente Lösung müssten wir auf ein Zertifikat umstellen, das manuell erneuert wird, was nicht praktikabel ist oder den TLSA-Record automatisch anpassen, was aktuell von unseren internen Policies nicht unterstützt wird. Da die Verfügbarkeit von DANE statistisch keine Auswirkung auf unseren Mailtraffic zeigt, erwägen wir auch den TLSA-Record gänzlich zu entfernen."
We have new KSK for the root!
Today a mega ceremony was held where new HSMs were introduced and a new root key was generated in them. This key will be pre-publicated at the end of this year, and the rollover will be at the end of 2026. It'll be the third in the history of the DNS. The first was in 2010 and the second in 2017. #dns#dnssec
Generating #DNSSEC signatures using the private keys from #RFC 9500 (a bunch a publicly known private keys, which is a strange concept 🤔) : it works nicely. :3 The keytag for "testECCP256" is 56715 or 56716 (whether it's a ZSK or a KSK).
Heureusement, je ne serais sans doute plus là, un peu avant 2106, quand il faudra commencer à se faire des nœuds au cerveau avec l'arithmétique des numéros de série du RFC 1982 appliquée au champs de dates des signatures #DNSSEC
Il y a une vingtaine d'années, l' @afnic avait mis en ligne une auto-formation au #DNS, avec un design très CD-ROM interactif typique de la fin 90's / début du siècle :)
Il y a même du #DNSSEC dans la partie avancée : c'est l'époque des KEY, SIG et autre NXT du DNSSEC 1ère génération
“This document simply moves the canonical list of algorithms from [RFC8624] to the IANA registry, and defines the registry policies for updating the registry. It does not change the status of any of the algorithms listed in [RFC8624];”
Now, in the table in section 3, column "#DNSSEC Signing", algorithms 5 & 7 are listed as "MUST NOT". They are "NOT RECOMMANDED" in RFC 8624 section 3.1. The recommandation for validation also changes (from "MUST" to "SHOULD NOT")
It is slightly different (for the better imo but still) :)
Analysis of existing CDS/CDNSKEY records in the wild. They are sometimes broken, sometimes in funny ways (authortative name servers not returning the samed CDS...)
Why would a domain in .com publish a CDS (.com does not handle CDS) and a broken one (does not match the keys)?