Zusammenfassung

  • DNS Cookies ergänzt UDP-DNS um ein leichtes, serverseitig zustandsloses Signal. Ein gültiger Wert bindet einen früheren Austausch schwach an Client Cookie und Quell-IP; er identifiziert keine Person, authentisiert keine DNS-Daten und schützt nicht vor On-Path-Beobachtung.
  • RFC 9018 definiert Version 1 mit 16 Byte Server Cookie, SipHash-2-4, Zeitstempel und konfigurierbarem Secret. Im Anycast wird dessen Verteilung und Rotation selbst zur operativen Machtfläche.
  • Beweise müssen Rohbytes, Prüfgrund, Node, Epoche, BADCOOKIE, gewährte Erleichterung, Antwortgröße und Retry verbinden. „Valid“ ist kein vollständiges Protokoll.

Bekannt bedeutet nur zuvor erreichbar

Ein autoritativer Anycast-Dienst erhält massenhaft UDP-Anfragen nach einer großen signierten Antwort. Unbekannte Quellen werden begrenzt, damit gefälschte Adressen den Dienst nicht zum Verstärker machen. Ein Resolver kehrt mit Client Cookie und früher erhaltenem Server Cookie zurück. Die Prüfung gelingt, die Policy gestattet mehr Antwortbytes.

Die Anzeige „bekannter Client“ ist verführerisch. Dieselbe CGNAT-Adresse kann kurz darauf anderen Teilnehmern dienen. Ein Beobachter auf dem Pfad kann die Option kopieren. Ein Anycast-Standort kann eine alte Epoche akzeptieren, die anderswo abgelaufen ist. Der gültige Bytewert erzählt keine stabile Organisationsgeschichte.

Die korrekte Frage lautet: Konnte jemand an dieser sichtbaren Adresse vor kurzem einen Serverwert für diesen Client Cookie empfangen? Nicht: Wer ist es, ist die Anfrage harmlos oder darf sie alle übrigen Schutzregeln überwinden? Der Validator liefert ein Faktum; erst Rate- und Größenpolicy verleihen ihm Wirkung.

Zwei Cookies mit ungleichen Aufgaben

IANA weist COOKIE den EDNS-Optionscode 10 zu. Beim Erstkontakt trägt RFC 7873 nur einen acht Byte langen Client Cookie. Die Antwort ergänzt den Server Cookie; spätere Anfragen führen beide mit. Der Server kann prüfen, ohne pro Client einen Datensatz vorzuhalten.

Der Client Cookie ist kein Ausweis. RFC 9018 verlangt unterschiedliche Werte je Server-IP, empfiehlt 64 Bit Entropie, Wechsel bei neuer Client-IP und keine Lebensdauer über einen Programmneustart. Der Server liest daraus weder Konto noch Betreiber.

Der Server Cookie der Version 1 hat 16 Byte, die vollständige Option exakt 24. SipHash-2-4 verarbeitet Client Cookie, Version, Reserve, Zeitstempel und Client-IP unter einem Server Secret. So kann ein Off-Path-Angreifer einen aktuellen Wert kaum erfinden. Wer den Pfad beobachtet, kann ihn hingegen sehen und während der Gültigkeit missbrauchen.

Zustandslosigkeit spart Speicher, verlagert Verantwortung aber auf Secret, Uhr und Parser. Falsche Längentoleranz, Zeitdrift oder überbreite Schlüsselverteilung verändern die Zusicherung, obwohl überall „COOKIE enabled“ steht.

Schwache Zusicherung, kleines Privileg

Eine nur die Quelladresse fälschende Partei erhält die erste Antwort nicht. Der gültige Rücklauf kann daher eine etwas größere UDP-Antwort oder höhere kurzfristige Rate rechtfertigen. Genau dort endet die Aussage.

DNSSEC authentisiert RRsets und negative Antworten, nicht der Cookie. Transaktionsentropie bleibt für Antwortzuordnung wichtig. Verschlüsselte Transporte besitzen andere Eigenschaften. Ein kompromittierter Resolver kann gültige Cookies tragen und trotzdem schädlich handeln.

Ein Cookie darf nur Abwehr verändern, die direkt gegen Off-Path-Fälschung gerichtet ist. Er öffnet keine Rekursion, umgeht keine ACL, ersetzt keine DNSSEC-Prüfung und hebt keine globale Kapazitätsgrenze auf. Quell-IP ist zudem keine Person: NAT bündelt, Mobilität verschiebt und Adressen werden neu vergeben.

Anycast macht aus Interoperabilität Schlüsselverwahrung

Aufeinanderfolgende Anfragen an dieselbe Anycast-IP können verschiedene Nodes erreichen. Der zweite muss den Wert des ersten erkennen. RFC 9018 vereinheitlicht deshalb die Konstruktion und macht das Secret konfigurierbar.

Rotation erfolgt dreistufig. Zuerst lernen alle das neue Secret, generieren weiter mit dem alten und prüfen beide. Dann generieren sie neu und prüfen alt wie neu. Erst nach der Client-Erneuerungsfrist wird alt entfernt. Zu frühes Generieren erzeugt geografisches BADCOOKIE; zu frühes Entfernen macht echte Clients fremd; ewige Annahme vergrößert das Leckfenster.

„Konfiguration zugestellt“ beweist keine Laufzeitkonvergenz. Jeder Node braucht eine nicht geheime Epochen-ID, Zustände für learned/generating/accepting und eine Uhrmessung. Ein Secret soll nur den kleinsten interoperierenden Satz umfassen und nicht bequemerweise unabhängige Umgebungen verbinden.

BADCOOKIE ist Diagnose und Rückweg

Ungültigkeit kann Ablauf, Adress- oder Client-Cookie-Wechsel, unbekannte Epoche, Fehlformat oder Fälschung bedeuten. BADCOOKIE liefert einen neuen Wert; ein passender Client Cookie erlaubt begrenzten Retry. Eine Endlosschleife wäre selbst ein Lastproblem.

Fehler nach Standort und Population trennen. Nur ein Standort mit hoher Rate spricht für Epochendrift; mobile Quellen für Adresswechsel; illegale Längen überall für Parser-Angriffe. Zählen: Erstkontakte, gültig, abgelaufen, malformed, unbekannte Epoche, BADCOOKIE, erfolgreiche Retries, Abbrüche und TCP-Fallback.

Gemeinsame Sprache, lokale Ausführung

Heng Lus Minimum Initial Specification ist sichtbar: Codepoint, Länge, Algorithmus, Zeit und Recovery sind gemeinsam. Antwortbudget, DDoS-Policy, Schlüsselorganisation und Einführung bleiben lokal. Ein überlasteter Server darf trotz gültigem Cookie ablehnen; ein Client kann mit einem Server ohne Cookie weiterarbeiten.

IANA-Eintrag ist symbolische Koordination. Die Option ist Protokollzustand. Die Policy, die mehr Bytes erlaubt, ist ausführbare Macht. Das Paket ist Folge. Running-code primacy fordert Messung dieser Ebenen und macht nicht jede Programmentscheidung legitim.

Quellen