Zusammenfassung

  • Die ECS-Option enthält feste Rollen für Quellpräfix und Antwortbereich: Der Resolver begrenzt die übermittelten Clientnetz-Bits, die Autorität begrenzt die Cache-Reichweite.
  • Die Adresse wird auf die signifikanten IPv4- oder IPv6-Bits gekürzt; weder sie noch der zurückgegebene Bereich beweisen Identität, Einwilligung oder genaue Geografie.
  • RFC 7871 dokumentierte Datenschutz- und Cachekosten und empfahl ECS standardmäßig abzuschalten; RFC 8932 empfahl Datenschutzdiensten Vermeidung, Minimierung und Offenlegung.

Ein Vertrag aus Feldern

FAMILY bezeichnet IPv4 oder IPv6. SOURCE PREFIX-LENGTH bestimmt, wie viele führende Adressbits im Query aussagekräftig sind. SCOPE PREFIX-LENGTH ist im Query null und erhält erst in der Antwort Bedeutung. ADDRESS enthält nur die für das Quellpräfix nötigen Bits und wird bis zum letzten erforderlichen Oktett aufgefüllt, nicht zwingend bis zur vollständigen Adresse.

Diese Aufteilung macht Verantwortungen sichtbar. Ein rekursiver Resolver besitzt eine konfigurierte maximale, cachefähige Präfixlänge und sollte weniger als die volle Adresse senden. Kommt bereits ein kürzer begrenztes ECS-Präfix an, darf ein nachgeschalteter Forwarder nicht mehr Clientbits offenlegen. Die Quelllänge ist damit eine Obergrenze, die entlang der Kette erhalten bleiben soll.

Der autoritative Server spiegelt die Quelllänge in seiner Antwort und setzt einen Bereich. Dessen führende Bits beschreiben das Netz, für das die Antwort wiederverwendet werden kann. Ein kürzerer Bereich umfasst mehr Adressen; ein längerer kann anzeigen, dass das gelieferte Quellpräfix für die beabsichtigte Auswahl nicht spezifisch genug war.

Warum ein Resolver überhaupt Clientkontext sendet

Ein autoritativer Server sieht normalerweise die Quelladresse des rekursiven Resolvers. Sie kann als topologischer Hinweis genügen, wenn Resolver und Client nahe beieinander liegen. Ein zentraler Dienst kann jedoch Nutzer aus weit entfernten Netzen bündeln; dann führt eine Anpassung an den Resolver nicht notwendig zu einer passenden Antwort für den dahinterstehenden Client.

RFC 7871 dokumentierte ECS als optionalen EDNS0-Mechanismus, mit dem ein Zwischenserver Teile des Ursprungsnetzes weitergeben kann. Der Resolver ersetzt seine eigene Adresse als einzigen Hinweis durch ein gekürztes Clientpräfix. Die Autorität kann darauf reagieren, doch das Query an sie stammt vom Vermittler. Nutzen und Offenlegungsentscheidung liegen nicht bei derselben Partei.

Das Präfix ist kein Identitätsnachweis. Topologische und geografische Nähe hängen nur locker zusammen. Der RFC legt außerdem nicht fest, wie eine Autorität ihre angepasste Antwort auswählt. ECS garantiert weder den nächsten noch den schnellsten oder besten Server.

Der Bereich wird Cachepolitik

Ein ECS-fähiger Cache sucht zunächst wie üblich nach Name, Typ und Klasse. Danach wählt er den passenden RRset über Präfixabgleich. Antworten werden an das in der Response beschriebene Netz gebunden; Quelllänge, Bereichslänge und lokales Maximum bestimmen die Wiederverwendung.

Fehlt ECS in der Antwort, gilt diese normalerweise als Bereich /0 und damit für alle Clientadressen. Antwortet die Autorität mit REFUSED, versucht ein ECS-fähiger Resolver das Query ohne ECS erneut. So kann er eine Ablehnung der Option von anderen Bedeutungen desselben Codes unterscheiden.

Die zusätzliche Dimension fragmentiert den Cache. Für denselben Namen, Typ und dieselbe Klasse können mehrere Netzvarianten entstehen. RFC 7871 warnt vor höherem Speicherverbrauch, geringerem Wiederverwendungsgrad und zusätzlicher Serverlast. ECS sollte deshalb standardmäßig deaktiviert bleiben, nur bei klarem Clientnutzen eingeschaltet und durch Obergrenzen für Netze und Antworten kontrolliert werden.

Auch die empfohlenen Antwortprüfungen haben eine enge Grenze. Nicht übereinstimmende Query-Identitätsfelder sollen zur Verwerfung führen und dadurch einige Spoofing- und Cache-Pollution-Pfade begrenzen. Eine Übereinstimmung authentifiziert aber weder das Clientpräfix noch die Auswahlpolitik der Autorität.

Null als Widerspruch

Ein Stub kann SOURCE PREFIX-LENGTH auf null setzen. Der rekursive Resolver darf dann keine Clientadressinformation in nachfolgende Queries einsetzen. Er kann ECS weglassen oder eigene Adressinformation verwenden. Forwarder müssen die ankommende Einschränkung erhalten.

RFC 7871 hielt 2016 zugleich fest, dass diese Präferenz praktisch nur dort erreichbar war, wo Software die Option offenlegte. Das ist eine historische Beobachtung, keine Bestandsaufnahme heutiger Anwendungen, Anbieter oder öffentlicher Resolver. Die hier festgelegten Quellen enthalten keine aktuellen Nutzungszahlen.

RFC 8932 betrachtete ECS 2020 aus Sicht von DNS-Datenschutzdiensten. Verschlüsselung schützt die Strecke vom Client zum Resolver vor bestimmten Beobachtern, hindert den Resolver aber nicht an späterer Datenweitergabe. Der BCP empfiehlt, /0 zu respektieren, ECS upstream zu vermeiden oder einen Dienst ohne ECS anzubieten. Bei Nutzung soll das kürzeste betrieblich mögliche Präfix gesendet, der Empfängerkreis möglichst begrenzt und die wirkliche Länge samt Richtlinie veröffentlicht werden.

DNSSEC ist kein Siegel für die Delegation

DNSSEC und ECS-Bereich behandeln unterschiedliche Fragen. RFC 7871 empfiehlt /0 für die meisten DNSSEC-Daten; eine RRSIG bleibt an den signierten RRset gebunden. Validierung signiert weder die Offenlegungsentscheidung des Resolvers noch Geografie oder die Auswahlmethode der Autorität.

Die historische Aussage bleibt daher eng: ECS formalisierte einen Vermittlungsvertrag über offengelegten Netzkontext und Cache-Reichweite. Das ist eine redaktionelle Folgerung aus den protokollierten Mechanismen, keine Messung heutiger Verbreitung oder Leistung.

Quellen