Zusammenfassung
- Der vorgeschlagene ECS-Opt-in meldet in der Antwort eine wirksame Präfixgrenze, auch wenn die Antwort aus dem Cache kommt und für diese Anfrage keine neue Adressinformation übertragen wurde.
- Eine Richtlinienobergrenze, die Herkunft eines Cache-Eintrags und die tatsächlich an autoritative Server gesendeten Bits sind unterschiedliche Belege und brauchen getrennte Verantwortliche.
Die Antwort enthält den Wert 24. Das Überwachungssystem schreibt: 24 Adressbits verwendet. Tatsächlich kam die Antwort aus dem Cache. Für diese Anfrage ging keine neue ECS-Abfrage an einen autoritativen Server, und die Zahl beschrieb lediglich die Grenze, die gegolten hätte.
Der Fehler liegt nicht in der Zahl. Er liegt in der Bedeutung, die das System ihr zuweist.
Revision 00 von Client Opt-In Signaling for EDNS Client Subnet definiert den Rückgabewert derzeit als wirksame Präfixlänge, unabhängig davon, ob die Antwort aus dem Cache stammt. Zugleich hält der Entwurf als offene Frage fest, ob stattdessen die tatsächlich verwendeten Bits gemeldet werden sollten. Diese scheinbar kleine Feldfrage entscheidet darüber, ob eine Quittung eine Regel oder ein Ereignis beschreibt.
Der Text ist ein individueller Internet-Draft vom 20. August 2026, kein angenommenes DNSOP-Arbeitsgruppendokument und kein RFC. Der vorgesehene Status lautet Experimental, der Optionscode ist TBD. Daraus folgt weder Implementierung noch Einsatz. Die offene Semantik ist gerade ein Grund, das Verfahren nicht als fertige Messnorm zu behandeln.
Das bisherige ECS-Modell
RFC 7871 erlaubt einem rekursiven Resolver, einen Präfix der Netzwerkadresse des Clients an autoritative DNS-Server zu senden. Diese können ihre Antworten auf das Netz zuschneiden. Der Resolver entscheidet üblicherweise durch seine Konfiguration, ob er ECS für Clients ohne eigene ECS-Option verwendet.
Ein Client kann sich mit SOURCE PREFIX-LENGTH 0 abmelden. Einen kürzeren positiven Präfix kann er im bestehenden Format nur verlangen, wenn er auch die Adresse liefert, aus der diese Bits stammen. Hinter NAT, Carrier-Grade NAT oder einem VPN kennt der Client die öffentlich sichtbare Adresse möglicherweise nicht.
Die neue Option trennt Erlaubnis und Adressangabe. Mit einem Byte setzt der Client die höchste Zahl von Bits, die der Resolver weitergeben darf. Ohne eine verwendbare mitgelieferte Adresse nimmt der Resolver die Quelladresse, die er beobachtet. Die wirksame Grenze ist das Minimum aus Clientgrenze, einer vorhandenen ECS-Grenze, der lokalen maximal cachebaren Präfixlänge und 32 beziehungsweise 128 Bits für IPv4 oder IPv6.
Eine Option ohne Daten erteilt die Erlaubnis, setzt aber keine Clientobergrenze. Dann gilt die lokale Grenze des Resolvers. Wer nichts freigeben will, soll die Option weglassen. Ein ausdrücklicher Wert 0 führt ebenfalls zu keiner Weitergabe, verrät auf unverschlüsseltem Transport aber die Unterstützung des Verfahrens.
Normale Auflösung beweist keine Annahme
Ein Resolver, der die neue EDNS-Option nicht kennt, ignoriert sie und antwortet wie zuvor. Deshalb darf ein Client das Eintreffen einer Antwort nicht als Beleg dafür behandeln, dass sein Limit eingehalten wurde. Der kompatible Ausfallmodus erhält DNS-Funktion, verschleiert aber die fehlende Kontrollfähigkeit.
Ein implementierender Resolver sendet die Option mit der wirksamen Länge zurück. Fehlt sie, kann das fehlende Unterstützung oder Entfernung auf dem Weg bedeuten. Der alte Resolver könnte dennoch ECS aus eigenem Antrieb einsetzen. „Option nicht zurück“ ist daher keine sichere Aussage „keine Offenlegung“.
Die zurückgesendete Zahl ist außerdem eine Erklärung des Resolvers über sein eigenes Verhalten. OPT-Datensätze werden nicht durch DNSSEC signiert. Eine DNSSEC-validierte Namensantwort authentisiert nicht die Behauptung, wie viele Adressbits der Resolver weitergegeben hat.
Verschlüsselter DNS-Transport schützt die Strecke zwischen Client und Resolver. Er kann verhindern, dass ein Angreifer die Option hinzufügt, das Limit erhöht oder den Rückgabewert verändert. Er beweist nicht, dass der Resolver intern korrekt handelt. Ein kompromittierter Resolver kann mehr senden und weniger melden. Für einen Ergebnisnachweis braucht es Beobachtung auf der autoritativen Seite.
Der Wert auf einem Cache-Treffer
Bei einer frischen autoritativen Auflösung kann die wirksame Obergrenze eng mit dem möglichen Upstream-Verhalten verknüpft sein. Bei einem Cache-Treffer fällt diese Verbindung auseinander. Der Resolver kann 24 zurückmelden, weil 24 das aktuelle Maximum wäre, obwohl keine neue Adresse den Resolver verlassen hat.
Der Cache-Eintrag selbst kann mit ECS erworben worden sein. Dann trägt er eine andere Geschichte: welcher Quellpräfix galt beim Erwerb, welcher Scope zurückkam und für welche Clients der Eintrag zulässig ist. Die aktuelle Richtliniengrenze überschreibt diese Herkunft nicht.
Der Entwurf verlangt, dass ein Resolver für jeden Cache-Eintrag weiß, ob er mit ECS erworben wurde. Eine solche Antwort darf nicht an einen nicht signalisierenden Client gehen. Andernfalls erhält jemand, der nie zugestimmt hat, eine für ein Netz zugeschnittene Antwort. Im ausgelieferten DNS-Paket gibt es kein Feld, das diese Anpassung kennzeichnet.
Getrennte Caches für signalisierende und nicht signalisierende Clients sind eine mögliche Umsetzung. Herkunftsmetadaten mit Zulässigkeitsregeln sind eine andere. Entscheidend ist, dass die Kontrollentscheidung aus dem gespeicherten Zustand erklärbar bleibt.
Für signalisierende Clients gelten die Longest-Prefix-Regeln von RFC 7871 weiter. Ein Eintrag mit längerer SOURCE PREFIX-LENGTH als der aktuellen wirksamen Grenze darf unter Umständen antworten, weil die Cache-Nutzung keine neuen Adressbits weiterleitet. Genau deshalb sind Offenlegungsgrenze und Wiederverwendungsberechtigung zwei Achsen.
Zustimmung bleibt am direkten Empfänger
Die vorgeschlagene Option ist nicht transitiv. Der Resolver darf sie weder an autoritative Server schicken noch aus einer Client-Anfrage in eine beliebige Upstream-Anfrage kopieren. EDNS wird hopweise ausgehandelt; die Anweisung richtet sich an den rekursiven Resolver, der die Clientwahl direkt erhielt.
Ein Forwarding Resolver ist gegenüber seinem Upstream selbst Client. Er darf eine eigene Opt-in-Option senden, jedoch niemals ein höheres Limit als das empfangene setzen. Baut er ECS selbst, berichtet er die Zahl der weitergeleiteten Original-Client-Bits. Überlässt er die Adressauswahl dem Upstream, sieht dieser die Adresse des Forwarders, und für die Adresse des ursprünglichen Clients muss der Forwarder 0 melden.
Eine gewöhnliche ECS-Option beweist keine Endnutzerzustimmung. Ein Forwarder kann sie hinzufügen. Die getrennte Opt-in-Option soll gerade zeigen, dass der direkte Client eine Wahl übermittelt hat. Sie ist eine lokale Weisung, kein übertragbarer Berechtigungsnachweis.
Die Antwortzahl bleibt eine Eigenaussage
Die Beweiskette sollte daher mindestens vier Objekte behalten. Erstens die vom Client gesendete Form: abwesend, ohne Daten, ausdrücklich 0 oder positive Grenze. Zweitens Identität und Schutz des Transportwegs. Drittens die Berechnung und Erklärung des Resolvers. Viertens die tatsächlich auf autoritativer Seite beobachtete ECS-Information.
Diese Objekte können miteinander verglichen werden, dürfen aber nicht zusammenfallen. Die Clientanfrage beweist Absicht, nicht Ausführung. Die verschlüsselte Sitzung beweist Transport, nicht Ehrlichkeit. Die Antwort beweist eine Erklärung, nicht deren Wahrheit. Autoritative Beobachtung beweist einen Empfang an diesem Punkt, nicht automatisch die gesamte weitere Nutzung.
Auch ein kurzer Präfix ist nicht anonym. Er kann jeden autoritativen Server erreichen, an den der Resolver ECS sendet, und Beobachter auf ungeschützten Upstream-Strecken. Kürze verringert Genauigkeit; sie löscht den Netzbezug nicht.
Ein Registereintrag wäre kein Messergebnis
Der Optionscode ist noch offen. Der Entwurf beantragt eine Zuteilung per Expert Review aus dem normalen EDNS0-Register statt eines willkürlichen experimentellen Werts. Eine spätere Zuteilung würde interoperable Implementierungen ermöglichen und Kollisionen vermeiden.
Sie würde weder Cache-Herkunft noch ehrliche Berichte garantieren. Ebenso wenig beweist die Bezeichnung Experimental, dass Versuchsziel, Erfolgskriterium und Auswertung bereits feststehen. Der Entwurf nennt diese Punkte selbst als offene Arbeit.
Für Führungskräfte folgt daraus eine einfache Messdisziplin. Eine Obergrenze ist eine Regel. Die verwendeten Bits sind ein Ereignis. Die Cache-Herkunft ist Zustand. Die Zustimmung ist eine Eingabe. Wer alle vier als einen Zahlenwert speichert, gewinnt kein einfaches Kontrollsystem, sondern verliert die Möglichkeit, einen Vorfall zu erklären.
Quellen
- https://www.ietf.org/archive/id/draft-farrokhi-dnsop-ecs-opt-in-00.txt
- https://www.ietf.org/archive/id/draft-farrokhi-dnsop-ecs-opt-in-00.html
- https://www.ietf.org/archive/id/draft-farrokhi-dnsop-ecs-opt-in-00.xml
- https://datatracker.ietf.org/doc/draft-farrokhi-dnsop-ecs-opt-in/
- https://datatracker.ietf.org/doc/draft-farrokhi-dnsop-ecs-opt-in/history/
- https://datatracker.ietf.org/doc/draft-farrokhi-dnsop-ecs-opt-in/references/
- https://datatracker.ietf.org/api/v1/doc/document/draft-farrokhi-dnsop-ecs-opt-in/
- https://www.rfc-editor.org/rfc/rfc7871.txt
- https://www.rfc-editor.org/rfc/rfc6891.txt
- https://www.rfc-editor.org/rfc/rfc9499.txt
- https://www.rfc-editor.org/rfc/rfc7858.txt
- https://www.rfc-editor.org/rfc/rfc8484.txt
- https://www.rfc-editor.org/rfc/rfc9250.txt
- https://www.rfc-editor.org/rfc/rfc8126.txt
- https://www.rfc-editor.org/rfc/rfc7942.txt
- https://www.rfc-editor.org/rfc/rfc6890.txt
- https://www.rfc-editor.org/rfc/rfc9660.txt
- https://www.ietf.org/archive/id/draft-bellis-dnsop-edns-tags-01.txt
- https://www.rfc-editor.org/rfc/rfc7873.txt
- https://www.rfc-editor.org/rfc/rfc7828.txt
- https://www.rfc-editor.org/rfc/rfc7314.txt
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
