Zusammenfassung

  • Im Jahr 2012 konnten AFRINIC-Mitglieder die DS-Daten ihrer signierten Reverse-DNS-Zonen durch eine Aktualisierung des passenden domain-Objekts in der WHOIS-Datenbank an den Veröffentlichungspfad zur übergeordneten Reverse-Zone übergeben. Belegt ist die Existenz dieses Pfads im Jahr 2012. Nicht belegt ist ein eigener genauer Aktivierungstag. Der 10. Mai 2012 gehört zum größeren Go-live der signierten AFRINIC-Reverse-Zonen mit bei IANA veröffentlichten DS-Datensätzen; er darf nicht stillschweigend als Startzeitpunkt der einzelnen Mitgliederfunktion ausgegeben werden.

  • Der DS-Datensatz ist kein dekoratives Attribut. Am Delegationspunkt verbindet er die übergeordnete Zone mit dem vorgesehenen DNSKEY der untergeordneten Zone. Seine vier protokollierten Bestandteile — Key Tag, Algorithmus, Digest-Typ und Digest — sind kompakt, doch ihre Wirkung ist groß. Stimmen Parent-DS und Child-DNSKEY nicht zusammen, können validierende Resolver die Antworten der Child-Zone verwerfen, obwohl gewöhnliche DNS-Server weiterhin antworten. Dadurch wird eine Registeränderung zu einer sicherheitskritischen Betriebsanweisung.

  • Die notwendige Kontrollkette beginnt nicht mit institutionellem Ermessen, sondern mit nachweisbarer Zuordnung. Wer den WHOIS-Eintrag ändern darf, muss für genau die betroffene Ressource und das genau betroffene Objekt autorisiert sein. Ein Ressourceninhaber, ein technischer Beauftragter, ein Benutzerkonto und eine Person, die in einem Konflikt Vertretungsmacht behauptet, sind nicht automatisch dasselbe. Sichere Buchführung muss diese Rollen auseinanderhalten, statt einen vorhandenen Zugang pauschal mit materieller Befugnis gleichzusetzen.

  • Auf die Autorisierung folgt eine eng begrenzte technische Prüfung: Syntax, unterstützter Algorithmus und Digest-Typ, Zuordnung zur richtigen Reverse-Zone, Übereinstimmung mit dem vorgesehenen Child-DNSKEY, Zustand der signierten Child-Zone, mögliche Duplikate sowie sichere Übergänge bei einem Schlüsselwechsel. Das sind Anforderungen an einen guten Kontrollpfad, keine Behauptung über die internen AFRINIC-Verfahren von 2012. Die versiegelte Überlieferung nennt weder den damaligen Objektaufbau noch Authentisierungsmethoden, Prüfalgorithmen, Bearbeitungszeiten oder Fehlermeldungen.

  • Veröffentlichung braucht eine lückenlose, unveränderliche Geschichte. Vorheriger und neuer DS-Wert, Antragsteller, Autorisierungsnachweis, maschinelle Prüfergebnisse, menschliche Eingriffe, Zeitpunkte, Empfänger von Benachrichtigungen und der beobachtete Veröffentlichungsstatus gehören in ein nachvollziehbares Änderungsjournal. Verifizierte administrative und technische Kontakte sollten vor und nach einer folgenreichen Änderung über voneinander unabhängige Kanäle informiert werden. Eine Ablehnung muss den engen technischen Mangel benennen und einen klaren Heilungsweg öffnen.

  • Rücknahme ist Teil der Sicherheit, nicht ihr Eingeständnis. Ein veralteter, vertippter, zu früh veröffentlichter oder unbefugt eingereichter DS kann eine funktionierende Zone aus Sicht validierender Resolver unbrauchbar machen. Der Pfad braucht daher eine schnelle authentisierte Korrektur, eine technisch notwendige Notfallentfernung, unabhängige Benachrichtigung, unveränderliche Historie und eine nachträgliche Erklärung. Derselbe Notfallweg darf jedoch nicht zu einer zweiten, schlechter kontrollierten Übernahmemöglichkeit werden.

  • AFRINICs Rolle bleibt in jedem Glied eng. Die Organisation darf die relevante Mitglieds-, Ressourcen- und Objektbeziehung protokollieren, eine Änderung authentisieren, notwendige technische Bedingungen prüfen, einen akzeptierten Datensatz veröffentlichen, Belege bewahren und einen gefährlichen Zustand korrigieren. Daraus entstehen weder Eigentum an der Nummernressource oder am privaten Schlüssel noch Souveränität, Gesetzgebung, Regulierung, Polizeigewalt, Strafgewalt, Konfiskationsmacht oder richterliche Zuständigkeit.

  • Das stärkste Argument für ein gewisses Maß an Prüfung ist zugleich das stärkste Argument gegen breite Willkür. Eine ungeprüfte Automatik wäre gefährlich, weil auch ein formal autorisierter Benutzer einen falschen oder schlecht getimten DS einreichen kann. Zulässig ist deshalb nur enges, überprüfbares Ermessen im Dienst von Identität, Objektbefugnis, Protokollgültigkeit und Betriebssicherheit. Unzulässig wäre es, den Parent-Zone-Zugang als Druckmittel in Mitgliedschafts-, Gebühren-, Geschäftsmodell-, Politik- oder sonstigen Streitigkeiten zu verwenden.

  • Die Beleglage verzeichnet keinen konkreten Angriff, Ausfall, falschen Antrag, Validierungsfehler, Supportfall, Rollback, Schlüsselwechsel oder Konflikt in diesem Pfad. Sie identifiziert auch die zwei Mitglieder nicht, von denen zum Jahresende 2012 insgesamt 49 DS-Datensätze für 13 Domains gemeldet wurden. Diese Zahl zeigt Nutzung, ist aber nur Kontext. Die Geschichte hier handelt nicht von allgemeiner DNSSEC-Einführung oder Akzeptanzstatistik, sondern ausschließlich vom Weg der Anweisung: signierte Reverse-Zone des Mitglieds, DS-Material, WHOIS-domain-Objekt, Verarbeitung durch AFRINIC, Veröffentlichung in der Parent-Zone, Wirkung beim Validator und nötigenfalls Korrektur.

  • Der institutionelle Schluss ist klar: Kryptografische Wirkung erhöht den Standard der Buchführung; sie erhebt die Buchführerin nicht zur Herrscherin. Je folgenreicher die technische Schnittstelle, desto genauer müssen Zweckbindung, Identitätsnachweis, objektbezogene Autorisierung, deterministische Prüfung, Benachrichtigung, begründete Zurückweisung, Versionsgeschichte, Notfallkorrektur, Rollback und Ausfallsicherheit sein. Jede Beeinträchtigung, die nicht der engen Integrität der Delegation dient, ist Mandatsausweitung und keine DNSSEC-Sicherheit.