Zusammenfassung

  • Revision 03 des DNSOP-Entwurfs zu GREASE will DNS-Erweiterungspunkte mit nicht zugeteilten Werten betätigen, damit Implementierungen und Middleboxes heutige Belegungen nicht zur einzigen erlaubten Liste machen. Der Text ist ein aktiver, unfertiger Internet-Draft, keine RFC und kein Einsatzbefehl.
  • Ein nachgelagerter Normalversuch kann die Antwort retten, aber Latenz hinzufügen. Eine parallele Kontrollanfrage schützt die Antwortzeit, erhöht jedoch die Last der autoritativen Seite. Vom Responder gestartetes GREASE kann Schäden beim Client auslösen, die der Initiator nicht sieht.
  • Vor einer Voreinstellung sollte eine befristete Versuchscharta Erweiterungspunkt, Wertewahl, Stichprobe, Ausschlüsse, Latenz- und Volumenbudgets, Telemetrie, Fingerprinting, Ablaufdatum, Abbruchschwellen und Rückfallverantwortung binden. Das ist Daniel Kades Vorschlag, keine IETF-Vorgabe.

Ein freies Feld ist nicht automatisch ein nutzbares Feld. Wenn über Jahre kein neuer Wert erscheint, wird aus Gewohnheit eine Regel. Software akzeptiert nur noch Bekanntes; Zwischenboxen tun es ihr gleich. Der Fehler stört den alten Betrieb nicht und kann sich deshalb unbemerkt verbreiten. Erst eine echte Erweiterung entdeckt, dass der formell offene Raum praktisch verschlossen ist.

GREASE verschiebt diesen Test nach vorn. Die Technik erzeugt Werte ohne Nutzbedeutung, die ein Empfänger ignorieren soll. RFC 8701 führte dafür im TLS-Ökosystem verstreute reservierte Werte ein. Ein korrekter Peer arbeitet weiter; ein intoleranter Peer zeigt seinen Defekt, bevor eine spätere Fähigkeit von ihm abhängt.

Der DNSOP-Entwurf Greasing Protocol Extension Points in the DNS überträgt den Ansatz auf DNS. Revision 03 erschien am 6. Juli 2026 und läuft am 7. Januar 2027 ab. Sie ist Arbeitsstand einer IETF-Arbeitsgruppe und kann geändert oder ersetzt werden. Reservierte Bereiche sind nicht konsentiert. Der entsprechende Abschnitt enthält noch einen Platzhalter. Detailliertes Verhalten, Fehlererkennung, Fallback, Testende, einzelne Abschalter und Telemetrieteilung stehen ausdrücklich auf einer Arbeitsliste.

Das ist kein Argument gegen Erprobung. Es ist ein Argument dagegen, aus implementierbarem Code bereits eine allgemeine Betriebserlaubnis abzuleiten.

Der Sammelbegriff verdeckt sieben verschiedene Eingriffe

Der Entwurf nennt das letzte freie DNS-Header-Flag, Opcode, EDNS-Version, EDNS-Flags, Class, Resource Record Type und EDNS Option Code. Die Räume reichen von einem einzelnen Bit bis zu mehr als sechzigtausend derzeit freien Nummern. Mit jeder IANA-Zuteilung kann sich der Bestand verändern.

RCODE und Extended RCODE fehlen bewusst. Sie beschreiben den Zustand einer Antwort. Eine Änderung würde die Bewertung des Fragenden beeinflussen und nicht bloß prüfen, ob ein unbekannter Zusatz folgenlos ignoriert wird.

GREASE ist daher nicht einfach eine absichtlich kaputte DNS-Nachricht. Der unbekannte Wert sitzt in einem dafür vorgesehenen Raum und trägt absichtlich keine Nutzsemantik. Wird er ignoriert, bleibt das Gelenk beweglich. Scheitert die Transaktion, ist eine Unverträglichkeit sichtbar. Der konkrete Verursacher ist damit noch nicht bestimmt.

Auch innerhalb der Kandidaten unterscheiden sich die Versuche. Eine EDNS-Option enthält Code und Daten. Ein unbekannter RR Type kann eine neue Anfrage verlangen. Eine Reservierungsregel für 16 Bit passt nicht zu einer einzigen Flag-Position. Genehmigt werden sollte deshalb ein genaues Feld in einer genauen Richtung mit definierter Kontrollanfrage, nicht eine pauschale Produktfunktion.

Fallback verteilt die Rechnung

Im seriellen Modell sendet der Resolver zunächst die GREASE-Anfrage. Scheitert sie, wiederholt er sie ohne den unbekannten Zusatz. Der Nutzer erhält womöglich ein korrektes Endergebnis, wartet aber auf den ersten Fehlschlag. Ein Verfügbarkeitsdiagramm, das nur das Ende misst, verbucht die Transaktion als Erfolg und verliert den eigentlichen Befund.

Im parallelen Modell gehen eine normale und eine GREASE-Anfrage gleichzeitig hinaus. Die normale Antwort dient dem Nutzer; die experimentelle Antwort wird nur gemessen. Die Antwortzeit bleibt geschützt, dafür bearbeiten Autorität und Transportweg zusätzlichen Verkehr.

Serieller Betrieb belastet ein Latenzbudget. Paralleler Betrieb belastet Abfragevolumen, Rechenzeit und Ausleitung. Beide erzeugen Protokolle, Warnungen und Diagnosearbeit. Der Versuchseigner erhält die Erkenntnis, während ein fremder Betreiber einen Teil der Kosten trägt.

Revision 03 empfiehlt eine kleine Stichprobe und nennt fragend vielleicht eine von tausend Anfragen. Das Fragezeichen ist keine Nebensache. Der Wert ist weder normative Schwelle noch Kapazitätsnachweis. Ein Promille eines weltweiten Resolvers kann auf einer kleinen autoritativen Plattform noch immer eine erhebliche Spitzenlast erzeugen.

Versuchsregeln brauchen Quote und absolute Grenze, global und pro Ziel. Störungszeiträume, bekannte schwache Ziele und besonders folgenreiche Dienste sollten ausgenommen werden können. Vor jeder Ausweitung müssen der normale Dienstpfad, der experimentelle Vergleich und der einzelne Abschalter nachweisbar funktionieren.

Die Rückrichtung nimmt dem Initiator Sicht

Beim Resolver beginnt der Versuch dort, wo die Messung liegt. Der Initiator kennt den Wert, sieht eine nahe Antwort oder deren Ausbleiben und kann mit einer normalen Anfrage vergleichen. Das lokalisiert den Defekt nicht, liefert aber zwei kontrollierte Enden.

Ein autoritativer Responder könnte ebenso ein unbekanntes Flag, eine Option oder eine höhere Version in seine Antwort einsetzen. Für gezielte Messungen kann das nützlich sein. Der Server erfährt aber womöglich nicht, ob der Resolver die Antwort akzeptierte, einen anderen Server fragte, still aufgab oder bei einer Anwendung einen Ausfall auslöste.

Der Entwurf sagt deshalb, responder-initiiertes GREASE solle standardmäßig abgeschaltet sein. Diese Trennung darf eine Benutzeroberfläche nicht in einem einzigen Häkchen auflösen. Die Zustimmung zu ausgehenden Resolver-Tests ist keine Zustimmung zu experimentellen autoritativen Antworten.

Ein Serverversuch benötigt benannte Zonen oder Verkehrsklassen, externe Client-Beobachtung, strengere Grenzen und einen sofortigen Abschaltweg. Wo der Initiator den Endschaden nicht sieht, beweist ein ruhiges Serverprotokoll nichts über den Nutzer.

Reservierte Werte und freie Werte scheitern unterschiedlich

Ein reservierter GREASE-Bereich lässt sich in Mitschnitten erkennen und kollidiert später nicht mit einer normalen Zuteilung. Doch Empfänger können genau diesen bekannten Bereich hart codiert tolerieren und jeden anderen unbekannten Wert weiter ablehnen. Der Test erscheint erfolgreich, obwohl die allgemeine Erweiterbarkeit unverändert schlecht ist.

Zufällige Auswahl aus dem heute unzugeteilten Raum erschwert eine solche Sonderbehandlung. Dafür kann IANA eine verwendete Nummer später einer echten Funktion zuteilen. Alte Software hat dann gelernt, gerade diese Nummer wegzuwerfen und könnte ihre neue Bedeutung weiter ignorieren.

Der Entwurf nennt ein vorkonfiguriertes oder konfigurierbares Testende als Gegenmittel. Das Ablaufdatum ist eine Drahtsicherheitsregel. Es stoppt alte Annahmen und zwingt bei einer Verlängerung zum erneuten Vergleich mit dem Register.

Die IANA-Seite für DNS-Parameter war beim Rechercheabschluss am 28. August 2026 aktualisiert. Sie führt getrennte Register für Classes, RR Types, OpCodes, EDNS-Optionen, Flags und Versionen. Sie enthält keine fertige Antwort auf die im Entwurf offenen DNS-GREASE-Bereiche.

Eine gespeicherte Registeraufnahme belegt, welchen Zustand der Betreiber beim Start kannte. Sie schafft kein dauerhaftes Nutzungsrecht. Schneidet eine neue Zuteilung die aktive Wertemenge, muss der Versuch automatisch auslaufen statt bis zum ersten Vorfall weiterzumachen.

Telemetrie muss den Eingriff rechtfertigen

Ein Fehler ohne verwertbare Diagnose ist kein Beitrag zur Erweiterbarkeit. Der allgemeine Greasing-Entwurf beschreibt ein enges Fenster: Bei zu seltener Nutzung verschwinden Befunde im Grundrauschen; bei zu regelmäßiger Nutzung erkennen Empfänger das Muster und behandeln es gesondert.

DNS-Fallback erzeugt zwei Wahrheiten. Der Dienst kann nach der Wiederholung erfolgreich sein, obwohl der Test scheiterte. Ein Mindestereignis sollte Erweiterungspunkt, Werteklasse, Algorithmusversion, Richtung, Zeitpunkt, nahe Antwort, Dauer, Kontrollzweig und das an den Client gelieferte Ergebnis enthalten.

Die Schlussfolgerung bleibt begrenzt. Ein Timeout benennt keine Middlebox. FORMERR zeigt den Ort der Ablehnung nicht. Ein reproduzierbarer Unterschied zwischen Versuch und Kontrolle eröffnet eine Untersuchung; er ist noch keine belastbare öffentliche Zuschreibung.

Revision 03 warnt zudem: Nicht zufällige GREASE-Werte können Resolver-Implementierungen erkennbar machen. Der allgemeine Text verweist auf Fingerprinting durch Parameteränderungen. Ein über eine Softwareversion stabiles Muster erleichtert die Wiederholung, verrät aber ein Produkt. Vollständiger Wechsel je Anfrage erschwert die Zuordnung, kann jedoch probabilistische Fehler durch automatische Wiederholung verdecken.

Die Scharta sollte den Kompromiss festhalten: zeitlich begrenzte Epochen, Wechsel zwischen ihnen, minimierte Namen, kurze Rohdatenhaltung, eingeschränkter Zugriff und nur aggregierte Weitergabe. Das Wort anonym ersetzt keine Feldliste und keine Löschfrist.

Erfolgreicher Fallback ist keine Reparatur

Erweiterungen bei Problemen abzuschalten und erneut zu versuchen hält alte Systeme erreichbar. Es erlaubt ihnen auch, ihre Aktualisierungskosten dauerhaft auf alle Sender abzuwälzen.

Der Sicherheitsfall ist ernster. Revision 03 weist darauf hin, dass ein Angreifer einen Fallback auslösen könnte, der eine schützende Erweiterung deaktiviert. GREASE soll solche Schwächen früh zeigen, damit künftige Erweiterungen weniger auf stilles Herabstufen angewiesen sind.

Beobachten, eindämmen und Fallback entfernen bleiben drei Entscheidungen. Der messende Betreiber kontrolliert die fehlerhafte Komponente womöglich nicht. Eine sofortige Abschaffung des Fallbacks kann Wartungsschuld in öffentliche Nichtverfügbarkeit verwandeln.

Das Register sollte daher Zustände trennen: beobachtet, im Dienst abgefedert, repariert, zur Entfernung freigegeben. Jeder Übergang braucht einen Zuständigen und eigene Belege. Ein roter Messpunkt erteilt keine Kompatibilitätspolitik.

Eine Versuchscharta mit eingebautem Ende

Am Anfang stehen Rollen: Wer genehmigt echten Verkehr, wer implementiert, wer bewertet und wer kann sofort stoppen? Eine Herstellervoreinstellung ist kein Beleg für die Zustimmung jedes Betreibers.

Danach folgt der Drahtgegenstand: Erweiterungspunkt, Wertemenge oder Auswahlverfahren, zusätzliche Daten, Richtung, Softwareversion und IANA-Aufnahme. Reserviert, experimentell, privat und unzugeteilt bleiben unterschiedliche Kategorien.

Der Umfang nennt einbezogene und ausgeschlossene Klassen, Quote, absolute Gesamtrate, Zielgrenzen, Stufen und Beobachtungsfenster. Er erklärt seriellen Fallback oder parallele Kontrolle und trennt Budgets für Latenz, Fehler, Volumen, CPU, Logs und Alarme.

Der Belegteil definiert Erfolg, Fehler und offene Zuschreibung; Datensparsamkeit, Aufbewahrung, Weitergabe und Fingerprinting. Der normale Pfad muss unabhängig vom experimentellen Zweig dienen können.

Zum Schluss wird die Zeit geschlossen: Start, Standardende, ausdrückliche Verlängerung, Registerprüfung, Schalter je Test, automatische Abbruchschwellen und Rückfallverantwortung. Sichtbare Nutzerfehler, Zielüberlastung, verlorene Kontrolle, stabile Signatur oder Registerkollision führen zur Pause, nicht zur Ausweitung.

GREASE hält eine Fähigkeit am Leben, die heute keinen unmittelbaren Ertrag liefert. Gerade deshalb braucht die Technik ein sichtbares Abkommen über ihre heutigen Kosten. Ein Versuch ohne klaren Umfang, Ablauf und Abschaltbefugnis ist noch keine verantwortbare Voreinstellung.

Quellen

  1. Greasing Protocol Extension Points in the DNS — Revision 03
  2. Datatracker-Eintrag zum DNS-GREASE-Entwurf
  3. Dokumentverlauf zu DNS GREASE
  4. Aktive Dokumente von DNSOP
  5. Arbeitsauftrag von DNSOP
  6. RFC 8701 — GREASE für TLS
  7. RFC 6891 — Erweiterungsmechanismen für DNS
  8. Maintaining Protocols Using Grease and Variability — Revision 06
  9. IANA Domain Name System Parameters