DNSSEC Fehler: The TTL of the RRset (180) exceeds the value of the Original TTL field of the RRSIG RR covering it (0).

    Ich habe DNSSEC für meine Domain aktiviert. Die "meisten" DNSSEC-Analyzer sind glücklich (DNSSEC Analyzer, SSL Tools) und auch andere Mail-Server sind mit meinen DANE-Einträgen zufrieden.


    Bei DNSViz erhalte ich jedoch die Fehlermeldung:

    Code
    RRSIG mhnnet.de/NSEC3PARAM alg 8, id 37935: The TTL of the RRset (180) exceeds the value of the Original TTL field of the RRSIG RR covering it (0).

    Ich bin kein DNSSEC-Profi. Was bedeutet diese Fehlermeldung? Oder ist das ein False Positive und ist das Ergebnis bei DNSViz einfach falsch?

    Alle RR haben bei mir momentan die minimal mögliche TTL von 180s. Bei den betroffenen Fällen habe ich

    Code
    mhnnet.de.              180     IN      DNSKEY  257 3 8 AwEAAcXNH+ECVOdLRnR5bewh2C/M0C7F+jdWb7KuK2EqRrjUgvdv51ZR MvmTrCPmJ+bKn+ucFLCuaG/B6nWBcmytC0nKllUrTLYVYaKeI2RXwEka bFzgsBbkY2h90aRPKFzazUN1rumJh1UdwNRccTSzEZGUN6iiNnrgm54Q 2CVqKhrzTN
LYypYiACF4pBbAQfIyj2lmwneZwdi4J7UfzA2PMHY6v33u Bu/4U84gHBv+u6wK8e698+8sufdAiduvR8FTMOQCDRcUQnlf02ELP9Fr 2y6d/gxwjRKZiXVE59VCLqa3yCOiVg8LYVoyHxhnT+d5Z23H3P+DfDh2 2QG4F+9fWP8=
mhnnet.de.              180     IN      DNSKEY  256 3 8 AwEAAahpb+4SJ/gSt4Vb9x4MwqX0nvnUxt0kjESnM/aOnWdJfOtlVhs4 r7x+ireDVyCcVodLIQGkm4WzhgKNjG4FZaE7VV4WFqXjC6KL5UJdVBiE W4tY3Ej+TxNMWDUWeA7ZAPLJBDWdwDjobd/5Xy9AoFvDjidEL6vBRcMv 86ooES6H
mhnnet.de.              180     IN      NSEC3PARAM 1 0 100 73D66FE98D54FC17

    Daher kann ich aber die Aussage, dass die TTL die Original TTL übersteigen würde nicht nachvollziehen.


    PS: Ich bin noch am Testen und sobald alles stabil läuft, wird die TTL von 180s wieder auf angemessene Werte hochgesetzt.

    Ich bekomme:


    mhnnet.de. 0 IN NSEC3PARAM 1 0 100 73D66FE98D54FC17


    Also eine TTL von 0 und nicht 180, wie von Dir angegeben. Das ist bei meinen Resolvern so. Ebenfalls bei 8.8.8.8 und 8.8.4.4. Allerdings liefern 1.1.1.1 und die Netcup-Server eine TTL von 180. Dnsviz sieht wohl auch die TTL von 0. Wo die falsche TTL her kommt, ist mir unklar. Das Flushen meiner Caches hat nicht geholfen.


    Edit: Bei genauerem Hinsehen stellt sich heraus, dass die NC-Server den korrekten NSEC3PARAM-Record liefern, aber den passenden RRSIG mit einer TTL von 0. Ergo: Broken DNSSEC made bei Netcup. Zu dem Thema gibt es hier diverse Threads.

    Naja, was ich dir ziemlich sicher sagen kann, das ist kein Fehler, der zum Ausfall führt, also die Auflösung verhindert. Den Fehler habe ich hier bei netcup schon, seit ich Domains mit netcup Nameservern auf dnsviz anschaue. Noch nie eine solche Domain auf dnsviz.net gecheckt, wo der Fehler nicht gekommen wäre. Jetzt ist es zwar leider so, dass hier bei netcup gelegentlich Fehler mit DNSSEC auftreten, die dann sehr wohl die Auflösung verhimdern, das sieht dann aber bei dnsviz deutlich schlimmer aus als diese immer gleiche Fehlermeldung.


    Ich bin in dem DNSSEC-Thema zu wenig drin, aber was man jedenfalls finden kann, ist z.B.dieser Issue:https://github.com/dnsviz/dnsviz/issues/91

    Da wird zumindest behauptet, dass es keinerlei praktische Bedeutung hat und einen Fehler dafür auszugeben nicht angemessen ist, eigentlich nicht mal eine Warnung, weil eben NSEC3PARAM Records unter normalen Umständen nicht abgefragt oder gar gecacht werden. Vielleicht wenn es mal jemand liest, der in dem DNSSEC-Theme tiefer drinsteckt als ich ... Ähnliches habe ich auch anderswo schon gelesen mit besserer Erklärung, die mich damals dazu gebracht hat, diesen Fehlerzu ignorieren. Ich finde das aber gerade nicht mehr.

    Es handelt sich in der Tat um einen Fehler seitens Netcup beim Signieren und Erzeugen des zugehörigen RRSIG Records für den Record NSEC3PARAM. Es ist ein Bug und ich hoffe Netcup liest hier mit bzw. ich werde im Nachgang einen Bug Report mit Verweis auf diesen Post an Netcup schicken.


    Zitat von heppel

    Also eine TTL von 0 und nicht 180, wie von Dir angegeben. Das ist bei meinen Resolvern so. Ebenfalls bei 8.8.8.8 und 8.8.4.4. Allerdings liefern 1.1.1.1 und die Netcup-Server eine TTL von 180. Dnsviz sieht wohl auch die TTL von 0. Wo die falsche TTL her kommt, ist mir unklar. Das Flushen meiner Caches hat nicht geholfen.

    Das Du bei Caching Resolvern eine kleinere TTL erhältst als beim Name Server, der autoritative für die Zone ist, ist normal. Ein Caching Resolver trägt die Rest-TTL ein, die zum Zeitpunkt des Zonentransfers noch gültig war. Siehe weiter unten, das wird noch wichtig. Für die Fehleranalyse ist es daher notwendig, den authoritive Name Server direkt anzufragen, wenn man die ursprüngliche TTL erfahren möchte.


    Screenshot:


    Screenshot_20231115_175553.png


    Der NSEC3PARAM Resource Record für mhnnet.de hat eine TTL von 180s (vgl. erster pinker Kreis). Die Signatur ist in einem zugehörigen RRSIG Record für mhnnet.de und NSEC3PARAM hinterlegt.


    Ein RRSIG Record ist grundsätzlich wie folgt aufgebaut

    Code
    <Name> <TTL> IN RRSIG <Original Type> <Sig-Algo> <count of labels> <Original TTL> <validity end> <validity begin> <key id> <issuer name> <signature value>

    Wir haben

    • Name = mhnnet.de
    • TTL = 180 (Standardwert für alle TTL in der Zone)
    • Original Type = NSEC3PARAM (Typ des Eintrags der signiert wird)
    • Signature Algo = 8 (RSA/SHA-256)
    • Count of Labels = 2 (weil "mhnnet.de" aus zwei Namensbestandteilen besteht)
    • Original TTL = 0 (Hier ist der Bug, dass müsste 180 sein!)
    • Rest sollte klar sein

    Wichtig ist hier zu unterscheiden zwischen der TTL des RRSIG Records selbst und der Original TTL. Ersteres gibt an, wie lange der RRSIG Record gültig ist. Der Wert ist im Folgenden egal. Die Original TTL muss den Wert der TTL des zu signierenden Resource Records enthalten. In diesem Fall also die TTL des zu signierenden NSEC3PARAM Records. Dieser ist 180 (erster pinker Kreis), aber Netcup trägt für Original TTL konstant eine Null ein (zweiter pinker Kreis).


    Der korrekte ursprüngliche TTL-Wert wird zwingend benötigt, um den Signaturwert korrekt verifizieren zu können. Die Signatur wird über den gesamten zu signierenden RRSIG Record erstellt, in dem 180 steht. Wie heppel bereits festgestellt hat, erscheint an dieser Stelle bei Caching Resolvern mitunter ein kleinerer Wert. Damit nun eine Instanz, die die Signatur prüfen will, die Signatur korrekt nachrechnen kann, muss der originale TTL-Wert mitgeteilt werden. Dafür dient Orig-TTL. Aus dem RFC 4034, Sec. 3.1.4:

    Zitat
    The Original TTL field specifies the TTL of the covered RRset as it appears in the authoritative zone. The Original TTL field is necessary because a caching resolver decrements the TTL value of a cached RRset. In order to validate a signature, a validator requires the original TTL.

    Zusammenfassung: Beim Erzeugen des RRSIG Record baut Netcup Mist. Anstatt den richtigen TTL-Wert aus dem zu signierenden Record einzutragen, trägt Netcup hier eine Null ein. Interessanterweise bekommt es Netcup aber bei den anderen RRSIG Records für die übrigen Einträge korrekt hin.


    Zitat von tab

    Naja, was ich dir ziemlich sicher sagen kann, das ist kein Fehler, der [...] die Auflösung verhindert. Den Fehler habe ich hier bei netcup schon, seit ich Domains mit netcup Nameservern auf dnsviz anschaue. Noch nie eine solche Domain auf dnsviz.net gecheckt, wo der Fehler nicht gekommen wäre.

    Das ist insofern richtig, weil nur die Signatur zum NSEC3PARAM-Eintrag kaputt ist. Die Signaturen für die Einträge, die "üblicherweise" von Clients abgefragt werden (z.B. A, AAAA, CNAME, MX usw.) sind in meinem Fall korrekt berechnet. Aber dies ist trotzdem ein Bug, der gefixt gehört. Es müssen alle Einträge korrekt signiert werden!

    Zitat von tab

    Ich bin in dem DNSSEC-Thema zu wenig drin, aber was man jedenfalls finden kann, ist z.B.dieser Issue:https://github.com/dnsviz/dnsviz/issues/91

    Da wird zumindest behauptet, dass es keinerlei praktische Bedeutung hat.

    Klares jein. Ich habe mir mittlerweile auch andere RFC zu DNSSEC durchgelesen. Der Record NSEC3PARAM dient dazu, kryptographisch die Nicht-Existenz von Einträgen zu beweisen. Das ist sicherlich ein exotischer Anwendungsfall. Mir fällt spontan auch keine Client-Software ein, die einen Beweis für die Nicht-Existenz eines Eintrags sinnvollerweise benötigen würde.


    Aber, dass Netcup hier einen einzelnen RRSIG-Record falsch erstellt, andere RRSIG-Record aber korrekt hinbekommt, verheißt nichts Gutes. Das klingt nach einen typischen indeterministischen "Heisenberg-Bug". Wer garantiert, dass beim nächsten Mal, wenn ich die DNS-Zone bearbeitet, wieder "nur" der Signatureintrag zu etwas unbedeutenden wie NSEC3PARAM kaputt gerechnet wird, der für exotische Client-Applikationen benötigt wird, und nicht mal was wichtigeres wie ein A, AAAA, MX usw. Eintrag betroffen ist?

    Zitat von nagmat84

    Aber dass Netcup hier einen einzelnen RRSIG-Record falsch erstellt, andere RRSIG-Record aber korrekt hinbekommt, verheißt nichts Gutes. Das klingt nach einen typischen indeterministischen "Heisenberg-Bug". Wer garantiert, dass beim nächsten Mal, wenn ich die DNS-Zone bearbeitet, wieder "nur" der Signatureintrag zu etwas unbedeutenden wie NSEC3PARAM kaputt gerechnet wird, der für exotische Client-Applikationen benötigt wird, und nicht mal was wichtigeres wie ein A, AAAA, MX usw. Eintrag betroffen ist?

    Ich hätte es nicht beschreien sollen. :S Ich habe soeben die TTL-Werte von 180s wieder auf "vernüftige" Werte im Stunden und Tagesbereich hochgesetzt, weil ich mit Testen fertig war und alle DNS-Einträge zu meiner Zufriedenheit waren. Also habe ich neue TTL-Werte eingetragen, ein Update angestoßen und nun ist die Signatur zum SOA-Record kaputt. Arghhh! =O

    Ich wollte ressourcenschonend sein, denn DNS-Einträge ändern sich nicht alle naselang und ich habe

    Code
    mhnnet.de.   14400   IN   SOA   root-dns.netcup.net.   ;  4h (TTL for SOA)
                                dnsadmin.netcup.net.
                                          2023111518
                                               86400   ; 24h (refresh from primary to secondaries)
                                                7200   ;  2h (retry if refresh fails)
                                              259200   ;  3d (expiration)
                                               14400   ;  4h (minimum TTL for any record)

    verwendet.

    Jetzt muss ich "irgendwas" in der Zone ändern, damit es ein neues Update gibt und Netcup hoffentlich dann die Signaturen wieder richtig rechnet. Aber wenn es jetzt blöd läuft, kann es bis zu 24h dauern, bis die neuerliche Änderung durch das DNS-System durchpropagiert ist. Bis dahin könnten manche Clients eine kaputte SOA-Signatur sehen. Grmph. Wieso habe ich es nur weisgesagt. ||

    Tja, wie geschrieben, passiert leider ab und an mal bei netcup. Wahrscheinlich sind deswegen mittlerweile die meisten, die hier DNSSEC nutzen, mit externen Nameservern unterwegs. Ich nutze z.B. den kostenlosen Service von deSEC (desec.io), gibt aber auch andere Anbieter (Cloudflare?). Funktioniert bisher immer problemlos und dauert normalerweise maximal ca 2 Stunden bis die neuen Nameserver eingetragen sind und DNSSEC funktioniert. Downtime dabei meist maximal eine halbe Stunde und danach hatte jedenfalls ich bisher keinerlei Probleme mehr. Im Nebenefekt sind dann auch Änderungen schneller propagiert. Alles bisher aber von mir nur mit de-Domains getestet.

    Puh langsam sollte echt mal was passieren...

    Seit gestern sind bei mir 9,5 (die eine wird wahrscheinlich morgen auch vollends down sein) von 11 Domains wo ich DNSSEC aktiv habe kaputt...

    Also leider nicht mehr wirklich nen Einzelfall. [netcup] Alexander W.

    Wären das jetzt nicht Hobby Domains von mir und würden da Shops etc. drauf liegen würd ich richtig beef machen...

    Falls irgendwelche Daten zur Analyse benötigt werden- nicht wieder der Kommentar vom Support ich soll DNSSEC an und aus machen. (Ist mir zu blöd und lasse es so stehen), kann man sich ja melden ;)

    pasted-from-clipboard.png

    Oi weh, habe gerade auch wieder eine Domain gefunden, wo DNSSEC aktiv ist und wo es bei dnsviz.net ziemlich rot aussah. Ich habe DNSSEC mal vorsichthalber deaktiviert, auch wenn es doch eine ziemlich entbehrliche Domain ist. Also deSEC Nameserver braucht die jedenfalls nicht zwingend.

    Zitat von [netcup] Alexander W.

    Wir sind mit Hochdruck dran die DNSSEC Themen ein für alle mal zu fixen. Bitte gebt uns noch ein wenig Zeit.

    Das wurde in der Vergangenheit schon oft kommuniziert, auch auf den Netcup Events. Aber wenn es die Geschäftsführung sagt, dann glaube ich dem Mal. Wäre natürlich toll, wenn man DNSSEC dann endlich Mal zuverlässig einsetzen könnte :)

    VPS Secret • VPS 200 G8 • 4x VPS piko G11s • 2x RS 1000 G9.5 SE NUE • RS Cyber Quack • VPS 1000 ARM G11 VIE

    mail@compi653.net

    Gefällt mir 3

    Hallo zusammen,


    vielen Dank für eure Geduld, es hat etwas länger gedauert. Aber hier ein paar Details.


    Also ... wir haben uns jetzt ein paar Gedanken zum Thema DNS(SEC) gemacht.


    Zum Hintergrund:

    DNS ist bei uns über die Jahre stark gewachsen. Damit alles stabil läuft, haben wir viele Dinge angepasst, optimiert und erweitert. DNSSEC ist im Laufe der Zeit dazu gekommen.

    Gerade bei DNSSEC gibt es viele Cornercases, die man beachten muss. Registries arbeiten teilweise unterschiedlich, dann gibt es immer wieder Änderungen in den Prozessen und Schnittstellen.

    Neue TLDs kommen hinzu, neue Features, Security-Erweiterungen etc. etc.


    Kurzum, das Thema "DNS" ist im Kern super stabil und zuverlässig, hat aber auch seine Schwächen in der Architektur, was man insbesondere bei DNSSEC in Einzelfällen merkt.


    Unsere Handlungsoptionen:

    Wir hatten nun also die Möglichkeit, uns entweder für

    a. einen Quick-Fix oder

    b. eine Neuentwicklung

    zu entscheiden.


    Ursprünglich wollten wir mit Option (a) weitermachen bzw. hatten schon damit begonnen. Wir haben dann allerdings abgebrochen und uns für eine Neuentwicklung entschieden. Ganz "neu" ist es allerdings nicht, da wir schon einen großen Teil der neuen Technologie einsatzbereit haben.


    Entscheidung:

    Konkret bedeutet das, dass wir uns jetzt mit Hochdruck auf die Implementierung einer neuen DNS-Lösung konzentrieren, von der ein beträchtlicher Teil bereits funktioniert und nun angepasst und integriert wird.


    Wir werden auch ein neues, hübscheres Interface (das ehrlich gesagt auch längst überfällig ist) parallel zum jetzigen DNS Interface entwickeln und online stellen. Ihr werden dann auch die Möglichkeit bekommen, kontrolliert auf die neue Lösung umzusteigen. Nach 1-2 Jahren werden wir dann die derzeitige Lösung komplett abschalten.


    Zeitplan:

    Ende Q1 2024 (Live Betrieb)

    Das ist zugegebenermaßen ein sportliches, aber ein durchaus realistisches Ziel.


    Ich bitte euch noch um ein wenig Geduld, damit wir das Thema DNSSEC & DNS im Allgemeinen sauber und zukunftssicher gestalten.


    Liebe Grüße

    Alex

    Wo kann man sich als Alpha/Beta-Tester melden? 😍

    Zitat von [netcup] Alexander W.

    Wir werden auch ein neues, hübscheres Interface (das ehrlich gesagt auch längst überfällig ist) parallel zum jetzigen DNS Interface entwickeln und online stellen. Ihr werden dann auch die Möglichkeit bekommen, kontrolliert auf die neue Lösung umzusteigen. Nach 1-2 Jahren werden wir dann die derzeitige Lösung komplett abschalten.

    RS Eggnog | VPS 1000 G10 | VPS 1000 G10 SE | VPS piko G11s | VPS nano G11s | VPS mikro G11s | Webhosting 4000 NUE ADV23

    Gefällt mir 5
    • Offizieller Beitrag

    Liebe Community,


    erstmal möchten wir uns für eure Geduld bei diesem Thema bedanken und freuen uns, euch heute ein Update aus unserem Development Team zu geben. 8)


    Wie ihr weiter oben schon gelesen habt, steht unser CEO Alexander Windbichler hier voll und ganz hinter uns. Inzwischen wurden von ihm zwei weitere Entwicklerstellen freigegeben die wir mittlerweile erfolgreich mit erfahrenen Entwicklern besetzen konnten. Die beiden neuen Kollegen werden aktuell eingearbeitet. Sie werden uns maßgeblich dabei unterstützen, euch alsbald stabile Nameserver mit DNSSEC zur Verfügung stellen zu können. :thumbup:


    Daran arbeiten wir auch bereits mit Hochdruck, doch ihr kennt das bestimmt: Wer schon mal an Neuentwicklungen gearbeitet hat, weiß, dass sich Releases verzögern können. Aktuell ist das hier der Fall. Der Grund liegt in von Alex oben erwähnten Cornercases, die wir beachten, durchdenken und testen müssen. Aktuell rechnen wir damit, euch in den Sommermonaten über den Release zu informieren.


    Übrigens: Wir möchten hier gerne euer geschätztes Feedback mit einbeziehen. Deshalb wird es für euch eine Beta-Phase geben und wir freuen uns darauf, euer Feedback einfließen zu lassen. Auf diese Weise wird das Produkt nochmal besser! Sobald wir soweit sind, melden wir uns erneut. :)


    Liebe Grüße,

    Claudia H. & das gesamte netcup-Team