Le TLD .de est-il hors ligne à cause de DNSSEC ?

 (dnssec-analyzer.verisignlabs.com)
1 points par GN⁺ 1 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Le résultat du DNSSEC Debugger de nic.de est horodaté au 2026-05-06 00:38:26 UTC et vérifie pas à pas la chaîne de confiance depuis la racine jusqu’à nic.de en passant par .de
  • La zone racine contient DS=20326/SHA-256 et DS=38696/SHA-256, et le DS de la délégation .de, keytag 26755, est validé par la signature de la racine DNSKEY=54393
  • La zone .de contient DNSKEY=26755/SEP et DNSKEY=32911, et DS=26755/SHA-256 valide le DNSKEY RRset de .de
  • La délégation de nic.de inclut les serveurs de noms ns1.denic.de, ns2.denic.de, ns3.denic.de, ns4.denic.net, et DS=26155/SHA-256 est validé par DNSKEY=32911 de .de
  • L’enregistrement A de nic.de est confirmé comme étant 81.91.170.12 sur toutes les requêtes envoyées aux serveurs de noms autoritaires, et RRSIG=36463 avec DNSKEY=36463 valide ce RRset

nic.de flux de validation DNSSEC

  • La cible de l’analyse est nic.de, et l’écran du DNSSEC Debugger affiche les options de détail more(+) et less(-)
  • L’heure affichée est 2026-05-06 00:38:26 UTC
  • L’état DNSSEC de nic.de peut aussi être testé sur dnsviz.net

Chaîne de confiance de la racine à .de

  • Validation des DNSKEY de la zone racine

    • DS=20326/SHA-256 et DS=38696/SHA-256 de la racine (.) font partie de la chaîne de confiance
    • Une requête ./DNSKEY a été envoyée à j.root-servers.net, avec une réponse de 1139 octets reçue depuis 192.58.128.30, et le code de réponse était NOERROR
    • Trois enregistrements DNSKEY ont été confirmés dans la zone racine
      • DNSKEY keytag 54393, drapeau 256, algorithme 8
      • DNSKEY keytag 20326, drapeau 257, algorithme 8
      • DNSKEY keytag 38696, drapeau 257, algorithme 8
    • DNSKEY=20326/SEP et DNSKEY=38696/SEP ont été inclus dans la chaîne de confiance et validés respectivement par DS=20326/SHA-256 et DS=38696/SHA-256
    • Le DNSKEY RRset de la racine contient un RRSIG, et RRSIG=20326 avec DNSKEY=20326/SEP valide ce DNSKEY RRset
    • DNSKEY=54393 fait aussi partie de la chaîne de confiance

  • Vérification de la délégation .de depuis la racine

    • Une requête nic.de/A a été envoyée à k.root-servers.net, avec une réponse de 742 octets reçue depuis 193.0.14.129 ; la section réponse était vide et la section autorité contenait les informations de délégation de .de
    • Les serveurs de noms retournés pour .de sont a.nic.de, f.nic.de, l.de.net, n.de.net, s.de.net, z.nic.de
    • L’enregistrement DS de .de a été retourné avec keytag 26755, algorithme 8, digest type 2, et le digest SHA-256 f341357809a5954311ccb82ade114c6c1d724a75c0395137aa3978035425e78d
    • Le DS RRset de .de inclut un RRSIG, signé par DNSKEY=54393 de la racine
    • La section additional contient les adresses IPv4/IPv6 des serveurs de noms de .de
      • 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

  • Validation du DS RRset de .de

    • Une requête de/DS a été envoyée à b.root-servers.net, avec une réponse de 366 octets reçue depuis 170.247.170.2, et le code de réponse était NOERROR
    • Un enregistrement DS pour .de a été confirmé dans la zone racine
    • DS=26755/SHA-256 utilise l’algorithme RSASHA256
    • Le DS RRset de .de contient un RRSIG, et RRSIG=54393 avec DNSKEY=54393 valide ce DS RRset
    • DS=26755/SHA-256 fait partie de la chaîne de confiance

  • Validation du DNSKEY RRset de .de

    • Une requête de/DNSKEY a été envoyée à f.nic.de, avec une réponse de 745 octets reçue depuis 81.91.164.5, et le code de réponse était NOERROR
    • Deux enregistrements DNSKEY ont été confirmés pour .de
      • DNSKEY keytag 32911, drapeau 256, algorithme 8, TTL 3600
      • DNSKEY keytag 26755, drapeau 257, algorithme 8, TTL 3600
    • DNSKEY=26755/SEP a été inclus dans la chaîne de confiance, et DS=26755/SHA-256 valide DNSKEY=26755/SEP
    • Le DNSKEY RRset de .de contient un RRSIG, et RRSIG=26755 avec DNSKEY=26755/SEP valide ce RRset
    • DNSKEY=32911 fait partie de la chaîne de confiance

Délégation de .de vers nic.de et validation du DS

  • Vérification de la sous-zone nic.de

    • Une requête nic.de/A a été envoyée à l.de.net, avec une réponse de 464 octets reçue depuis 77.67.63.105 ; la section réponse était vide et les informations de délégation de nic.de figuraient dans la section autorité
    • Les serveurs de noms retournés pour nic.de sont ns1.denic.de, ns2.denic.de, ns3.denic.de, ns4.denic.net
    • L’enregistrement DS de nic.de a été retourné avec keytag 26155, algorithme 8, digest type 2, et le digest SHA-256 2f06c8cdf8673a2e98d72c8b7ab6067d9318458b3d9edccde1c5ef793c0c565d
    • Le DS RRset de nic.de inclut un RRSIG, signé par DNSKEY=32911 de .de
    • La section additional contient certaines adresses des serveurs de noms de nic.de
      • 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
    • Lorsqu’une requête nic.de/DNSKEY a aussi été envoyée à l.de.net, la même délégation nic.de, le même DS, le même RRSIG et les mêmes informations d’adresse additionnelles ont été retournés, confirmant la sous-zone nic.de

  • Validation du DS RRset de nic.de

    • Une requête nic.de/DS a été envoyée à a.nic.de, avec une réponse de 245 octets reçue depuis 194.0.0.53, et le code de réponse était NOERROR
    • Un enregistrement DS pour nic.de a été confirmé dans la zone de
    • Le DS confirmé utilise keytag 26155, algorithme 8, digest type 2, et est indiqué comme basé sur SHA-256
    • Le DS RRset contient un RRSIG, et RRSIG=32911 avec DNSKEY=32911 valide le DS RRset
    • DS=26155/SHA-256 fait partie de la chaîne de confiance
nic.de. 86400 IN DS (
  26155 8 2 2f06c8cdf8673a2e98d72c8b7ab6067d9318458b3d9edccde1c5ef793c0c565d
)

Validation des DNSKEY et des enregistrements de nic.de

  • Validation des DNSKEY de nic.de

    • Une requête nic.de/DNSKEY a été envoyée à ns4.denic.net, avec une réponse de 625 octets reçue depuis 194.246.96.28, et le code de réponse était NOERROR
    • Deux enregistrements DNSKEY ont été confirmés pour nic.de
    • Le keytag 26155 est un DNSKEY au format 257 3 8, et DNSKEY=26155/SEP fait partie de la chaîne de confiance
    • DS=26155/SHA-256 valide DNSKEY=26155/SEP
    • Le DNSKEY RRset contient un RRSIG, et RRSIG=26155 avec DNSKEY=26155/SEP valide le DNSKEY RRset
    • DNSKEY=36463 fait aussi partie de la chaîne de confiance
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

  • Validation de l’enregistrement A de nic.de et de sa signature

    • Les requêtes nic.de/A vers ns1.denic.de, ns2.denic.de, ns3.denic.de, ns4.denic.net ont toutes répondu NOERROR
    • Les sources de réponse par serveur sont 77.67.63.106 pour ns1.denic.de, 81.91.164.6 pour ns2.denic.de, 195.243.137.27 pour ns3.denic.de, et 194.246.96.28 pour ns4.denic.net
    • Dans toutes les requêtes A, la valeur de l’enregistrement A de nic.de a été confirmée comme étant 81.91.170.12
    • Chaque réponse inclut un RRSIG signé par la zone nic.de, et un RRSIG a été confirmé dans le A RRset
    • RRSIG=36463 avec DNSKEY=36463 valide le 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=
)

  • Serveurs de noms autoritaires et réponse SOA

    • Les serveurs de noms autoritaires de nic.de, ns1.denic.de, ns2.denic.de, ns3.denic.de, ns4.denic.net, sont inclus dans la réponse
    • Des requêtes nic.de/SOA ont été envoyées à ns3.denic.de, ns4.denic.net et ns2.denic.de, et toutes ont retourné des réponses de 507 octets avec NOERROR
    • L’enregistrement SOA indique ns1.denic.de. comme serveur de noms principal et dns-operations.denic.de. comme contact responsable
    • Les valeurs du SOA sont identiques : serial 1778019826, refresh 10800, retry 1800, expire 3600000, minimum 1800
    • Les réponses SOA incluent aussi un RRSIG, avec le signataire indiqué comme 36463 nic.de.
nic.de. 3600 IN SOA (
  ns1.denic.de. dns-operations.denic.de.
  1778019826 ;serial
  10800 ;refresh
  1800 ;retry
  3600000 ;expire
  1800 ;minimum
)

À lire aussi

1 commentaires

 
GN⁺ 1 시간 전
Commentaires Hacker News

  • Cela ressemble à un problème DNSSEC, pas à une panne des serveurs de noms. Les résolveurs qui valident renvoient SERVFAIL avec EDE pour tous les noms en .de
    dig +cd amazon.de @8.8.8.8 et dig amazon.de @a.nic.de fonctionnent, donc les données de zone semblent intactes. DENIC a publié une RRSIG d’enregistrement NSEC3 qui ne se valide pas avec la ZSK 33834, et tous les résolveurs validateurs rejettent donc la réponse
    Le caractère intermittent est cohérent avec l’anycast. Certaines instances de [a-n].nic.de diffusent encore l’ancienne signature valide, donc lors des nouvelles tentatives on tombe parfois sur un serveur autoritatif sain. D’après la FAQ de DENIC, la ZSK de .de est renouvelée toutes les 5 semaines via une publication anticipée, donc cela sent l’échec de rollover

    • Une seule erreur de configuration à un seul endroit a donc suffi à faire disparaître l’accessibilité externe d’une grande puissance économique. C’est arrivé en soirée heure locale, et même en tenant compte du TTL des caches, ce sera sans doute corrigé d’ici le matin, donc l’ampleur des dégâts devrait rester limitée
      Cela dit, à ce niveau, une infrastructure fragile représente un risque politique. La fameuse propriété d’Internet consistant à « contourner les zones endommagées » ne fonctionne pas très bien ici. On aura probablement droit à une analyse post-mortem intéressante
    • Je travaille dans l’IT depuis 20 ans et à part DNSSEC, je ne comprends aucun des sigles ici

  • On dirait que l’équipe de DENIC était en soirée ce soir. Qu’ils s’amusent, oui, mais sans trop en faire
    https://bsky.app/profile/denic.de/post/3ml4r2lvcjg2h

    • Scénario intéressant de bus factor : en situation d’urgence, toutes les personnes ayant les compétences, l’expérience et la confiance nécessaires pour valider un changement en prod, annuler une maintenance ratée ou faire un rollback ne sont potentiellement plus totalement sobres

  • Je n’ai jamais utilisé DNSSEC ni essayé de l’implémenter, mais si j’ai bien compris, on a pris le DNS, qui était à l’origine décentralisé, et on lui a ajouté une hiérarchie de certificats à point de défaillance unique. Et maintenant, à cause d’une panne de l’organisation centrale qui gère ces certificats, pratiquement tous les domaines cassent en même temps ?

    • Le TLD .de est de toute façon géré en pratique par une seule organisation, et si ses serveurs de noms tombent, la situation n’est pas vraiment meilleure. Certains enregistrements seront mis en cache dans des résolveurs en aval, mais pas tous, et pas pour longtemps
      DNSSEC rend plutôt le DNS plus décentralisé. Sans DNSSEC, il faut interroger directement les serveurs de noms autoritatifs pour garantir une réponse fiable. Avec DNSSEC, on peut interroger un résolveur cache tiers et lui faire confiance, car seules les réponses légitimes portent une signature valide
      De même, sans DNSSEC, le propriétaire d’un domaine doit faire une confiance absolue à ses serveurs de noms autoritatifs, puisqu’ils peuvent facilement falsifier des résultats considérés comme fiables. Avec DNSSEC, on a besoin de beaucoup moins leur faire confiance [0], ce qui permet d’en héberger une partie de façon sûre chez des tiers
      [0]: https://news.ycombinator.com/item?id=47409728
    • DNSSEC ne change pas le degré de décentralisation du DNS. Le DNS a toujours été hiérarchique. Sans cache, toute requête DNS commence par une requête vers les serveurs DNS racine
      Pour foo.com ou foo.de, on interroge d’abord les serveurs racine pour connaître les serveurs responsables de .com et .de, puis on demande aux serveurs .com ou .de quels sont les serveurs de noms de foo.com et foo.de. DNSSEC ne fait qu’ajouter des signatures à ces réponses, ainsi que des clés publiques permettant d’authentifier la réponse de l’étape suivante
      La liste des adresses IP des serveurs racine est incluse dans tous les résolveurs DNS récursifs locaux. Elle change lentement au fil des années. Avec DNSSEC, cette liste contient aussi les clés publiques des serveurs racine, qui sont elles aussi renouvelées lentement
    • Ce qu’on voit ici, c’est justement la décentralisation en action. Le problème se situe chez l’opérateur du TLD .de, et seul ce TLD est donc touché
      Le DNS n’est pas décentralisé au sens où l’infrastructure d’un même TLD serait opérée par plusieurs organisations. Un TLD est toujours exploité par une seule entité. .com et .net sont exploités par Verisign
      Donc un problème chez l’opérateur ne change pas réellement le périmètre d’impact

  • Cloudflare désactive désormais la validation DNSSEC sur son résolveur 1.1.1.1 : https://www.cloudflarestatus.com/incidents/vjrk8c8w37lz

    • À ce stade, on peut presque considérer que DNSSEC est mort
    • Si le problème DNSSEC s’avère avoir été causé par un acteur malveillant, cela visait peut-être justement ce type d’impact en cascade

  • Je laisse ici l’excellent texte de Thomas Ptacek sur DNSSEC
    https://sockpuppet.org/blog/2015/01/15/against-dnssec/

  • C’est dingue. Je ne me souviens même pas d’un incident similaire auparavant, et ce n’est toujours pas réparé ? .de est probablement le domaine sans restriction le plus important économiquement après .com. Cela revient à mettre hors ligne des millions d’entreprises

  • Oui, tous les domaines .de sont tombés à cause de l’échec DNSSEC de DENIC
    https://dnsviz.net/d/de/dnssec/

  • Je suis arrivé trop tôt. Il n’y a pas encore une seule grande tirade de tptacek sur DNSSEC dans ce fil

    • Qu’aurais-je besoin de dire longuement ? Parfois, le monde parle à ma place
    • Cet incident ne parle-t-il pas déjà de lui-même ?

  • J’étais en train de devenir fou parce que plus rien ne se connectait à mes services et applis sur mon domaine. Ça ne fonctionnait qu’en données mobiles, donc pour une fois, c’était rassurant de voir que ce n’était pas ma faute

    • Cela dit, nous sommes allemands, donc il nous faut bien quelqu’un à blâmer

  • Sur https://status.denic.de/, le service DNS Nameservice est maintenant indiqué comme « Partial Service Disruption »
    Édition : c’est maintenant passé à « Service Disruption »

    • Même si tous les sites de la 3e économie mondiale tombent, cela reste une panne « partielle » :D
    • L’Allemagne entière est hors ligne et DENIC parle de « Partial Service Disruption ». Formulation originale, disons
    • Maintenant, il affiche « Server Not Found »
    • « All Systems Operational »