Ist die .de-TLD wegen DNSSEC offline?

 (dnssec-analyzer.verisignlabs.com)
1 Punkte von GN⁺ 1 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Das Ergebnis des nic.de-DNSSEC-Debuggers basiert auf dem Stand 2026-05-06 00:38:26 UTC und prüft die Vertrauenskette vom Root über .de bis zu nic.de Schritt für Schritt
  • Die Root-Zone enthält DS=20326/SHA-256 und DS=38696/SHA-256, und der DS-Eintrag keytag 26755 für die Delegation von .de wird durch die Signatur des Root-DNSKEY=54393 verifiziert
  • Die .de-Zone enthält DNSKEY=26755/SEP und DNSKEY=32911, und DS=26755/SHA-256 verifiziert das DNSKEY RRset von .de
  • Die Delegation von nic.de enthält die Nameserver ns1.denic.de, ns2.denic.de, ns3.denic.de, ns4.denic.net, und DS=26155/SHA-256 wird durch .des DNSKEY=32911 verifiziert
  • Der A-Record von nic.de wird bei allen Abfragen an autoritative Nameserver als 81.91.170.12 bestätigt, und RRSIG=36463 sowie DNSKEY=36463 verifizieren das entsprechende RRset

nic.de DNSSEC-Verifizierungsablauf

  • Das Prüfziel ist nic.de, und auf dem DNSSEC-Debugger-Bildschirm werden als Detail-Steuerung more(+) und less(-) angezeigt
  • Die angezeigte Zeit ist 2026-05-06 00:38:26 UTC
  • Der DNSSEC-Status von nic.de kann auch unter dnsviz.net getestet werden

Vertrauenskette vom Root bis .de

  • Verifizierung des DNSKEY der Root-Zone

    • In der Vertrauenskette sind DS=20326/SHA-256 und DS=38696/SHA-256 des Root (.) enthalten
    • An j.root-servers.net wurde ./DNSKEY abgefragt, dabei wurde von 192.58.128.30 eine Antwort mit 1139 Byte empfangen, und der Antwortcode war NOERROR
    • In der Root-Zone wurden 3 DNSKEY-Records bestätigt
      • DNSKEY keytag 54393, Flags 256, Algorithmus 8
      • DNSKEY keytag 20326, Flags 257, Algorithmus 8
      • DNSKEY keytag 38696, Flags 257, Algorithmus 8
    • DNSKEY=20326/SEP und DNSKEY=38696/SEP wurden in die Vertrauenskette aufgenommen und jeweils durch DS=20326/SHA-256 bzw. DS=38696/SHA-256 verifiziert
    • Das Root-DNSKEY RRset enthält 1 RRSIG, und RRSIG=20326 sowie DNSKEY=20326/SEP verifizieren dieses DNSKEY RRset
    • Auch DNSKEY=54393 ist in der Vertrauenskette enthalten

  • Prüfung der Delegation von .de aus dem Root

    • An k.root-servers.net wurde nic.de/A abgefragt, dabei wurde von 193.0.14.129 eine Antwort mit 742 Byte empfangen; der Answer-Abschnitt war leer, und im Authority-Abschnitt waren die Delegationsinformationen für .de enthalten
    • Als .de-Nameserver wurden a.nic.de, f.nic.de, l.de.net, n.de.net, s.de.net, z.nic.de zurückgegeben
    • Der DS-Record von .de wurde mit keytag 26755, Algorithmus 8, Digest-Typ 2 und dem SHA-256-Digest f341357809a5954311ccb82ade114c6c1d724a75c0395137aa3978035425e78d zurückgegeben
    • Das .de-DS-RRset enthielt RRSIG, und der Signierer ist das Root-DNSKEY=54393
    • Der Additional-Abschnitt enthält die IPv4-/IPv6-Adressen der .de-Nameserver
      • a.nic.de: 194.0.0.53, 2001:678:2::53
      • f.nic.de: 81.91.164.5, 2a02:568:0:2::53
      • z.nic.de: 194.246.96.1, 2a02:568:fe02::de
      • l.de.net: 77.67.63.105, 2001:668:1f:11::105
      • n.de.net: 194.146.107.6, 2001:67c:1011:1::53
      • s.de.net: 195.243.137.26, 2003:8:14::53

  • Verifizierung des .de-DS-RRset

    • An b.root-servers.net wurde de/DS abgefragt, dabei wurde von 170.247.170.2 eine Antwort mit 366 Byte empfangen, und der Antwortcode war NOERROR
    • In der Root-Zone wurde 1 DS-Record für .de bestätigt
    • DS=26755/SHA-256 verwendet den Algorithmus RSASHA256
    • Das .de-DS-RRset enthält 1 RRSIG, und RRSIG=54393 sowie DNSKEY=54393 verifizieren dieses DS-RRset
    • DS=26755/SHA-256 ist in der Vertrauenskette enthalten

  • Verifizierung des .de-DNSKEY-RRset

    • An f.nic.de wurde de/DNSKEY abgefragt, dabei wurde von 81.91.164.5 eine Antwort mit 745 Byte empfangen, und der Antwortcode war NOERROR
    • In .de wurden 2 DNSKEY-Records bestätigt
      • DNSKEY keytag 32911, Flags 256, Algorithmus 8, TTL 3600
      • DNSKEY keytag 26755, Flags 257, Algorithmus 8, TTL 3600
    • DNSKEY=26755/SEP wurde in die Vertrauenskette aufgenommen, und DS=26755/SHA-256 verifiziert DNSKEY=26755/SEP
    • Das .de-DNSKEY RRset enthält 1 RRSIG, und RRSIG=26755 sowie DNSKEY=26755/SEP verifizieren dieses RRset
    • DNSKEY=32911 ist in der Vertrauenskette enthalten

Delegation und DS-Verifizierung von .de zu nic.de

  • Prüfung der Unterzone nic.de

    • An l.de.net wurde nic.de/A abgefragt, dabei wurde von 77.67.63.105 eine Antwort mit 464 Byte empfangen; der Answer-Abschnitt war leer, und die Delegationsinformationen für nic.de waren im Authority-Abschnitt enthalten
    • Als nic.de-Nameserver wurden ns1.denic.de, ns2.denic.de, ns3.denic.de, ns4.denic.net zurückgegeben
    • Der DS-Record von nic.de wurde mit keytag 26155, Algorithmus 8, Digest-Typ 2 und dem SHA-256-Digest 2f06c8cdf8673a2e98d72c8b7ab6067d9318458b3d9edccde1c5ef793c0c565d zurückgegeben
    • Das nic.de-DS-RRset enthielt RRSIG, und der Signierer ist .des DNSKEY=32911
    • Der Additional-Abschnitt enthält einige Adressen der nic.de-Nameserver
      • ns1.denic.de: 77.67.63.106, 2001:668:1f:11::106
      • ns2.denic.de: 81.91.164.6, 2a02:568:0:2::54
      • ns3.denic.de: 195.243.137.27, 2003:8:14::106
    • Auch bei einer Abfrage von nic.de/DNSKEY an l.de.net wurden dieselbe nic.de-Delegation, DS-, RRSIG- und Additional-Adressinformationen zurückgegeben, und die Unterzone nic.de wurde bestätigt

  • Verifizierung des nic.de-DS-RRset

    • An a.nic.de wurde nic.de/DS abgefragt, dabei wurde von 194.0.0.53 eine Antwort mit 245 Byte empfangen, und der Antwortcode war NOERROR
    • In der de-Zone wurde 1 DS-Record für nic.de bestätigt
    • Der bestätigte DS hat keytag 26155, Algorithmus 8, Digest-Typ 2 und wird als SHA-256-basiert angezeigt
    • Das DS RRset enthält 1 RRSIG, und RRSIG=32911 sowie DNSKEY=32911 verifizieren das DS RRset
    • DS=26155/SHA-256 ist in der Vertrauenskette enthalten
nic.de. 86400 IN DS (
  26155 8 2 2f06c8cdf8673a2e98d72c8b7ab6067d9318458b3d9edccde1c5ef793c0c565d
)

Verifizierung von nic.de-DNSKEY und Records

  • Verifizierung des nic.de-DNSKEY

    • An ns4.denic.net wurde nic.de/DNSKEY abgefragt, dabei wurde von 194.246.96.28 eine Antwort mit 625 Byte empfangen, und der Antwortcode war NOERROR
    • In nic.de wurden 2 DNSKEY-Records bestätigt
    • keytag 26155 ist ein DNSKEY im Format 257 3 8, und DNSKEY=26155/SEP wurde in die Vertrauenskette aufgenommen
    • DS=26155/SHA-256 verifiziert DNSKEY=26155/SEP
    • Das DNSKEY RRset enthält 1 RRSIG, und RRSIG=26155 sowie DNSKEY=26155/SEP verifizieren das DNSKEY RRset
    • Auch DNSKEY=36463 ist in der Vertrauenskette enthalten
nic.de. 3600 IN DNSKEY (
  257 3 8 AwEAAb/xrM2MD+xm84YNYby6TxkMaC6PtzF2bB9WBB7ux7iqzhViob4GKvQ6L7CkXjyAxfKbTzrd
  vXoAPpsAPW4pkThReDAVp3QxvUKrkBM8/uWRF3wpaUoPsAHm1dbcL9aiW3lqlLMZjDEwDfU6lxLc
  Pg9d14fq4dc44FvPx6aYcymkgJoYvR6P1wECpxqlEAR2K1cvMtqCqvVESBQV/EUtWiALNuwR2Pbh
  wtBWJd+e8BdFI7OLkit4uYYux6Yu35uyGQ==
) ; keytag 26155

nic.de. 3600 IN DNSKEY (
  256 3 8 AwEAAdkJ06nJ8Cutng7f9HACMUhuYnF0CX7uCZ06CyauTxQIpOQpQBKI03/EPn8fI518pvOqxAO7
  XWaGsSovRyI3UPd963JZpYrEOcVDFPA2Qrz5eFj8MIBKH6HcQGnum0UFxmIRVaKT5K5WM+xeUeP5
  Xr4P54Jkyo18rz0LwzDp9gjj
) ; keytag 36463

  • Verifizierung des nic.de-A-Records und der Signatur

    • Abfragen von nic.de/A an ns1.denic.de, ns2.denic.de, ns3.denic.de und ns4.denic.net wurden alle mit NOERROR beantwortet
    • Die Antwortquellen je Nameserver sind 77.67.63.106 für ns1.denic.de, 81.91.164.6 für ns2.denic.de, 195.243.137.27 für ns3.denic.de und 194.246.96.28 für ns4.denic.net
    • Bei allen A-Abfragen wurde der A-Record-Wert von nic.de als 81.91.170.12 bestätigt
    • Jede Antwort enthält ein von der nic.de-Zone signiertes RRSIG, und im A RRset wurde 1 RRSIG bestätigt
    • RRSIG=36463 und DNSKEY=36463 verifizieren das A RRset
nic.de. 3600 IN A 81.91.170.12

nic.de. 3600 IN RRSIG (
  A 8 2 3600 20260519222346 20260505205346 36463 nic.de.
  VIyuPDO6Bf029ILioOvWPhkPmQctDIepz+bK/7s7GS1hHEIZrs/9pDGblfW19sjmVpJGIslYmiGh
  QUDTgJcv8lcWqrfUK3pTv9QxmYRDOMM/zTZz50hqfcNkvzL7dg/7A/yPoPk3aTMXH3pFNY0N2RnU
  t8THHOfUcu3w19fma4w=
)

  • Autoritative Nameserver und SOA-Antworten

    • Als autoritative Nameserver von nic.de wurden ns1.denic.de, ns2.denic.de, ns3.denic.de, ns4.denic.net in den Antworten aufgeführt
    • An ns3.denic.de, ns4.denic.net und ns2.denic.de wurden nic.de/SOA-Abfragen gesendet; alle lieferten Antworten mit 507 Byte und NOERROR
    • Der SOA-Record zeigt ns1.denic.de. als primären Nameserver und dns-operations.denic.de. als verantwortliche Stelle
    • Die SOA-Werte sind identisch: serial 1778019826, refresh 10800, retry 1800, expire 3600000, minimum 1800
    • Auch die SOA-Antworten enthalten RRSIG, und als Signierer wird 36463 nic.de. angezeigt
nic.de. 3600 IN SOA (
  ns1.denic.de. dns-operations.denic.de.
  1778019826 ;serial
  10800 ;refresh
  1800 ;retry
  3600000 ;expire
  1800 ;minimum
)

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 시간 전
Hacker-News-Kommentare

  • Sieht nach einem DNSSEC-Problem aus, nicht nach einem Ausfall der Nameserver. Validierende Resolver geben für alle .de-Namen SERVFAIL zusammen mit EDE zurück
    dig +cd amazon.de @8.8.8.8 und dig amazon.de @a.nic.de funktionieren, daher wirken die Zonendaten intakt. DENIC hat eine RRSIG für NSEC3-Records ausgeliefert, die sich nicht mit ZSK 33834 validieren lässt, weshalb alle validierenden Resolver die Antworten verwerfen
    Dass es nur gelegentlich funktioniert, passt zu Anycast. Einige Instanzen von [a-n].nic.de liefern wohl noch die vorherige gültige Signatur aus, sodass Wiederholungen manchmal einen funktionierenden autoritativen Server treffen. Laut DENIC-FAQ wird der .de-ZSK alle 5 Wochen per Pre-Publishing ausgetauscht, daher riecht das nach einem fehlgeschlagenen Rollover

    • Ein einzelner Konfigurationsfehler hat also die externe Erreichbarkeit eines großen Wirtschaftsraums lahmgelegt. Es passierte am Abend Ortszeit, und selbst unter Berücksichtigung der Cache-TTLs sollte es bis zum Morgen behebbar sein, sodass das Schadensausmaß wohl etwas begrenzt bleibt
      Trotzdem ist fragile Infrastruktur auf diesem Niveau ein politisches Risiko. Die berühmte Eigenschaft des Internets, „um beschädigte Stellen herumzurouten“, hilft hier nicht besonders gut. Das dürfte eine interessante Post-Mortem-Analyse geben
    • Ich arbeite seit 20 Jahren in der IT und außer DNSSEC verstehe ich hier kein einziges Akronym

  • Das DENIC-Team war heute Abend wohl auf einer Party. Feiern ist ja schön, aber man hätte es nicht übertreiben sollen
    https://bsky.app/profile/denic.de/post/3ml4r2lvcjg2h

    • Ein interessanter Bus-Faktor, wenn in einer Notlage ausgerechnet alle Leute, die qualifiziert, erfahren und vertrauenswürdig genug sind, Betriebsänderungen zu committen, vermurkste Wartung rückgängig zu machen oder ein Rollback durchzuführen, nicht mehr ganz nüchtern sind

  • Ich habe DNSSEC nie benutzt und auch nie versucht, es zu implementieren, aber wenn ich das richtig verstehe, wurde auf das eigentlich dezentrale DNS eine hierarchische Zertifikatsstruktur mit Single Point of Failure gesetzt. Und jetzt führt ein Ausfall der zentralen Organisation, die diese Zertifikate verwaltet, faktisch dazu, dass alle Domains gemeinsam kaputtgehen?

    • Die .de-Top-Level-Domain wird im Wesentlichen ohnehin von einer einzelnen Organisation verwaltet, und auch wenn deren Nameserver ausfallen würden, wäre die Lage nicht viel besser. Einige Records wären noch in nachgelagerten Resolvern gecacht, aber nicht alle und auch nicht lange
      DNSSEC macht DNS eher dezentraler. Ohne DNSSEC müsste man, um vertrauenswürdige Antworten sicherzustellen, direkt bei den autoritativen Nameservern anfragen. Mit DNSSEC kann man stattdessen einen Cache-Resolver eines Dritten fragen und ihm trotzdem vertrauen, weil nur legitime Antworten gültige Signaturen tragen
      Ebenso müssten Domaininhaber ohne DNSSEC ihren autoritativen Nameservern vollständig vertrauen, weil diese sonst problemlos gefälschte „vertrauenswürdige“ Ergebnisse liefern könnten. Mit DNSSEC muss man autoritativen Nameservern deutlich weniger vertrauen [0], sodass sich Teile davon sicher bei Dritten hosten lassen
      [0]: https://news.ycombinator.com/item?id=47409728
    • DNSSEC ändert nichts am Grad der Dezentralisierung von DNS. DNS war schon immer hierarchisch aufgebaut. Ohne Caching beginnt jede DNS-Anfrage mit einer Anfrage an die Root-DNS-Server
      Bei foo.com oder foo.de fragt man zuerst die Root-Server, um die für .com bzw. .de zuständigen Nameserver zu erfahren, und dann die .com- oder .de-Server, um die Nameserver für foo.com bzw. foo.de zu ermitteln. DNSSEC signiert diese Antworten lediglich und fügt die Public Keys hinzu, mit denen sich die Antworten der nächsten Stufe authentifizieren lassen
      Die Liste der IPs der Root-Nameserver ist in allen lokalen rekursiven DNS-Resolvern enthalten. Diese Liste ändert sich über Jahre hinweg nur langsam. Mit DNSSEC sind in dieser Liste auch die Public Keys der Root-Server enthalten, und auch diese werden nur langsam ausgetauscht
    • Was wir hier sehen, ist Dezentralisierung in Aktion. Das Problem liegt beim Betreiber der .de-Top-Level-Domain, deshalb ist auch nur diese Top-Level-Domain betroffen
      DNS ist nicht so dezentral aufgebaut, dass die Infrastruktur einer einzelnen Top-Level-Domain von mehreren Organisationen betrieben wird. Eine Top-Level-Domain wird immer von einem einzigen Akteur betrieben. .com und .net werden von Verisign betrieben
      Das Problem beim Betreiber verändert den Wirkungsbereich also nicht

  • Cloudflare deaktiviert jetzt die DNSSEC-Validierung im Resolver 1.1.1.1: https://www.cloudflarestatus.com/incidents/vjrk8c8w37lz

    • Spätestens an diesem Punkt kann man wohl sagen, dass DNSSEC erledigt ist
    • Falls sich herausstellt, dass das DNSSEC-Problem von einem Bedrohungsakteur verursacht wurde, könnte genau dieser nachgelagerte Effekt das eigentliche Ziel gewesen sein

  • Ich lasse hier mal Thomas Ptaceks berühmten Text zu DNSSEC da
    https://sockpuppet.org/blog/2015/01/15/against-dnssec/

  • Völlig verrückt. Ich kann mich nicht erinnern, dass so etwas schon einmal passiert ist, und es ist immer noch nicht behoben? .de ist wirtschaftlich wahrscheinlich die wichtigste uneingeschränkte Domain nach .com. Damit sind Millionen Unternehmen faktisch „down“

  • Ja, wegen DENICs DNSSEC-Fehler sind alle .de-Domains ausgefallen
    https://dnsviz.net/d/de/dnssec/

  • Ich bin wohl zu früh hier. In diesem Thread gibt es noch keinen einzigen DNSSEC-Rant von tptacek

    • Was müsste ich da noch groß reden? Manchmal übernimmt die Welt das für mich
    • Sagt dieses Ereignis nicht schon alles?

  • Ich war total gestresst, weil meine Dienste und Apps über meine Domain überhaupt nicht erreichbar waren. Über mobile Daten ging es nur, und ich bin froh, dass es diesmal nicht mein Fehler war

    • Aber wir sind immer noch Deutsche, also brauchen wir jemanden, dem wir die Schuld geben können

  • Auf https://status.denic.de/ wird der DNS Nameservice jetzt als „Partial Service Disruption“ angezeigt
    Bearbeitung: Jetzt steht dort „Service Disruption“

    • Dass selbst dann, wenn in der drittgrößten Volkswirtschaft der Welt alle Websites ausfallen, immer noch von einer „teilweisen“ Service-Störung gesprochen wird :D
    • Ganz Deutschland ist offline und DENIC spricht von „Partial Service Disruption“. Eine eigene Ausdrucksweise haben sie ja
    • Jetzt steht da „Server Not Found“
    • „All Systems Operational“