Zusammenfassung

  • Greasing nutzt unzugeteilte DNS-Werte, um Intoleranz vor der Einführung echter Erweiterungen sichtbar zu machen und den späteren Bedarf an Fallback zu verringern.
  • Ein erfolgreicher Retry ohne Erweiterung schützt die Auflösung, kann aber einem Angreifer erlauben, eine Sicherheitsfunktion still zu entfernen; Erstfehler, Wiederherstellung und Abschaltkriterium müssen getrennt bleiben.

Die erste Anfrage enthält eine neue Sicherheitsoption und scheitert. Der Resolver versucht es ohne Option erneut, erhält eine gültige Antwort und liefert sie aus. Für den Verfügbarkeitsmonitor ist der Vorfall beendet. Für den Angreifer ist der gewünschte Zustand erreicht.

Die Antwort ist da. Der Schutz ist weg.

Revision 03 von Greasing Protocol Extension Points in the DNS beschreibt Greasing als vorbeugende Wartung gegen genau diese Zukunft. Unzugeteilte Werte werden regelmäßig benutzt, solange sie noch keine Semantik tragen. Pfade, die Unbekanntes ablehnen, sollen repariert werden, bevor eine echte Funktion davon abhängt.

Der Entwurf vom 6. Juli 2026 ist aktive DNSOP-Arbeitsgruppenarbeit mit beabsichtigtem Informational-Status. Er ist kein RFC und belegt keine Implementierung. Reservierte Bereiche, detailliertes Verhalten, Fallback und Telemetrie sind noch offen.

Fallback ist nicht neutral

Resolver sollten nach einem gescheiterten greased Versuch im Allgemeinen ohne den unzugeteilten Wert wiederholen. Das ist für einen Test vernünftig: Nutzer sollen nicht für Messung bezahlen. Bei neu konstruierten Abfragen, etwa einem unbekannten RR Type, ist Entfernen nicht immer dieselbe Operation.

Der Retry verändert eine Bedingung. Sein Erfolg ist ein Kontrollbeleg, kein Ersatz für den Erstfehler. Wird nur die letzte Antwort gespeichert, bleibt ein intoleranter Pfad unsichtbar.

Sobald eine echte Sicherheitsoption dieselbe Fehlerbehandlung nutzt, entsteht eine Angriffsfläche. Ein Gegner muss nicht Kryptografie brechen; er muss den Pfad so stören, dass Software die Option entfernt. Die normale Antwort kann DNSSEC-valid sein und dennoch ohne die zusätzliche Eigenschaft eintreffen.

Greasing soll zeigen, wo Fallback heute nötig ist, Reparatur auslösen und die spätere Entfernung vorbereiten. Es darf Fallback nicht als dauerhaften Vertrag etablieren.

Die erste Störung braucht einen eigenen Beleg

Eine belastbare Spur enthält greased Versuch, Wert, Erweiterungspunkt, Ziel, Transport, Zeitpunkt, Fehler oder Timeout, ungreased Retry und Nutzerergebnis. Beide Ereignisse werden verbunden, ohne zusammenzufallen.

Ein paralleler normaler Kontrollversuch kann Latenz vermeiden. Er kann aber eine andere Anycast-Instanz, Cache-Lage oder Route treffen. „Normal erfolgreich, grease fehlgeschlagen“ impliziert die geänderte Bedingung, lokalisiert aber nicht automatisch Server, Proxy, Load Balancer, Firewall oder Middlebox.

Reparaturverantwortung folgt dem Kontrollpunkt. Telemetrie, die den sichtbaren autoritativen Endpunkt beschuldigt, kann den falschen Betreiber belasten und das eigentliche Gerät unangetastet lassen.

Welche Werte getestet werden, verändert das Ergebnis

Zufällige Auswahl aus unzugeteiltem Raum prüft allgemeine Toleranz. Ein Wert kann später real zugeteilt werden; alte Software könnte ihn weiter als Grease senden oder ignorieren.

Ein reservierter Bereich verhindert Kollisionen und erleichtert Diagnose. Er kann selbst hartcodiert werden: Der Bereich passiert, alles andere Unbekannte bleibt gesperrt. Die Anti-Ossifikationsregel ist ossifiziert.

Revision 03 meldet keinen Konsens über Reservierungen. Manche Register sind klein, andere wie RR Type intern strukturiert. Ein IANA-Eintrag wäre Syntaxkoordination, keine Konformitätsbescheinigung.

Ein End-of-Test-Datum reduziert Kollisionsrisiko nur, wenn laufende Geräte tatsächlich stoppen. Registry-Stand, Release und wirksame Konfiguration bilden eine Beweiskette.

Greasing misst Toleranz, nicht künftige Semantik

Kandidaten sind DNS-Headerflags, Opcode, EDNS-Version und -Flags, Class, RR Type und EDNS Option Code. RCODE wird ausgelassen, weil willkürliche Statuscodes die Bedeutung der Antwort verändern. EDNS-Optionen brauchen neben einem unbekannten Code auch passende Zufallsdaten.

Ein erfolgreich ignorierter Wert zeigt, dass Unbekanntes toleriert wurde. Er beweist nicht, dass eine zukünftige Bedeutung korrekt ausgeführt wird. Ein Dashboard darf „Pfad toleriert Testwert“ nicht zu „Erweiterung unterstützt“ aufblasen.

Stichproben brauchen Grenzen

Der Entwurf diskutiert kleine Anteile und fragt beispielhaft nach einer von tausend Abfragen. Das ist keine Norm. Populäre Namen und große Plattformen können die Stichprobe dominieren; seltene Altanlagen fehlen.

Gemeinschaftliche Aggregation erweitert Sicht, vereinheitlicht aber nicht Kunden, Geografie, Werte, Transport oder Retry. Ohne Nenner und Schichtung ist eine globale Fehlerquote nicht belastbar.

DNS Error Reporting kann Hinweise an autoritative Betreiber senden. Der Bericht bleibt eine Aussage des Resolvers mit Spoofing- und Zustellgrenzen, kein fernes Urteil.

Der Responder kennt das Ergebnis nicht

Ein autoritativer Server kann unbekannte Werte in Antworten einfügen. Er weiß danach oft nicht, ob der Querier akzeptiert, einen anderen Server gewählt, aufgegeben oder eine Anwendung beschädigt hat. Senden ist kein Empfangsbeleg.

Gezielte Versuche brauchen kontrollierte Clients oder Rückmeldung. Der Entwurf sieht deshalb vor, responder-initiiertes Greasing standardmäßig abzuschalten.

Nichtzufällige Wertfolgen können Resolverprodukte fingerprinten. Auch eine Sicherheitswartung muss Identifizierbarkeit und Mehrverkehr begrenzen.

Die strategische Entscheidung betrifft nicht nur, ob Fallback existiert. Sie betrifft, ob die Organisation die Fähigkeit besitzt, ihn wieder zu entfernen. Jeder gerettete Request ohne Reparatur vergrößert die stille Abhängigkeit. Greasing ist erst abgeschlossen, wenn der intolerante Pfad korrigiert und der Downgrade-Ausweg geschlossen wurde.

Quellen