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:
query[A] www.example.com from ::1
forwarded www.example.com to 8.8.4.4
forwarded www.example.com to 8.8.8.8
validation result is BOGUS
reply www.example.com is 46.38.249.69Irgendwelche 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… 
MfG Christian
KB19: Ihre zone ist wieder signiert. Bitte prüfen Sie ob Ihre Probleme noch bestehen.
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:
dig +dnssec A "test-${RANDOM}.example.com" @8.8.8.8Ich 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
Ich hatte bisher Probleme mit dem Signieren, die jetzt behoben zu sein scheinen.
Über die Schreibweise mit den Nullen hatte ich mich schon gewundert…
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:
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.
Hallo,
Wem sind noch Probleme mit DNSSEC oder DANE bekannt momentan?
bei mir lässt sich DNSSEC von Anfang an nicht aktivieren.
Derzeit erhalte ich lediglich "DNSSEC konnte nicht aktiviert werden. Nachdem DNSSEC deaktiviert wurde, müssen mindestens 24 Stunden vergehen."
Gruß,
Peter
Hallo jpschley,
vielen Dank für Ihre Nachricht. Seit ca. 11 Uhr ist Ihre Domain signiert.
Wem sind noch Probleme mit DNSSEC oder DANE bekannt momentan?
ich habe da höchstens ein paar Fragen,
wenn ich im CP nun ein TLSA Eintrag der Art
_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:
_443._tcp.example.com. IN TLSA 3 0 1 SHA256Hasha) 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 
c) Kennt jemand ein TLSA/DANE Testtool? Für Webseiten und SMTP 
am besten ohne das ich etwas Installieren muss
Derzeit behaupten meine Testseiten ich habe keine TLSA Records 
hallo MrKrabat,
ein Testtool findet sich hier: https://danetools.com/dane
Ein Eintrag für die Stammdomain sähe so aus: _port._tcp
(das @ ist ja nur der platzhalter für nix, wir wollen ja aber einen record _port._tcp.domain.tld)
Und natürlich muss man den Port angeben, die Frage nach der Wildcard verstehe ich nicht ganz.
gruß
g
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"
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:
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
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.
