Zusammenfassung

  • DNS Cookies machen aus einem ersten Hin- und Rückweg einen begrenzten Erreichbarkeitsnachweis. Eine spätere Anfrage mit dem richtigen Tokenpaar ist von außerhalb des Pfades schwerer zu fälschen.
  • RFC 7873 definierte den Austausch; RFC 9018 standardisierte einen interoperablen Version-1-Server-Cookie, damit unterschiedliche Implementierungen in einem Anycast-Verbund denselben Zustand prüfen können.
  • Der Mechanismus stiftet weder Identität noch Vertraulichkeit. Ein Beobachter auf dem Pfad sieht die Tokens, NAT bündelt viele Clients, und weitere Maßnahmen gegen Missbrauch bleiben notwendig.

Die erste Anfrage bringt kein Konto, kein Zertifikat und keinen ausgehandelten Schlüssel mit. Sie trifft als UDP-Datagramm ein, dessen Quelladresse wahr oder gefälscht sein kann. Der Client setzt einen acht Byte langen Client Cookie in die EDNS-COOKIE-Option. Unterstützt der Server das Verfahren, sendet er diesen Wert zusammen mit einem eigenen Server Cookie zurück. Bei der nächsten Anfrage legt der Client beide vor.

Das zweite Paket trägt eine knappe Vorgeschichte. Der Server Cookie hängt vom Client Cookie, von der sichtbaren Clientadresse und von einem Servergeheimnis ab. Ein Angreifer außerhalb des Pfades kann die Adresse eines Opfers in den IP-Header schreiben, sollte aber die dorthin geschickte Antwort nicht gesehen haben. Ihm fehlt der passende Token. Der Server gewinnt nur den Hinweis, dass er mit dieser Kombination aus Adresse und Cookie bereits Daten ausgetauscht hat. Der Client kann umgekehrt eine Antwort verwerfen, die nicht seinen erwarteten Client Cookie zurückliefert.

Das ist keine Identität. Ein Heimrouter, ein Carrier-Grade-NAT oder eine Unternehmensgrenze kann viele Geräte unter einer öffentlichen Adresse zusammenfassen. Ein kompromittiertes System an der richtigen Adresse bleibt gefährlich. Wer den Pfad beobachten kann, sieht den Cookie im Klartext und kann ihn innerhalb der Gültigkeit wiederverwenden. DNS Cookies verschlüsseln die Frage nicht, weisen keine Organisation aus und ersetzen DNSSEC nicht. Sie belegen lediglich, dass ein Rückweg zuvor funktioniert hat.

Dieser schmale Befund war wichtig, weil UDP-DNS Quellfälschung in Verstärkung verwandeln konnte. Eine kurze Frage konnte eine größere Antwort an das Opfer auslösen. Eine gefälschte Anfrage konnte außerdem Rekursion und DNSSEC-Prüfungen erzwingen. In Gegenrichtung konnten erfundene Antworten mit der legitimen Antwort um den Cache konkurrieren. DNSSEC authentifiziert Daten; TSIG bietet stärkeren Transaktionsschutz mit Schlüsselverwaltung; zufällige Ports und IDs erschweren blindes Raten; Response Rate Limiting begrenzt den Ausgang. Cookies ergänzten diese Maßnahmen um leichtgewichtige Rückwegevidenz ohne serverseitige Clientdatenbank.

RFC 7873 vom Mai 2016 wies der COOKIE-Option den EDNS-Code 10 zu. Kennt der Client keinen Server Cookie, sendet er nur acht Byte. Danach enthält die Option zusätzlich einen Serverwert, ursprünglich mit acht bis zweiunddreißig Byte. Die konkrete Berechnung blieb jeder Implementierung überlassen. Der Server konnte den Token aus Quelle, Client Cookie und Geheimnis neu berechnen, statt eine Sitzung zu speichern.

Der Zustandsautomat unterstützt schrittweise Einführung. Ein Server ohne Funktion ignoriert die Option. Ein unterstützender Server darf auf einen einzelnen Client Cookie je nach Richtlinie mit Verwerfen, BADCOOKIE oder einer normalen Antwort reagieren; antwortet er, liefert er den Server Cookie für den nächsten Zustand. Eine unzulässige Länge führt zu FORMERR. Ein alter oder ungültiger Wert wird wie ein fehlender behandelt. Ein gültiger Wert kann Schutzmaßnahmen lockern, die ausschließlich gegen gefälschte UDP-Quellen gerichtet sind, nicht alle Missbrauchskontrollen.

BADCOOKIE ist deshalb ein Übergang. Stimmt der zurückgegebene Client Cookie, übernimmt der Client den neuen Serverwert und versucht es erneut. Scheitert dieser frische Wert sofort, kann er auf TCP ausweichen. Wiederholungen können auch eine interne Störung anzeigen: Knoten derselben Anycast-Adresse verwenden unterschiedliche Geheimnisse, Verfahren oder Rollout-Phasen.

NAT erklärt die Bindung an beide Werte. Wäre der Server Cookie nur an die öffentliche Adresse gebunden, könnte ein Gerät einen Token für alle anderen hinter demselben Gateway beschaffen. Der Client Cookie trennt die Flüsse, ohne persönliche Zustände auf dem Server anzulegen. Die Trennung bleibt netztechnisch und identifiziert keinen Menschen.

Anycast legte eine schwierigere Lücke offen. Zwei aufeinanderfolgende Anfragen an dieselbe Adresse können verschiedene Maschinen und DNS-Produkte erreichen. RFC 7873 empfahl ein gemeinsames Server Secret, vereinheitlichte aber die Berechnung nicht. Zwei Produkte konnten trotz identischen Geheimnisses inkompatible Tokens erzeugen. Eine normale Routenänderung sah dann wie ein ungültiger Cookie aus.

RFC 9018 vom April 2021 definierte dafür den 16 Byte langen Version-1-Server-Cookie: ein Byte Version, drei reservierte Byte, vier Byte Zeitstempel und acht Byte SipHash-2-4. Zusammen mit dem Client Cookie ist die vollständige Option exakt 24 Byte lang. Die Berechnung umfasst Client Cookie, Strukturfelder, Client-IP und Server Secret. Die Adresse wirkt in der Prüfung mit, wird aber nicht in den Token kopiert.

Der Zeitstempel begrenzt Wiederholung. Die Empfehlung akzeptiert Werte aus der vergangenen Stunde, toleriert fünf Minuten in der Zukunft für Uhrabweichungen und erneuert einen Cookie, der älter als eine halbe Stunde ist. Das sind Standardempfehlungen, keine Aussage über jede Installation. Sie zeigen, dass der Nachweis verfallen soll und ein Beobachter auf dem Pfad auch sein Nutzungsfenster erkennt.

Geheimniswechsel wurden zu einem dreistufigen Flottenvorgang. Zuerst wird das neue Geheimnis überall verteilt, während weiter mit dem alten ausgestellt und mit beiden geprüft wird. Danach stellen die Knoten mit dem neuen aus, akzeptieren das alte aber noch. Erst nach der Überlappung wird der alte Wert entfernt. Einheitliche Uhren, Verteilung und Phasen gehören damit ebenso zum Kontrollsystem wie die Hashfunktion.

RFC 9018 änderte auch die Client-Cookie-Empfehlung: 64 Bit Entropie getrennt je Server-IP und keine Wiederverwendung, sobald sich die Client-IP ändert. So soll ein stabiler Bezeichner das Gerät nicht über Netze hinweg verfolgen. Ein Host hinter NAT erkennt einen Wechsel der öffentlichen Gateway-Adresse möglicherweise nicht; dieser Rest bleibt außerhalb des Verfahrens.

Die Geschichte der DNS Cookies ist daher nicht die Einführung von Identität in DNS. Sie zeigt, wie Evidenz auf die Aussage begrenzt wird, die sie tragen kann. Der erste Rundweg beweist keine Absicht. Er erzeugt einen Token, der die Lüge einer Quelle ohne empfangene Antwort verteuert. RFC 7873 entwarf diesen Tausch; RFC 9018 machte ihn in heterogenen Anycast-Flotten praktikabel. Die wirklichen Kontrollpunkte bleiben Client- und Serverrichtlinien, Zeit und koordinierte Geheimnisverwaltung.

Quellen