Zusammenfassung

  • DNS Cookies bieten bewusst begrenzten Schutz gegen Amplifikation, Fälschung und Cache Poisoning außerhalb des Pfads, indem sie eine Anfrage mit Client Cookie, Quelladresse und einer früheren Serverantwort verknüpfen.
  • Ein gültiges Server Cookie identifiziert weder eine Person noch ein dauerhaftes Gerät: NAT kann viele Clients hinter einer Adresse bündeln, ein Adresswechsel verlangt neue Cookies, und ein Beobachter auf dem Pfad kann einen gesehenen Wert während seiner Laufzeit verwenden.
  • Der Betrieb sollte Methode, Alter, Adresskontext, Anycast-Validierungsdomäne und Ergebnis eines Wiederholungsversuchs bewahren; Zugriff, Abrechnung und personenbezogene Limits bleiben an einen getrennt authentifizierten Prinzipal gebunden.

Ein Resolver-Dashboard markiert eine Anfrage als „authentifiziert“, weil ihr Server Cookie gültig war. Ein nachgelagertes System macht daraus eine Teilnehmeridentität und nimmt die Anfrage von einer Kontrolle für anonymen Verkehr aus. Die Schlussfolgerung wirkt plausibel: Der Server erzeugte den Wert, der Anfrager brachte ihn zurück und die Quelladresse stimmt. Doch eine Carrier-NAT kann Tausende Kunden hinter dieser Adresse zusammenfassen, ein gemeinsamer rekursiver Resolver kann für eine ganze Organisation sprechen, und ein Beobachter auf dem Weg kann denselben Wert während seiner Gültigkeit gesehen haben.

Damit wird das Cookie nicht nutzlos. Es beantwortet nur eine engere Frage: Legt diese Anfrage nahe, dass ein Client an dieser Quelladresse mit diesem Client Cookie früher eine Antwort dieses Servers oder eines interoperablen Anycast-Sets erhalten hat? Das ist eine Aussage über Rückweg und Transaktion. Identität ist eine andere Aussage mit einem anderen Beweis und einem anderen Verantwortlichen.

Ein gültiges Server Cookie stützt die Evidenz eines früheren Austauschs

RFC 9018, Abschnitt 1 beschreibt DNS Cookies als leichtgewichtigen Transaktionsschutz mit begrenztem Schutz vor Dienstverstärkungs-, Fälschungs- und Cache-Poisoning-Angriffen durch Angreifer außerhalb des Pfads. „Begrenzt“ ist dabei Teil der Architektur: Der Angreifer sieht den Verkehr zwischen dem behaupteten Client und dem DNS-Dienst nicht und muss deshalb einen Wert erraten, den er nie erhalten hat.

Die beiden Cookie-Felder haben verschiedene Rollen. Der Client erzeugt ein nicht vorhersagbares Client Cookie und muss für jede andere Server-IP-Adresse einen anderen Wert verwenden; RFC 9018 empfiehlt 64 Bit Entropie. Der Server gibt dieses Feld nicht als Kontoberechtigung aus. Er erhält einen vom Client gewählten Wert und gibt ihn später zurück.

Das Server Cookie ist dagegen der Rückweg-Token des Servers. RFC 9018 beschreibt es praktisch als MAC aus Client Cookie, Client-IP-Adresse, festgelegten Versions- und Zeitfeldern sowie einem Geheimnis des Servers oder von Servern an derselben Anycast-Adresse. Kommt ein gültiges Server Cookie mit einer neuen Anfrage zurück, hat der Server schwache Sicherheit, dass ein Client an dieser Adresse und mit diesem Client Cookie eine frühere Antwort mit diesem Wert erhielt. In einem interoperablen Anycast-Dienst kann ein anderes Mitglied derselben Validierungsmenge ihn ausgestellt haben.

Das Wort „schwach“ ist entscheidend. Die Evidenz hängt an Adresse und Cookie, nicht an einer natürlichen Person, einem Teilnehmer, einem Browserprofil oder einem Hardware-Vertrauensanker. RFC 7873, Abschnitt 5.2 erlaubt dem Server bei gültigem Cookie, davon auszugehen, dass er diesen Client-Kontext schon gesehen hat, und Schutzmaßnahmen gegen gefälschte UDP-Anfragen zu lockern. Daraus wird kein allgemeines Authentifizierungsprotokoll. Das Cookie beweist weder eine Berechtigung für eine geschützte Zonensicht noch ein Abrechnungskonto oder ein persönliches Limit.

Geteilte Adressen brechen die Identitätsabkürzung

NAT macht den Unterschied ohne jeden Angreifer sichtbar. Ein Haushalts-Gateway, ein Unternehmensrand, Carrier-Grade NAT oder ein gemeinsamer Resolver kann viele unabhängige Clients unter einer öffentlichen Adresse zeigen. Die Server-Cookie-Berechnung kann diese Adresse korrekt einbeziehen und trotzdem nichts darüber aussagen, welches Gerät oder welche Person dahinter eine Anwendungshandlung auslöste.

RFC 9018 benennt die Grenze in ihrer Datenschutzdiskussion. Ein Client hinter NAT kann einen Wechsel seiner öffentlichen Adresse möglicherweise nicht erkennen. Der Server kann die öffentliche Adresse des NAT-Geräts verfolgen; dies zu verhindern liegt außerhalb des RFC-Umfangs. Adressgebundene Evidenz kann an der Netzgrenze des Servers zutreffen und zugleich für Teilnehmerzuordnung zu grob sein.

Ein gültiges Cookie als Schlüssel für ein Limit pro Person zu benutzen, fasst fremde Nutzer im selben sichtbaren Kontext zusammen. Es als Abrechnungsidentität zu verwenden, weist dauerhafte Verantwortung einem Wert zu, dessen Lebenszyklus Netzanschluss und Prozesszustand folgt. Nicht das Cookie hat versagt; die Richtlinie verlangte von ihm eine Unterscheidung, für die es nie bestimmt war.

Mobilität erzeugt den umgekehrten Fehler. Um ein Gerät nicht über Links hinweg zu verfolgen und IPv6-Privacy-Adressen nicht zu unterlaufen, verlangt RFC 9018 nach einem Wechsel der Client-IP-Adresse neue Client und Server Cookies. Ein neues Cookie nach Übergabe kann daher dieselbe Person und dasselbe Gerät bedeuten. Ein stabiles Cookie ist umgekehrt keine dauerhafte Identität, sondern kann nur einen stabilen Prozess und Anschluss anzeigen.

BADCOOKIE protokolliert einen Pfad, keinen Schuldigen

Auch ein ungültiges Server Cookie ist engere Evidenz, als sein Name vermuten lässt. RFC 7873 nennt mehrere Ursachen: Der Wert kann zu alt sein, Client-Adresse oder Client Cookie können sich geändert haben, ein Anycast-Cluster kann uneinheitlich konfiguriert sein oder ein Spoofing-Versuch kann vorliegen. Der Server verarbeitet die Anfrage, als wäre das ungültige Server Cookie nicht vorhanden. Das Protokoll wählt keine dieser Ursachen für den Betreiber aus.

BADCOOKIE liefert einen Wiederherstellungspfad. Der Client wiederholt die Anfrage mit dem neuen Server Cookie aus der Antwort. Führt der frische Wert erneut zu BADCOOKIE, werden inkonsistente Geheimnisse oder Erzeugungsmethoden im Anycast-Set plausibel; RFC 7873 weist dann auf einen TCP-Wiederholungsversuch. Diese Abfolge enthält mehr Information als ein Zähler ungültiger Cookies.

Ein brauchbarer Beleg bewahrt Alter und Methode des alten Cookies, die auf beiden Seiten sichtbare Adresse, Validierungsdomäne oder Anycast-Mitglied, den neu ausgegebenen Wert, die nächste Antwort und das Ergebnis eines TCP-Fallbacks. Ein einzelnes BADCOOKIE unterscheidet normalen Ablauf, Mobilität, unvollständige Geheimnisrotation und feindlichen Verkehr nicht.

Das wird bei Geheimniswechseln praktisch. RFC 9018 verlangt eine gestufte Rotation im Anycast-Set: Mitglieder lernen und validieren das neue Geheimnis, bevor sie damit ausstellen, und behalten das vorige während des Übergangs. Wechselt ein Mitglied zu früh oder vergisst den Vorgänger, können Clients je nach Anycast-Ziel abwechselnd gültige und ungültige Ergebnisse sehen. Diese Clients als Angreifer zu etikettieren verdeckt den eigentlichen Kontrollfehler.

Cookies ergänzen die DNS-Transaktionsprüfung

DNS Cookies ersetzen die Regeln zur Antwortzuordnung nicht. RFC 5452 verlangt, dass ein Resolver Quell- und Zieladressen, Zielport, Query ID, Namen, Klasse und Typ von Antwort und ausstehender Anfrage abgleicht, bevor DNS-Vertrauensregeln greifen. Unvorhersagbare Quellports und Query IDs gehören ebenfalls dazu. Diese unabhängigen Felder vergrößern den Raum, den ein Angreifer außerhalb des Pfads erraten muss.

Die Kontrollen beantworten verwandte, aber verschiedene Fragen. Query-Matching fragt, ob eine Antwort zur versandten Transaktion passt. Ein in einer Antwort zurückgegebenes Client Cookie verknüpft diese Antwort schwach mit der angesprochenen Serveradresse. Ein gültiges Server Cookie in einer Anfrage zeigt dem Server einen früheren Rückweg zum Quellkontext. Keines davon benennt einen Nutzer oder liefert für sich Vertraulichkeit.

RFC 6891 definiert die Transaktionsoberfläche. EDNS ist eine Hop-by-Hop-Erweiterung; sein OPT-Record trägt Steuerinformationen für eine einzelne Frage-und-Antwort-Folge, enthält keine DNS-Daten und darf weder gecacht noch weitergeleitet oder in Master-Dateien abgelegt werden. Die COOKIE-Option gehört damit zur Transaktionsverarbeitung, nicht in ein dauerhaftes Benutzerverzeichnis.

Auch die Grenze gegenüber einem Beobachter auf dem Pfad bleibt klar. Wer unverschlüsselten DNS-Verkehr sehen kann, kann ein Server Cookie erfassen und während seiner Gültigkeit gegen den Client benutzen. Der serverseitige MAC hindert eine Partei ohne Geheimnis außerhalb des Pfads daran, beliebige gültige Werte zu erzeugen. Er verschlüsselt den Wert unterwegs nicht und authentifiziert nicht jeden Akteur auf dem beobachteten Weg.

Einen Beleg bauen, der die Grenze erhält

Für jede Cookie-Entscheidung sollten serverseitig sichtbare Quelladresse, clientseitig sichtbare Adresse soweit verfügbar, eine nicht umkehrbare Referenz auf das Client Cookie, Methode und Alter des Server Cookies, Validierungsergebnis, Anycast-Validierungsmenge, Wiederholungsfolge und TCP-Fallback festgehalten werden. Epochen der Geheimniserzeugung und Rollout-Zustände der Mitglieder gehören getrennt dazu, damit Infrastrukturdrift geprüft werden kann, ohne das Geheimnis preiszugeben.

Authentifiziert der Dienst zusätzlich ein Konto oder Gerät, wird dieser Prinzipal mit eigener Methode und Zeit festgehalten. Die Verbindung zwischen Identität und DNS-Transaktion muss ausdrücklich sein: welche authentifizierte Sitzung verursachte welche Resolver-Anfrage, in welchem Zeitraum und mit welcher Unsicherheit bei gemeinsamem Resolver oder NAT. Fehlt diese Verbindung, darf ein Cookie sie nicht erfinden.

Die Sprache in Dashboards und Alarmen muss die Evidenz spiegeln. „Gültiger Rückweg-Token“ ist korrekt. „Hat diesen Quellkontext zuvor erreicht“ kann mit Adresse und Zeit korrekt sein. „Bekannter Kunde“, „vertrauenswürdiges Gerät“ und „autorisierter Nutzer“ erfordern Tatsachen, die das DNS Cookie nicht enthält.

Quellen

  1. RFC 9018 — Interoperable Domain Name System (DNS) Server Cookies
  2. RFC 7873 — Domain Name System (DNS) Cookies
  3. RFC 5452 — Measures for Making DNS More Resilient against Forged Answers
  4. RFC 6891 — Extension Mechanisms for DNS (EDNS(0))