Zusammenfassung

  • RFC 3445 beschränkte neue KEY-Daten auf DNSSEC-Protokollwert 3, weil eine Abfrage keinen Untertyp wählen konnte und die Signatur alle Mitglieder des RRsets umfasste.
  • Die Migration verlief absichtlich asymmetrisch: nicht mehr alt schreiben, aber beim Lesen für die Prüfung erhalten; sonst änderte Filterung das signierte Set und ließ Caches auseinanderlaufen.

Ein gemeinsamer Behälter ohne gemeinsame Regeln

RFC 2535 gab KEY Flags, Protokolloktett, Algorithmus und öffentlichen Schlüssel. 1 stand für E-Mail, 2 für IPsec, 3 für DNSSEC, 4 für TLS; 5–254 waren offen, 255 galt für jedes Protokoll. DNS schien als allgemeines Schlüsselverzeichnis geeignet.

Doch der Client konnte nur den Typ KEY anfragen. Das innere Protokoll war kein Abfragefilter. Er erhielt das gesamte RRset eines Namens, und DNSSEC signierte ebenfalls die ganze Menge. Mehrere Zwecke teilten so Such-, Signatur- und Cache-Grenze.

RFC 3445 zog im Dezember 2002 aus begrenzter experimenteller Nutzung eine normative Grenze. Text, RFC-Editor-Eintrag, Datatracker, Historie, Referenzen, spätere Zitate und Errata belegen den Dokumentstand, nicht die Verbreitung.

Sechs Unterschiede hinter identischen Feldern

Zweck, Administrator, Authentifizierungsregel, Aufnahme in autoritative Antworten, Resolverbehandlung und Folgen von Ausfall oder Kompromittierung unterschieden sich. DNSSEC-Schlüssel gehören zur DNS-Integrität; Anwendungsschlüssel haben für DNS selbst keine besondere Bedeutung.

Ein gemischtes RRset wuchs mit fremden Anwendungen, vergrößerte Antworten und koppelte Rotationen. Missachtete Software das Protokollfeld, konnte sie einen kompromittierten Anwendungsschlüssel als Zonenschlüssel behandeln. Korrekte Kryptografie rettet keine falsche Autoritätszuweisung.

RFC 3445 verlangte Wert 3 für neue autoritative KEY-Daten, reservierte alle Flags außer Zonenbit 7 und schloss 1, 2, 4, 255 sowie den offenen Bereich. Neue Zuteilungen brauchten Standards Action. DNSSEC-Zwecke aus RFC 2930, RFC 2931 und RFC 3007 blieben, die Host/User-Unterscheidung nicht.

Bedeutung ablehnen, Beweis erhalten

Nicht-3-Werte durften DNS-Daten nicht authentifizieren, sollten aber bis zur Signaturprüfung im RRset bleiben. Der Signierer hatte die ursprüngliche Gesamtmenge abgedeckt. Vorheriges Entfernen prüfte andere Bytes und ließ SIG scheitern; unterschiedliche Filter ließen Caches verschiedene Mengen halten.

Semantische Ablehnung und Erhaltung des Prüfobjekts sind getrennt. Die sichere Reihenfolge lautet: alte Produktion schließen, Lesbarkeit behalten, Autorität verweigern, erst nach belegter Konvergenz löschen.

RFC 4033, 4034 und 4035 ersetzten später die 2535-Familie mit DNSKEY. SSHFP, CERT und TLSA zeigen zweckspezifische Behälter, ohne eine einzige Ursache zu beweisen. IANA belegt Registerzustand, nicht Implementierung oder Sicherheit.

Gemeinsam ist nur, was dieselbe Vertrauensregel trägt

Heng Lus Realitätsschichten trennen Registerwert, gültige Signatur, Verwaltungsmacht, laufenden Code und Ergebnis. Ein Format vereinigt diese Belege nicht. Vorrang laufenden Codes erklärt die Korrektur durch Experiment: reale Abfrage-, Signatur- und Cachekosten widerlegten die saubere Abstraktion, ohne Code zum Souverän zu machen.

Die minimale Anfangsspezifikation legt nahe, nur den kleinsten Kern mit gemeinsamem Zweck, Prüfung und Schadensbild zu standardisieren. DNS konnte seinen Infrastrukturschlüssel festlegen, ohne alle Anwendungsschlüssel zu regieren. Das ist redaktionelle Deutung, keine Motivbehauptung.

Gleiches Drahtformat ist kein gemeinsamer Vertrauensbereich. Wenn Abfrage, Signatur und Cache Objekte gemeinsam bewegen, ist die Set-Grenze bereits Sicherheits- und Verantwortungsgrenze.

Quellen