Zusammenfassung

  • Der neue KSK wird vor seiner Nutzung veröffentlicht und überlappt mit dem alten, damit validierende Resolver ihren Vertrauensanker aktualisieren können.
  • BTW-Analyse: Der zentral ausgeführte Schlüsselwechsel aktualisiert keine verteilte Resolver-Software. Kontinuität verlangt beobachtbare Akzeptanz im Übergangsfenster.

Quellen: Erklärung des KSK-Wechsels und LACNICs DNSSEC-Messmethode.

Die DNSSEC-Validierung beginnt beim KSK der Root-Zone als Vertrauensanker und folgt der Signaturkette nach unten. Kennt ein Resolver den neuen Vertrauensanker nicht, kann er gültige Antworten ablehnen. Die von LACNIC veröffentlichte Erklärung der IANA Services beschreibt daher eine frühe Veröffentlichung und eine Phase, in der beide Schlüssel vertraut werden.

LACNICs Studie macht Validierung beobachtbar. Atlas-Sonden fragen eine Domain mit absichtlich fehlerhaften Signaturen ab: SERVFAIL zeigt die Ablehnung, NOERROR fehlende Validierung. Anonymisierte Mitschnitte suchen zusätzlich nach DNSSEC-Datensätzen.

Die Autoren warnen jedoch, dass Atlas-Sonden oft in fortgeschrittenen Netzen stehen. Die Stichprobe kann eine Obergrenze statt einer Vollerhebung sein. Auch ein früher Test garantiert nicht den gesamten Übergang. Entscheidend ist, welche Resolver-Gruppen den neuen Anker vor der Stilllegung des alten noch nicht angenommen haben.