Öffentliche Beta-Phase für DNSSEC gestartet

  • Kleine Rückmeldung,


    ich habe einfach ALLE DNS Records von Domain A gelöscht und neu erstellt.
    Jetzt gehen wildcard Subdomains, also das neu signieren der Zone hat bei mir allein nicht gereicht aus unerklärlichen Gründen :)


    Vieleicht wurde das Problem auch indirekt durch Einführung von Dane gefixt :)

  • Hallo MrKrabat,
    danke für Ihre Nachricht. Das freut mich zu hören.


    Generell für alle:
    Speichern Sie Ihre Zone neu um neue Signaturen zu erhalten, sollten sie auf Probleme stoßen.
    Unsere Software hat ein Update erhalten.
    Bei der Verarbeitung von NSEC3 Records wurde ein Fehler behoben.


    Richtig, TLSA Records sind nun auch möglich: siehe Facebook

  • Ich spiele zum Test gerade mit dig und einer zusätzlichen Dnsmasq-Installation in einer VM herum, bei der DNSSEC aktiviert ist. Als Resolver sind die Google-DNS-Server eingetragen. Das funktioniert soweit auch zufriedenstellend, außer bei der Subdomain "www". Laut den diversen Tests im Internet ist dort aber alles korrekt. Trotzdem liefert mir Dnsmasq nur einen SERVFAIL, im Log steht dazu folgendes:


    Code
    1. query[A] www.example.com from ::1
    2. forwarded www.example.com to 8.8.4.4
    3. forwarded www.example.com to 8.8.8.8
    4. validation result is BOGUS
    5. reply www.example.com is 46.38.249.69


    Irgendwelche Tipps, wo ich noch nach dem Fehler suchen soll? Ich bin da gerade etwas ratlos.


    Edit 1: Achja, www wird durch einen Wildcard-Record beantwortet. Hängt es vielleicht damit zusammen?


    Edit 2: Offenbar ja, denn andere Subdomains mit eigenem Record funktionieren einwandfrei. Fragt sich nur, ob es an Dnsmasq liegt oder nicht…


    Edit 3: Wildcard-Record gelöscht, neu angelegt und Zone gespeichert. Jetzt geht es teilweise schon, teilweise wieder nicht. Getestet mit zufälligen Präfixen ala test-$n.


    Edit 4: DNSSEC nochmals neu de-/aktiviert für die Domain. Mal sehen, was morgen dabei heraus kommt. Irgendwie scheint der die Wildcard-RRs nicht zu mögen.



    MfG Christian

  • Hallo killerbees19,


    danke für Ihre Nachricht.


    Bitte bedenken sie: Bei jedem aktivieren und deaktivieren wird ein neuer KSK und ZSK erzeugt. Die bestehenden KSK und ZSK verblieben im System für die doppelte TTL der Zone.
    In Zukunft können Kunden DNSSEC erst wieder aktiveren wenn die doppelte TTL der Zone vergangen ist, um dem vorzubeugen.


    Wenn Sie eine neue Signatur für die Zone haben möchten, reicht es die Zone einmal mit einer kleinen Änderung zu speichern. Dann wird Sie innerhalb von 5 Minuten neu signiert.

  • Wenn Sie eine neue Signatur für die Zone haben möchten, reicht es die Zone einmal mit einer kleinen Änderung zu speichern. Dann wird Sie innerhalb von 5 Minuten neu signiert.


    Nur bringt das beim Wildcardproblem offensichtlich nichts. Bleibt nur die Frage, ob Dnsmasq, ein Resolver dazwischen oder die netcup Nameserver hier den Fehler verursachen. Komische Sache… :wacko:



    MfG Christian

  • Resultiert noch immer in einem SERVFAIL, sobald die Anfrage durch den Wildcard-RR beantwortet werden würde. Die anderen fix eingetragenen Records funktionieren problemlos.


    Direkt über den Ubuntu Desktop über die Google-DNS-Server funktioniert es allerdings immer perfekt:

    Code
    1. dig +dnssec A "test-${RANDOM}.example.com" @8.8.8.8


    Ich tippe derzeit auf einen Bug in Dnsmasq in der Version von Debian Jessie. Ich muss am WE einmal die neueste Entwicklerversion testen und den Bugtracker vom Projekt durchforsten.



    MfG Christian

  • In manchen Fällen werden TLSA Records nicht korrekt signiert.
    Wir haben dazu ein Update eingespielt das aber noch getestet wird.
    Konnten Sie schon erfolgreich TLSA records signieren?


    Zudem verwenden wir nun die abwärtskompatible Schreibweise mit zwei Stellen für die Parameter von TLSA Recods. Beispiel: 03 01 01 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

  • guest123 : Vielen Dank für Ihre Nachricht.



    Unsere Tests sind mittlerweile auch erfolgreich gewesen mit einem TLSA Record für eine SSL Verbindung zu einem Webserver.


    Bei der Schreibweise der TLSA Records werden wir in den nächsten Tagen auch die einstellige Variante wieder unterstützen können.

  • Ein Problem, das ich bisher nicht lösen konnte, ist folgendes:
    Ich möchte meine TLSA-Records auf meinem eigenen Nameserver verwalten, um den Keychange beim Zertifikatswechsel automatisieren zu können. Dafür will ich die Zonen _tcp und _udp delegieren. Die notwendigen NS- und DS-Einträge schlagen bisher allerdings fehl:

    Quote

    Fehler: Eintrag ungültig: _tcp NS 0 domain.de Host bei NS-Record falsch.


    Da die Erstellung auch bei nicht (mehr) signierten Domains fehlschlägt, genauso wie bei signierten nach Löschen aller Einträge dieser Zonen, ist es vermutlich kein DNSSEC-eigenes Problem.
    Einträge mit Unterstrich im Host waren jedoch vor der Einführung schon möglich, für DMARC beispielsweise.


    Gruß
    g

  • Hallo guest123,
    wir werden dieses Verfahren intern prüfen. Solange können Sie für Ihre Zone eigene Nameserver verwenden. Dann haben Sie die volle Kontrolle über Ihre Hashes in der Zone. Als nameserver mit DNSSEC kann ich persönlich PowerDNS empfehlen, dafür stellen wir auch schon ein Image bereit.

  • ich habe da höchstens ein paar Fragen,


    wenn ich im CP nun ein TLSA Eintrag der Art

    Code
    1. _tcp.test TLSA 03 01 01 SHA256Hash


    habe, steht "test" ja für die Subdomain nehme ich an, auf Facebook der Screenshot von euch hatte das ja äquivalent nur mit mail.


    Laut Standard sieht der Eintrag ja so aus:

    Code
    1. _443._tcp.example.com. IN TLSA 3 0 1 SHA256Hash


    a) den Port können wir ja nicht angeben, ist er mit Wildcard vorgeben? Laut RFC6698 ist das ja möglich
    b) Wie setzt man den TLSA für die Stammdomain bei Netcup? "_tcp", "_tcp.", "_tcp.@" mir würde vieles einfallen :S
    c) Kennt jemand ein TLSA/DANE Testtool? Für Webseiten und SMTP :thumbup: am besten ohne das ich etwas Installieren muss


    Derzeit behaupten meine Testseiten ich habe keine TLSA Records ^^

  • Danke guest123,


    die Frage wegen dem Wildcard für den Port kommt daher, dass bei dem Facebookpost von Netcup ein Screenshot gegeben war:
    https://www.facebook.com/netcup/photos/a.392423024148693.89056.165424236848574/1081006705290318/?type=3&theater


    dort sieht man, dass kein Port bei dem TLSA-Record angegeben wird daraus würde sich ja schließen, dass der Port hardcoded sein muss
    Laut Standard für TLSA wäre es erlaubt "_*._tcp.example.com." zu machen und jeden Port abzudecken, daher die Frage :)

  • Laut Standard für TLSA wäre es erlaubt "_*._tcp.example.com." zu machen und jeden Port abzudecken, daher die Frage :)


    Ohne die Details zu TLSA zu kennen: Das würde allerdings im Widerspruch zu diversen RFC's stehen, die DNS behandeln. Dort ist ein Wildcardeintrag explizit nur ganz links von einem Punkt erlaubt. (*.sub.example.com)



    MfG Christian

  • Hallo,


    der Screenshot des TLSA auf Facebook ist etwas irreführend. Ports sind nicht hard-coded.
    Wie es sich generell mit Wildcards verhält kann ich nicht sagen.


    Dane Testtool: DANE Validator by SIDN Labs
    Vorsicht, die Seite hat ein langen Cache und prüft nicht Live.


    Hier ein Bild eines Beispiels mit korrekten TLSA Recod der ein LetsEncrypt Zertifikat auf Port 443 publik macht:


  • Ohne die Details zu TLSA zu kennen: Das würde allerdings im Widerspruch zu diversen RFC's stehen, die DNS behandeln. Dort ist ein Wildcardeintrag explizit nur ganz links von einem Punkt erlaubt. (*.sub.example.com)


    MfG Christian


    Ja du hast recht, der _ am anfang gehört weg :)
    Ich habe Wildcards erfolgreich getestet mit "*._tcp"




    Danke! Das Funktioniert so jetzt, Wildcards gehen auch mit "*._tcp", deckt dann alle Ports ab


    Ich verlinke auch mal das Tool meines Vertrauens
    https://ssl-tools.net/
    die Seite kann ebenfalls auf DANE Prüfen und viele andere Sachen auch :)