EDNS Client Subnet (ECS): verstehen, wie DNS Antworten an Ihren Standort anpasst

Von CaptainDNS
Veröffentlicht am 20. Oktober 2025

#DNS
#ECS
#Geolocation

Stellen Sie sich vor, Sie verschicken eine Postkarte ohne Absender. Der DNS-Server sieht in erster Linie den Resolver (8.8.8.8, 1.1.1.1 …), nicht Sie. EDNS Client Subnet (ECS) liefert gerade genug Hinweise, um zu sagen „das kommt aus diesem Viertel“ – ein IP-Präfix, nicht die vollständige IP.

Schneller Überblick für Eilige

ECS (RFC 7871): eine EDNS-Option, die ein Client-Subnetz transportiert (z. B. 203.0.113.0/24).
Ziel: dem Autoritativserver/CDN helfen, die dem Client nächstgelegene IP zurückzugeben.
Auswirkungen: geringere Latenz, dafür ein stärker fragmentierter Cache und Datenschutz, der beachtet werden muss.
Praxis: mit dig … +subnet=… testen und Antworten zwischen zwei Subnetzen vergleichen.

Das Problem, das ECS löst

Ohne ECS sieht ein Autoritativserver: „Diese Anfrage kommt von 8.8.8.8.“ Er hat keine Ahnung, wo der Endnutzer sitzt. Ergebnis: Er könnte die IP eines weit entfernten PoP (Point of Presence) liefern.

Mit ECS trägt die Anfrage einen Hinweis: „Client ≈ 203.0.113.0/24“. Der Server wählt dann die IP, die für dieses Viertel am relevantesten ist.

🎯 Weniger Netzwerk-Kilometer → geringere Latenz → bessere Erfahrung.

Probieren Sie es sofort aus (Try it #1)

Testen Sie die Subnetz-Variation (IPv4):

dig cdn.example.com @8.8.8.8 +subnet=8.8.8.0/24  +noall +answer +comments
dig cdn.example.com @8.8.8.8 +subnet=1.1.1.0/24  +noall +answer +comments

Gleiches in IPv6:

dig cdn.example.com @8.8.8.8 +subnet=2001:db8::/56 +noall +answer +comments

Wenn sich die IP ändert, berücksichtigt der Autoritativserver für diesen Namen ECS.

Wie funktioniert das?

ECS ist kein neues Protokoll; es ist eine Option innerhalb von EDNS(0). Der Resolver fügt der DNS-Anfrage hinzu:

CLIENT-SUBNET: 203.0.113.0/24

Der Autoritativserver sieht „Viertel ≈ /24“ und liefert die IP des passendsten PoP.

Was enthält die ECS-Option?

0..1  FAMILY            (1 = IPv4, 2 = IPv6)
2     SOURCE PREFIX     (z. B. 24 für /24)
3     SCOPE  PREFIX     (z. B. 24, 20 …)
4..n  ADDRESS           (auf das Präfix gekürzt)

SOURCE: Genauigkeit, die der Resolver sendet (oft /24 in v4, /56 in v6).
SCOPE: wie weit die Antwort im Cache weiterverwendet werden darf.
ADDRESS: auf das Präfix gekürzt (keine vollständige IP offengelegt).

Ablaufdiagramm (SVG)

Ablaufdiagramm (Das Diagramm ist unten auch inline eingebettet, falls Ihr Renderer keine externen SVG lädt.)

ASCII (Fallback)

[Client] -> [Resolver 8.8.8.8] ==(ECS: 203.0.113.0/24)==> [Autoritativserver] -> [CDN-PoP in der Nähe]

Serverseite: Entscheidungen und Scope

Beim Empfang einer Anfrage mit ECS:

das Präfix lesen (SOURCE),
den nächstgelegenen PoP/Ressource auswählen,
die Antwort zurückgeben, ggf. mit einem SCOPE (Hinweis zur Cache-Nutzung).

🪧 Denken Sie an SCOPE wie an ein Schild „gilt für das ganze Viertel“.

Cache und Komplexität: warum manche zögern

Ohne ECS → ein Eintrag pro Name. Mit ECS → ein Eintrag pro Name und pro Subnetz.

Folgen:

Cache wächst (z. B. Varianten pro /24),
Richtlinie festlegen (maximale Präfixe, erlaubte Domains, sinnvolle TTLs),
manche Resolver kürzen oder deaktivieren ECS, um Cache-Fußabdruck und Privatsphäre zu kontrollieren.

💡 Pragmatische Faustregel: /24 (IPv4) und /56 (IPv6). Mehr Präzision = wenig Gewinn, mehr Risiko.

Datenschutz: nützliche Unschärfe, kein Tracking

ECS legt nicht die komplette IP offen, sondern nur ein Präfix. Es bleibt trotzdem eine geografische Information – gut für Performance, sensibel in manchen Kontexten.

Bewährte Praktiken:

nur kurze Präfixe senden (vermeiden Sie /32, /128),
dokumentieren, wann und für wen ECS gilt,
auf Autoritativseite einen angemessenen SCOPE setzen, um Fragmentierung zu begrenzen.

Testlabor (Try it #2 und #3)

🧪 Try it #2 – die ECS-Option sichtbar machen

dig google.com @8.8.8.8 +subnet=203.0.113.0/24 +noall +answer +comments

In der OPT PSEUDOSECTION nach einer Zeile wie folgt suchen:

CLIENT-SUBNET: 203.0.113.0/24/0

Wenn sie nicht erscheint, ignoriert oder entfernt der Resolver ECS.

🧪 Try it #3 – Subnetz wechseln und vergleichen

# Zwei /24-Präfixe, gleicher Resolver
dig cdn.example.com @8.8.8.8 +subnet=8.8.8.0/24 +short
dig cdn.example.com @8.8.8.8 +subnet=1.1.1.0/24 +short

Bonus: DoT/DoH mit kdig testen (TLS hilft, wenn UDP TC/Truncation setzt):

kdig +tls @1.1.1.1 example.com +subnet=203.0.113.0/24

(Resolver verhalten sich je nach Richtlinie unterschiedlich; Dokumentation prüfen.)

Häufige Stolperfallen & Anti-Patterns

Cache, der täuscht: zufällige Labels (a1234.cdn.example.com) verwenden, um einen MISS zu erzwingen.
DNSSEC-Verwechslung: EDNS (und damit ECS) ist nicht signiert; den DO-Bit nicht mit der ECS-Option verwechseln.
UDP-Truncation (TC): erneut über TCP oder TLS versuchen (kdig +tls).
Übertriebene Präzision: /32 und /128 vermeiden – Rauschen, Risiko, fragmentierter Cache, wenig Nutzen.
Vorschnelle Messungen: mehrere /24 und /56 vergleichen, bevor man einen CDN als „falsch konfiguriert“ einstuft.

FAQ

Macht mich ECS individuell nachverfolgbar?
Nein. ECS zeigt ein Präfix, nicht die exakte IP. Es bleibt jedoch Standortinformation.

Warum ändert sich trotz ECS nichts auf meinem Autoritativserver?
Weil er keine Geo-Logik implementiert oder die sichtbaren PoPs für die getesteten Subnetze identisch sind.

Verhalten sich öffentliche Resolver alle gleich?
Nein. Manche fügen ECS hinzu (häufig mit gekürztem Präfix), andere entfernen es aus Datenschutzgründen. Dokumentation prüfen – Richtlinien können sich ändern.

Nützliche Referenzen

RFC 7871 – Client Subnet in DNS Queries
RFC 6891 – Extension Mechanisms for DNS (EDNS(0))