Zusammenfassung

  • DNS Response Rate Limiting (RRL) reduziert ähnliche, wiederholte Antworten eines autoritativen Servers, wenn gefälschte UDP-Anfragen ihn als Verstärker missbrauchen könnten.
  • Paul Vixies Beitrag war zentral, aber geteilt: ISC berichtet von Abwehrgesprächen mit ihm; ein BIND-Entwicklungseintrag nennt außerdem Vernon Schryver.
  • RRL gruppiert Antwortklassen und Client-Präfixe. Das ist Verkehrskontrolle, keine Authentifizierung, Zuordnung zu einem Angreifer oder Feststellung seiner Absicht.

Wenn die Antwort zur Angriffslast wird

Bei einer DNS-Reflexionsattacke sendet der Angreifer eine Anfrage an einen autoritativen Server und fälscht dabei die Absenderadresse als Adresse des Opfers. Die Antwort erreicht dann das Opfer. Ist sie deutlich größer als die Anfrage, lässt der Angreifer den Server mehr Daten senden, als er selbst verschickt hat.

Eine ISC-Präsentation aus dem Jahr 2014 veranschaulicht das mit einer 36 Byte großen ANY-Anfrage für isc.org, auf die eine 3.576 Byte große Antwort folgen konnte. Das erklärt den Reiz der Reflexion, ist aber kein allgemeingültiges Verstärkungsverhältnis. Größe und Wirkung hängen von Anfrage, Zonendaten, DNSSEC, Transport und Antwort ab. Die Betriebsfrage ist enger: Wie viele ähnliche Antworten soll ein autoritativer Server bei wiederkehrenden Anfragen weiter ausliefern?

ISC zufolge führten interne Abwehrgespräche mit Paul Vixie zu RRL. Ein BIND-Entwicklungsticket nennt Vixie und Vernon Schryver als Autoren des BIND-9-Patches. Die öffentlichen Belege stützen Vixies maßgebliche Beteiligung, nicht die Erzählung eines alleinigen Erfinders. Eine betriebliche Herausforderung wurde gemeinsam diskutiert, implementiert und später weiter abgestimmt.

Das Porträt der Internet Hall of Fame ordnet diese Episode in eine längere DNS-Laufbahn ein. Vixie begann 1988 bei Digital Equipment Corporation mit der Pflege von BIND 4 und wurde später Hauptautor und technischer Architekt von BIND 8. Außerdem gründete er MAPS, PAIX und das Internet Software Consortium; an der Keio University promovierte er über DNS und DNSSEC. Diese Stationen zeigen die Breite seiner Arbeit, ändern aber nichts an der gemeinsamen Zuschreibung des RRL-Patches, in der auch Schryver genannt wird.

BIND 9.9.4 führte RRL als optionales Build-Merkmal ein. Der ISC-Beitrag „BIND 9.10 Significant Changes“ hält fest, dass RRL später zur Standard-Build-Konfiguration gehörte. Das belegt die Verfügbarkeit in BIND, nicht die Aktivierung durch jeden Betreiber autoritativer Server und auch kein gleiches Verhalten anderer DNS-Produkte.

Der Zähler misst Ähnlichkeit, nicht Identität

Das aktuelle BIND-9.20.29-Administrationshandbuch beschreibt Token- oder Credit-Buckets, die ähnliche Antworten und DNS-Clients zusammenfassen. Jede Antwort verbraucht Guthaben, das sich im konfigurierten Zeitfenster mit der festgelegten Rate erneuert. Betreiber können Klassen wie nichtleere Antworten, NODATA, NXDOMAIN, Verweise, Fehler oder alle UDP-Antworten begrenzen. Wird der Schwellenwert überschritten, kann BIND einzelne Antworten verwerfen oder verändern.

Im Wort „Client“ steckt eine Betriebsentscheidung. Die dokumentierten BIND-Standardwerte fassen IPv4-Adressen unter /24 und IPv6-Adressen unter /56 zusammen; Adressen eines Blocks zählen gemeinsam. Hinter einem Resolver, Unternehmen, Campus oder Zugangsanbieter können viele voneinander unabhängige Nutzer liegen. Verbraucht einer das Bucket-Guthaben, kann ein anderer Nutzer desselben Präfixes eine verspätete, abgeschnittene oder gar keine Antwort erhalten.

Das macht Präfixaggregation nicht automatisch falsch. Eine Begrenzung je Einzeladresse lässt sich möglicherweise durch Verteilung der Anfragen umgehen; während einer Flut muss der Server zudem knappe Ausgangskapazität zuteilen. Präfixbreite, Antwortklasse und Rate haben jedoch Verfügbarkeitskosten. Es sind bewusste Betriebsregeln, keine neutrale Beobachtung der „wahren“ Client-Identität.

BINDs Einstellung slip zeigt den Zielkonflikt. Beim dokumentierten Standard slip=2 erhält jede zweite begrenzte Anfrage ohne gültiges Server-Cookie eine kleinere Antwort: BADCOOKIE, wenn der Client ein Cookie vorlegt, andernfalls setzt BIND das Truncation-Bit und fordert den Resolver zu einem TCP-Wiederholungsversuch auf. Einige Fehler lassen sich nicht kürzen und werden in der slip-Rate zugelassen. slip=1 sendet alle begrenzten Antworten abgeschnitten und priorisiert Integrität und Zustellung gegenüber maximaler Reflexionsunterdrückung; slip=0 verwirft sämtliche begrenzten Antworten. Der Wiederholungspfad gehört zur Abwehr, er ist kein Nebendetail.

Die Rolle des Dienstes setzt den Einsatzrahmen

ISC empfiehlt RRL für autoritative Server. Die Dokumentation warnt, dass RRL bei rekursiven Servern Fehlalarme erzeugen und Clients mit häufigen Anfragen nach denselben Namen bremsen kann; offene Rekursion sollte geschlossen werden. Derselbe Mechanismus hat bei einem öffentlichen autoritativen Dienst andere Kosten als bei einem Resolver für Endnutzer.

BIND bietet log-only, damit Betreiber mögliche Grenzwerte vor der Durchsetzung beobachten können. Zu den Zählern gehören RateDropped, QryDropped, RateSlipped und RespTruncated. Sie zeigen die Wirkung der Konfiguration, verraten aber nicht die Identität eines Angreifers. Eine beobachtete Quelladresse kann gefälscht sein; die Zugehörigkeit zu einem Bucket ist keine Zuordnung.

Heng Lus Note 65 dient hier nur als redaktionelle Perspektive: Laufzeitverhalten zeigt, was eine Implementierung tatsächlich steuert. Die Notiz ist weder ein historischer Beleg zu Vixie noch eine technische Quelle zu RRL. Entscheidend sind die laufende BIND-Version, ihre Konfiguration, Bucket-Zähler und die Wiederholungsreaktionen der Clients — nicht bloß eine Direktive in einer Dokumentation.

Die belastbare Schlussfolgerung bleibt begrenzt. RRL kann den Anteil ähnlicher Antworten verringern, den ein autoritativer Server zu Reflexionsverkehr beiträgt. Zugleich kann es legitime Nutzer zusammenfassen und zwischen Zustellung und Unterdrückung abwägen. Es authentifiziert keine Anfragen, weist keine Absicht nach, misst keine allgemeine Verbreitung und garantiert nicht, dass ein Opfer keinen reflektierten Verkehr erhält. Vixies Beitrag lässt sich am besten als Mitwirkung an einer konfigurierbaren betrieblichen Abwehr verstehen, deren Grenzen Betreiber untersuchen können.

Quellen