Öffentliche Beta-Phase für DNSSEC gestartet

  • Hallo


    Ich wurde vom Support hier her verwiesen. ([NC#2016051210001713])


    Seit der Aktivierung von DNSSEC auf meiner Domain „recodex.at“ kann ich keine Änderungen am DNS im CCP mehr vornehmen. Die Änderungen werden zwar gespeichert, aber der Status bleibt immer auf „unknown“. Auch nach mehr als 48 Stunden warten hat sich nichts geändert.


    Ich habe die Zone auch schon mehrmals neu abgespeichert... Jedoch ohne Erfolg.


    Bitte um Hilfe.


    Notiz am Rande: Könnte vielleicht hiermit zusammen hängen: [NC#2016050710000037]


    mfg.
    Daniel

  • Hallo,


    Ich habe meine .de-Domains jetzt auf DNSSEC umgestellt, und gleich auch noch DANE aktiviert, dabei sind beim Verifizieren ein paar Merkwürdigkeiten aufgetreten. Insbesondere kommt es anscheinend relativ häufig vor, dass die RRSIG zum falschen Namen eingetragen wird. Beispiel


    % dig @root-dns.netcup.net. +answer +dnssec +nocmd +nocomments any blog.bernd-paysan.de
    blog.bernd-paysan.de. 86400 IN CNAME blog-en.bernd-paysan.de.



    keine RRSIG. zum CNAME. Aber


    % dig @root-dns.netcup.net. +answer +dnssec +nocmd +nocomments any blog-en.bernd-paysan.de
    blog-en.bernd-paysan.de. 86400 IN A 37.221.194.73
    blog-en.bernd-paysan.de. 86400 IN AAAA 2a03:4000:2:188:0:be2:11d:b109
    blog-en.bernd-paysan.de. 86400 IN RRSIG A 8 3 86400 20160614003900 20160514003900 1
    820 bernd-paysan.de. BULxe09Mn4rabMU/HWhW6JYJKnAiiGqyI+DsIgdQXGKfnKjiw5jnukMU E7nCQ/EgtUPwa
    sxreArZEJFpkid7swr13AfbT837aK5+shGcUGq3D1rW Tf/alVMPG5HNSFbWHbc44zdpoJZgXXjkuG4jqKOGX3ZKF6H
    jH5Za5TUE +HE=
    blog-en.bernd-paysan.de. 86400 IN RRSIG AAAA 8 3 86400 20160614003900 2016051400390
    0 1820 bernd-paysan.de. Yai/yAu37kdSaLK1NVgOtUp+2rQditNB9LfJ8oYJfzoksGa3lXTx506O 0RE2dMUw2E
    +FgMR1c3NnveY7Mro8zQ5nMgczbgKZEMnmMiuu7fWhXFKH kDjdmfEeKrhgK8/l3SB9lmUx9HmnIfITYWy1zwnrmSDV
    rIoco/hk1BeJ oV8=
    blog-en.bernd-paysan.de. 86400 IN RRSIG CNAME 8 3 86400 20160614003900 201605140039
    00 1820 bernd-paysan.de. gcGR4YEpye9G4Tzr7QsCMl4W5LNwJuI9TDJXE1L+9P7db21u8m6fMC2O AkYmS/TXu
    GRSRxTAizr46lwkMn+QjKCrCgDw3DcxCj3btN2i2zgwfnhx nDy3YXqdMnVkL0MoJXn7d4UZKJCjUx+Bgco4r2MQByI
    LN/oQcVEZhgxP ovY=

    Ja, da ist ja der RRSIG für den CNAME von blog! Nach allem, was ich bis jetzt diagnostizieren konnte, kann man keine Hosts eintragen, die Präfix eines anderen Hosts sind; die RRSIG wird dann dem längeren Hostnamen zugewiesen (dem ersten, wenn es mehrere gibt). Das stört auch bei TLSA-Records, weil man z.B. _443._tcp und _443._tcp.www haben will. Ersterer wird nicht signiert, zweiter hat dann zwei Signaturen, was natürlich genauso stört. Neben blog-en habe ich auch noch blogspot und blogger als weitere Namen mit gleichem Präfix eingetragen, die Kollision findet mit dem alphabetisch ersten statt, also eben blog-en, die anderen sind normal signiert.


    Ich lass' diese Einträge jetzt mal bis nächste Woche stehen, ohne Workaround für mich, und wünsche frohe Pfingsten.

    • Offizieller Beitrag

    Vielen Dank für Ihre Meldungen.


    recodex: Wir unterstützen momentan TLSA Records mit 35 Byte Länge. Das heißt 64 Zeichen Certificate Association Data plus die Konfiguration. Es ist geplant auch andere Längen zu Unterstützen. Die Veröffentlichung ist für die nächsten Wochen geplant.


    @bernd@net2o.de: Ihr Fall wird konnte reproduziert werden. An einer Lösung wird aktuell gearbeitet.

  • [netcup] Johannes B.


    Ich habe jetzt die TLSA Einträge mit SHA256 speichern können (SHA512 war ja zu lang).


    Jedoch habe ich jetzt wieder ein Problem mit DNSSEC. Laut CCP ist DNSSEC jetzt deaktiviert.


    Aber laut einem Test mit DNSCheck ist DNSSEC aktiv. Die Seite gibt folgenden Fehler aus: „Broken chain of trust for recodex.at - DNSKEY found at child, but no DS was found at parent“


    Ebenso wie die Seite DNSSEC Analyzer - recodex.at
    “No DS records found for recodex.at in the at zone”


    Wenn ich versuche im CCP DNSSEC zu aktiveren kommt dieser Fehler: “DNSSEC konnte nicht aktiviert werden. Nachdem DNSSEC deaktiviert wurde, müssen mindestens 24 Stunden vergehen.“


    Bitte um Hilfe

    • Offizieller Beitrag

    @bernd@net2o.de: Prima, das freut mich zu hören. :)
    Für .com ist DNSSEC schon in Arbeit. Kann aber nicht sagen wann es soweit sein wird.


    recodex: Ihre Domain ist auch wieder korrekt signiert. Der SOA wurde nach der Signatur von unserem System geändert ohne die Zone neuzusignieren. Das ist jetzt behoben. :D



    Nun kann nun die führende Null bei TLSA Record Parametern weggelassen werden.
    Auch TLSA Records mit SHA512 sollten nun funktionieren.


    Herzlichen Dank für die vielen hilfreichen Hinweise zu DNSSEC. Das bringt uns wirklich weiter.


    Speichern Sie Ihre Zone neu um neue Signaturen zu erhalten, sollten sie auf Probleme stoßen.
    Unsere Software hat ein Update erhalten.



    Wem sind noch Probleme mit DNSSEC oder DANE bekannt momentan?





    :rolleyes:

  • Zitat von '[netcup

    Wem sind noch Probleme mit DNSSEC oder DANE bekannt momentan? :rolleyes:


    DNSSEC mit eu Domains geht offensichtlich nur dann, wenn die eu domains von netcup bei der EURID registriert wurden,
    wer durch netcup bei EPAG registriert wurde, muss den Support kontaktieren ...

    Grüße,
    Dirk
    (gekündigt am 06.11.2022, aus Gründen...)

  • Hallo,


    Weil es thematisch mit DNSSEC zusammenhängt (im Zweifelsfall bitte verschieben): Wäre es mittel-/langfristig denkbar, analog zu den VCP Webservices auch einen "CCP Webservice" anzubieten, welcher das Hinzufügen/Löschen von TLSA (und ggf. TXT[*]) RRs für eigene Domains erlaubt?
    Hintergrund: Dies würde eine vollautomatische Erneuerung der für DANE erforderlichen Einträge (insbesondere für das vorbereitende "Rollover" bei Zertifikatswechseln) auch für diejenigen Nutzer erlauben, welche keine eigenen (drei) Nameserver betreiben.


    [*] diese RRs werden bspw. für die letsencrypt DNS challenge validation verwendet


    mfg Markus Ueberall

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Hallo,


    Noch eine "Wunscherweiterung" (Posting bitte ggf. verschieben): Wenngleich die Standardisierung noch andauert, wäre es sicherlich interessant, mit Verfügbarkeit von DNSSEC auch die DNS-Einträge des Typs 53 (SMIMEA) und 61 (OPENPGPKEY) im CCP eintragen zu können, und sei es im Rahmen einer nächsten Betatestphase.


    Diese Einträge werden es mittel- bis langfristig erlauben, eMail-Zertifikate in Eigenregie zu verwalten, ohne aufgrund von Akzeptanzproblemen auf der Empfängerseite auf Drittanbieter angewiesen zu sein.
    Ich könnte mir vorstellen, daß dies im Zusammenhang mit DNSSEC sehr attraktiv für Kunden ist, welche keine eigenen Nameserver betreiben (können/wollen), aber Wert auf Ende-zu-Ende-Verschlüsselung legen (müssen) -- Netcup würde hiermit zu diesem Thema "alles aus einer Hand" anbieten können.


    (Testseiten im Netz zu diesen Einträgen: OPENPGPKEY.info - Test, SMIMEA Test - SMIMEA.info; Hintergrundinformationen zur Zertifikatsverwaltung bspw. mittels XCA: https://bit.ly/phdcXCA)


    Mit freundlichen Grüßen
    Markus Ueberall

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Hallo,

    Wem sind noch Probleme mit DNSSEC oder DANE bekannt momentan?

    Ich bin heute ggf. auf ein weiteres Problem gestoßen:
    Zur Redundanz-Vermeidung sollte es laut RFC6698 (Absatz A.2.1.1.) möglich sein, beispielsweise für eine Subdomain auf den/die TLSA-Einträge einer anderen Subdomain zu verweisen:

    Zitat

    _443._tcp.sub1.example.com. IN TLSA 3 1 2 308202c5308201ab...
    _443._tcp.sub1.example.com. IN TLSA 2 1 2 308202c5308201ab...
    _443._tcp.sub2.example.com. IN CNAME _443._tcp.sub1.example.com.

    (Das Ganze sollte insbesondere auch für Wildcards links (=Quelle) und rechts (=Ziel) funktionieren.)


    Ich bin mir sicher, alle möglichen Kombinationen durchprobiert zu haben (sowohl mit als auch ohne Wildcards, jeweils ohne abschließendem "." bei Angabe der Domainnamen bei Übertragung des Beispiels), erhalte jedoch immer die Fehlermeldung

    Zitat

    Fehler: Eintrag ungültig: _443._tcp.sub2 CNAME 0 _443._tcp.sub1.example.com Destination des CNAME Eintrags ist falsch.

    (In einem ersten Update-Schritt wurde das vorgenannte Ziel "_443._tcp.sub1" angelegt, es existiert also mit und ohne Wildcard-Verwendung.)


    Ich vermute, daß die Syntaxprüfung für den Typ CNAME der entsprechenden CCP-Eingabemaske keine Zielangaben akzeptiert, welche mit nicht-alphanumerischen Zeichen beginnen.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing


  • Noch eine "Wunscherweiterung" (Posting bitte ggf. verschieben): Wenngleich die Standardisierung noch andauert, wäre es sicherlich interessant, mit Verfügbarkeit von DNSSEC auch die DNS-Einträge des Typs 53 (SMIMEA) und 61 (OPENPGPKEY) im CCP eintragen zu können, und sei es im Rahmen einer nächsten Betatestphase.

    Ergänzend hierzu die beiden drafts (beide experimental, aber schon weit gediehen):
    https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-12
    https://tools.ietf.org/html/draft-ietf-dane-smime-11


    Für meine Begriffe sind das die bislang geeignetsten Vorschläge, eine Schlüsselverteilung für E-Mail-Verschlüsselung skalierfähig auszurollen.


    Endlich S/MIME ohne CA bzw übergangsweise mit CA und DANE-abgesichert. Endlich PGP mit brauchbarer Schlüsselverteilung. Dazu DNSSEC-abgesichert.


    Fehlt noch Verbreitung in Software, aber das wird wieder ein Henne-/Ei-Thema. Netcup könnte hier schon mal ein Ei legen.


    Ich kann es kaum erwarten, PGPOPENKEY und SMIMEA in Aktion zu sehen. Nicht nur für E-Mails, sondern auch z. B. für Code-Signing. Ich würde es am liebsten gleich einsetzen. Schadet ja nicht.

  • Hallo,


    Und noch eine "Wunscherweiterung" (Posting bitte ggf. verschieben): Gerade im Kontext einiger Angebote, welche LetsEncrypt-Zertifikate verwenden und diese ggf. automatisch erneuern, wäre im CCP die Unterstützung des RR-Typs 257 (DNS Certification Authority Authorization, CAA) gemäß RFC6844 interessant, welcher von Nutzern wahrscheinlich noch eher als TYPE53 und TYPE61 (SMIMEA/OPENPGPKEY, siehe vorheriges Posting) angenommen/verwendet/wertgeschätzt werden dürfte.


    Mit freundlichen Grüßen
    Markus Ueberall

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Hallo,


    danke für die Anregung. Ich werde Ihren Vorschlag mit der Geschäftsführung besprechen. Sie können solange selbst Nameserver betrieben und über uns die DNSSEC Einträge an die Registy senden. Dafür bieten wir auch ein Image mit PowerDNS.

    Hallo Johannes,


    gibt es inzwischen einen neuen Zwischenstand? :)


    Grüße

  • Neu erstellte Beiträge unterliegen der Moderation und werden erst sichtbar, wenn sie durch einen Moderator geprüft und freigeschaltet wurden.

    Die letzte Antwort auf dieses Thema liegt mehr als 365 Tage zurück. Das Thema ist womöglich bereits veraltet. Bitte erstellen Sie ggf. ein neues Thema.

    • :)
    • :(
    • ;)
    • :P
    • ^^
    • :D
    • ;(
    • X(
    • :*
    • :|
    • 8o
    • =O
    • <X
    • ||
    • :/
    • :S
    • X/
    • 8)
    • ?(
    • :huh:
    • :rolleyes:
    • :love:
    • :pinch:
    • 8|
    • :cursing:
    • :wacko:
    • :thumbdown:
    • :thumbup:
    • :sleeping:
    • :whistling:
    • :evil:
    • :saint:
    • <3
    • :!:
    • :?:
    Maximale Anzahl an Dateianhängen: 10
    Maximale Dateigröße: 1 MB
    Erlaubte Dateiendungen: bmp, gif, jpeg, jpg, pdf, png, txt, zip