Zusammenfassung

  • DNS-Cookies halten einen leichtgewichtigen Transaktionszustand vor, der bestimmte Off-Path-Angriffe durch Verstärkung, Fälschung und Cache-Poisoning erschwert.
  • Ein gültiges Server Cookie gibt dem Server nur begrenzte Gewissheit: Die Anfrage kam von der beobachteten Adresse und brachte ein zuvor gesehenes Client Cookie zurück.
  • Der Mechanismus widersteht keinem On-Path-Beobachter und identifiziert weder Nutzer, Anschlussinhaber, Gerätebesitzer noch einen authentifizierten Dienst hinter Resolver oder NAT.
  • Der Betrieb braucht deshalb ein Prüfprotokoll für DNS-Anfragen, das Cookie-Prüfung, Netzbeobachtung, Resolver-Identität und Autorisierung getrennt hält.

Man stelle sich ein hypothetisches Missbrauchskontrollsystem vor. Haushalt, Büro oder Zugangsnetz senden DNS über einen gemeinsamen rekursiven Resolver. Er erreicht einen Anycast-Dienst, erhält ein Server Cookie und präsentiert später von derselben öffentlichen Adresse einen gültigen Wert. Ein nachgelagertes System wertet dies als Beweis, dass derselbe Kunde beide Anfragen stellte. Das Protokoll belegt weniger: Die zweite Anfrage trägt Zustand, den der Server anhand von Client Cookie, beobachteter Adresse, Geheimnis und Zeitfenster prüfen kann.

RFC 7873 definiert DNS-Cookies als leichten Mechanismus für DNS-Transaktionssicherheit. Sie bieten begrenzten Schutz gegen Verstärkung, Antwortfälschung und Cache-Poisoning durch Angreifer, die den Austausch nicht beobachten können. Diese Off-Path-Bedingung ist die Grenze der Aussage.

Die erste Anfrage enthält ein acht Byte langes Client Cookie. Nach der Antwort können spätere Anfragen Client Cookie und empfangenes Server Cookie gemeinsam senden. Der Server kann Verkehr ablehnen oder begrenzen, der seinen ausgegebenen Zustand nicht reproduziert. Der Mechanismus lässt sich schrittweise einführen, verträgt NAT und Anycast und verlangt keine vorab eingerichteten Zugangsdaten für jeden Internetclient.

Darum spricht der RFC von schwacher Authentifizierung, nicht von einem Identitätssystem. Router, Bridge, Teilnehmer eines gemeinsamen Links oder andere On-Path-Beobachter können unverschlüsseltes DNS und damit das Cookie sehen. Während seiner Nutzungsdauer können sie den beobachteten Wert wiederverwenden. Das Cookie erhöht die Kosten für Off-Path-Fälscher; es verwandelt einen sichtbaren Bearer-Wert nicht in den Nachweis einer Person oder Organisation.

RFC 9018 standardisiert eine interoperable Server-Cookie-Konstruktion. Version 1 kombiniert Client Cookie, Versions- und reservierte Felder, Zeitstempel und Client-IP unter einem Server Secret. Die IP fließt in die Berechnung ein, obwohl sie nicht im Cookie-Wert steht. Der Server prüft das Ergebnis mit demselben Geheimnis.

Die Konstruktion beantwortet eine genaue Frage: Passt die Anfrage zu einem Cookie, das zuvor für dieses Client Cookie und diese beobachtete Adresse unter einem gültigen Geheimnis und Zeitfenster erstellt wurde? Sie sagt nicht, wer die Adresse nutzt. Viele Menschen können einen Resolver teilen. Mehrere Geräte können hinter einer NAT-Adresse erscheinen. Der Prozess kann neu starten, sein Client Cookie wechseln oder die Adresse ändern. Umgekehrt kann eine Adresse stabil bleiben, während Menschen und Rechte dahinter wechseln.

Zeit gehört zum Nachweis. RFC 9018 verlangt die Prüfung des Zeitstempels in einem definierten Zeitraum und empfiehlt ungefähr eine Stunde in der Vergangenheit und fünf Minuten in der Zukunft. Ist ein empfangenes Cookie älter als eine halbe Stunde, sollte der Server einen neuen Wert ausgeben. Dieses Fenster begrenzt Replay, ist aber keine aktuelle Autorisierungsperiode eines Kontos.

Anycast verlangt eine weitere Trennung. Mitglieder brauchen eine kompatible Konstruktion und die Server Secrets, um Ausgaben der anderen zu prüfen. RFC 9018 beschreibt drei Stufen: das neue Secret überall verteilen, zunächst weiter mit dem alten erzeugen; dann mit dem neuen erzeugen und beide prüfen; schließlich nach einer Erneuerungsfrist das alte entfernen. Akzeptiert ein anderes Mitglied das Cookie, zeigt dies nur, dass die Prüfung auf den Anycast-Knoten konsistent ist — nicht, dass derselbe physische Server, dieselbe Resolver-Instanz oder derselbe Nutzer zurückgekehrt ist.

Datenschutzregeln unterstreichen die Grenze. Ändert sich die Quelladresse, muss der Client ein neues Client Cookie erzeugen; hinter NAT erkennt er eine Änderung der öffentlichen Adresse womöglich nicht. Kontinuität ist bewusst an Netzkontext und Implementierungszustand gebunden. Ein dauerhafter Kundenbezeichner widerspräche den Mobilitäts- und Datenschutzannahmen.

Der stärkere Vergleich ist RFC 8945 zu TSIG. TSIG authentifiziert DNS-Transaktionen mit einem Nachrichtenauthentifizierungscode zwischen Entitäten, die bereits ein konfiguriertes Geheimnis teilen. Eine dynamische Aktualisierung oder Antwort kann so einer genehmigten Partei mit Schlüssel zugeordnet werden. Dafür sind Schlüsselverteilung, Schutz und eine benannte Vertrauensbeziehung nötig, die DNS-Cookies absichtlich vermeiden.

Selbst TSIG hat eine Grenze: Es authentifiziert die Übertragung zwischen Parteien mit gemeinsamem Geheimnis, nicht Wahrheit oder ursprüngliche Herkunft jedes DNS-Datums. DNS-Cookies erben diese stärkere Partei-Authentifizierung nicht, nur weil beide Verfahren Schlüsselberechnungen verwenden. Das eine ist ein leichtgewichtiger Schutz vor Fälschungen, das andere Transaktionsauthentifizierung in einer vorab eingerichteten Vertrauensbeziehung.

Der betriebliche Fehler besteht darin, vier Beobachtungen zu einem Identitätssignal zusammenzufassen. Das Server Cookie kann gültig sein und die Adresse zur Berechnung passen, während der Pfad beobachtbar bleibt und der Resolver viele Nutzer mit verschiedenen Rechten vertritt. Rate-Limiting darf das Cookie als Missbrauchssignal nutzen, ohne zu behaupten, einen Kunden authentifiziert zu haben.

Ein brauchbares Prüfprotokoll für DNS-Anfragen würde Client Cookie, Version und Zeitstempel des Server Cookies, Prüfergebnis, beobachtete Quelladresse, antwortendes Anycast-Mitglied, Generation des Server Secrets, Transport und On-Path-Exposition, bekannte Resolver-Instanz, separat authentifizierten Nutzer oder Dienst, Autorisierungsrichtlinie und Aktionszeit festhalten. Das Geheimnis selbst darf nie gespeichert werden.

So bleibt der Wert erhalten. Gültige Cookies unterstützen Rate-Limiting, reduzieren Reflexion und filtern offensichtliche Fälschungen vor teureren Kontrollen. Sie decken auch Fehler beim Secret-Wechsel und in der Anycast-Konsistenz auf. Der Nutzen entsteht durch einen nachvollziehbaren Nachweis, nicht durch eine Ausweitung über das Bedrohungsmodell hinaus.

Quellen

RFC 7873 — Domain Name System (DNS) Cookies; RFC 9018 — Interoperable DNS Server Cookies; RFC 8945 — Secret Key Transaction Authentication for DNS.