APNIC Labs: DNS-Clients akzeptieren NXDOMAIN nicht als Antwort und senden 4,4 Abfragen pro Name

Wenn ein Gerät das Domain Name System (DNS) nach einem Namen fragt, der nicht existiert, sendet der autoritative Server eine negative Antwort namens NXDOMAIN (DNS-Antwortcode 3), was "keine solche Domain" bedeutet. Theoretisch sollte ein klares "Nein" ausreichen. Doch neue Messungen von APNIC Labs deuten darauf hin, dass Millionen von Clients und Resolvern sich schlicht weigern, diese Antwort beim ersten Mal zu akzeptieren, und wiederholte Abfragen senden, wodurch die Last auf den Nameservern multipliziert wird. Dieses Verhalten ist wichtig, weil es das DNS fragiler macht und erklärt, warum ein bestimmter Denial-of-Service-Angriff, bekannt als Random-Name-Angriff, so effektiv ist.

Ein Random-Name-Angriff zielt darauf ab, die autoritativen Nameserver einer Domain mit Abfragen nach zufälligen nicht existierenden Namen in dieser Zone zu überfluten. Da jede zufällige Abfrage einzigartig ist, können Caching-Resolver Antworten nicht aus dem Speicher liefern, sodass jede Abfrage den autoritativen Server erreicht. Wenn der Angriff einen konstanten existierenden Namen verwenden würde, würde der Resolver-Cache die Autorität schützen; selbst ein konstanter nicht existierender Name würde nach der ersten Antwort zwischengespeichert. Aber Zufälligkeit macht Caching völlig wirkungslos. Wenn genügend Abfragen eintreffen, wird der Server zu beschäftigt, um legitime Anfragen zu beantworten, und die Ziel-Domain kann ausfallen. Im Gegensatz zu ausgefeilteren Angriffen erfordert ein Random-Name-Angriff keine konstruierten Pakete oder privilegierte Kontrolle über Bots; ein einfaches Skript auf vielen kompromittierten Maschinen kann endlose zufällige Labels unter der Zieldomain erzeugen.

Um zu verstehen, warum dies funktioniert, führte APNIC Labs ein Experiment durch, das in Online-Werbung eingebettet war. Das Werbeskript erzeugte eine DNS-Abfrage nach einem zufälligen nicht existierenden Namen, dessen einzige autoritative Server dem Labor gehörten. Das Team beobachtete dann, wie viele Abfragen tatsächlich auf diesen Servern ankamen. Im Oktober 2019 erzeugten 60.210.983 Messungen 142.631.272 DNS-Abfragen, durchschnittlich 2,37 Abfragen pro eindeutigem Namen. Vier experimentelle Server befanden sich in Singapur, Frankfurt, Dallas und São Paulo, und die meisten Round-Trip-Zeiten lagen deutlich unter einer halben Sekunde, sodass Netzwerkverzögerungen allein die hohe Wiederholungsrate nicht erklären konnten. Zu dieser Zeit hatten 24 Prozent der getesteten Clients IPv6-Fähigkeit und HTTPS-Abfragen waren nicht in Gebrauch, sodass ideales Verhalten ungefähr 75 Millionen Abfragen erzeugt hätte, weniger als die Hälfte der beobachteten Gesamtzahl.

Schneller Vorlauf bis August 2026. Vom 5. bis 11. August verwendete dasselbe Experiment einen Pool von 115.750.503 Endpunkten, die über eine Google-Ads-Kampagne gesammelt wurden, aus allen Teilen des Internets, die Google Ads erreicht, wobei Russland die wichtigste Ausnahme darstellt. Alle DNS-Namen wurden zufällig konstruiert, um Cache-Treffer zu verhindern, und die autoritativen Server gaben NXDOMAIN zurück. Die Zone war nicht mit Domain Name System Security Extensions (DNSSEC) signiert, sodass die Antworten keine NSEC- oder NSEC3-Nachweise enthielten. Die Server unterstützten UDP und TCP, aber keine verschlüsselten DNS-Transporte wie DNS over TLS oder DNS over HTTPS. In dieser Woche sah APNIC Labs 509.410.787 Abfragen, durchschnittlich 4,40 Abfragen pro eindeutigem Domainnamen. Das ist fast doppelt so viel wie der Durchschnitt von 2019.

Der Anstieg hat mehrere Komponenten. 48 Prozent der Endpunkte fragten sowohl nach A- als auch nach AAAA-Einträgen, gegenüber 23 Prozent im Jahr 2019, während 51 Prozent nur nach A-Einträgen fragten, gegenüber 74 Prozent, und 1 Prozent nur nach AAAA. Zusätzlich erzeugten 39 Prozent der Endpunkte eine HTTPS-Eintragsabfrage. Wenn jeder Abfragetyp genau einmal gesendet würde, wäre die Gesamtzahl 218 Millionen Abfragen gewesen. Die verbleibenden 291 Millionen Abfragen, also 57 Prozent aller beobachteten Lookups, stammten von irgendeiner Form der Wiederholung. Im Durchschnitt wurde jeder wiederholte Name zusätzlich 2,5 Mal abgefragt. Aber Durchschnittswerte verbergen das Detail: 67.316.541 Endpunkte schlossen die Auflösung mit nicht mehr als einer Abfrage pro Typ ab, während 48.433.962 Endpunkte für 291.919.927 wiederholte Abfragen verantwortlich waren, eine durchschnittliche Wiederholungsrate von 6,03 unter diesen Wiederholern.

Warum wiederholen Clients und Resolver eine Abfrage, nachdem sie eine klare negative Antwort erhalten haben? Ein Teil der Erklärung liegt in der Art und Weise, wie Client-Stub-Resolver aufgebaut sind. Ein Stub-Resolver ist die kleine DNS-Bibliothek in einem Gerät, die Abfragen an einen rekursiven Resolver sendet. Da DNS normalerweise über das User Datagram Protocol (UDP) läuft, gibt es keine Garantie für die Zustellung. Wenn ein Timer abläuft, bevor eine Antwort eintrifft, sendet der Stub-Resolver die Abfrage erneut, oft an einen anderen konfigurierten Resolver. Die Client-Resolver-Bibliothek von Microsoft verwendet beispielsweise einen Ein-Sekunden-Timer für die erste Wiederholung, dann zwei Sekunden, dann vier Sekunden, und gibt nach fünf Abfragen und zehn Sekunden auf. Rekursive Resolver haben ihre eigene ähnliche Timeout-Logik und können auch autoritative Server erneut abfragen. Die allgemeine Regel ist, dass nicht reagierende Server weitere Abfragen auslösen, aber diese erneuten Abfragen sollten nicht in dem Maße multipliziert werden, dass sie eine signifikante zusätzliche Last auf dem Server verursachen. Wenn doch, kann eine einzelne Benutzerabfrage zu einem Sturm werden, und ein vorübergehendes Lastereignis kann zu einem unbeabsichtigten Denial of Service werden.

Das ursprüngliche Versprechen von NXDOMAIN ist, dass es eine abschließende, cachebare Antwort ist. Ein rekursiver Resolver kann die negative Antwort für die Dauer seiner Time to Live (TTL) zwischenspeichern und wiederholte Abfragen für denselben Namen lokal beantworten. Aber bei zufälligen Namen ist jede Abfrage neu, sodass Caching nicht hilft. Die Daten von 2026 zeigen, dass viele Systeme nach einer negativen Antwort immer noch erneut fragen, als ob sie dem Server nicht glauben. Dies wirft die Frage auf, ob NXDOMAIN der effizienteste Weg ist, im DNS "Nein" zu sagen. APNIC Labs stellt fest, dass es andere negative Antworten gibt, wie NOERROR ohne Antwortdaten, aber der Vergleich wird Teil einer separaten Studie sein.

Die Quelle geht auch auf die Probleme ein, zu fragen, ob ein Name im DNS existiert. Jede DNS-Abfrage fragt nach einem bestimmten Eintragstyp, wie A für IPv4 oder AAAA für IPv6. Der ANY-Abfragetyp wurde historisch von einigen Servern als Anfrage nach allen Einträgen behandelt, aber das schafft Reflexions- und Verstärkungsrisiken, insbesondere mit DNSSEC-signierten Zonen. RFC 8482, Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY, empfiehlt, dass Server ANY-Abfragen mit einem kompakten synthetischen Eintrag wie HINFO oder mit NS-Einträgen beantworten, anstatt die gesamte Zone auszugeben. Dies hilft, Missbrauch zu begrenzen und das DNS robuster zu machen.

Die Ergebnisse sind eine Erinnerung daran, dass das DNS auf einer Kette von Vertrauen und Wiederholungen aufbaut, die ausgenutzt werden kann, wenn ein Angreifer zufällige nicht existierende Namen erzeugt. Für normale Internetnutzer und Website-Betreiber ist die Botschaft, nicht anzunehmen, dass das DNS immer effizient funktioniert. Die Verwendung eines datenschutzorientierten verschlüsselten Resolvers wie AEU DNS kann Ihre eigenen Lookups vor lokalem Spoofing und Überwachung schützen, und sein Caching und Filtern helfen, unnötige Upstream-Abfragen zu reduzieren. Für Menschen, die Domains betreiben, ist die Wahl eines DNS-Anbieters mit Rate Limiting, Anycast-Verteilung und DDoS-Schutz unerlässlich, um eine Random-Name-Flut zu überleben.