Zusammenfassung

  • APNICs Tabelle 1 weist für SERVFAIL 51,73 beim autoritativen Dienst empfangene Anfragen je Test aus, für keine Antwort 83,46. NXDOMAIN lag bei 4,40, NOERROR/NODATA bei 3,93 und die Positivkontrolle bei 3,43.
  • Beobachtet wurde am autoritativen Ende. Stub, Forwarder, rekursive Front- und Backends, alternative Server, Transporte und Verluste wurden nicht lückenlos instrumentiert. Der Autor verschiebt die Ursachenfrage ausdrücklich auf eine Folgestudie.
  • RFC 9520 verlangt das Zwischenspeichern von Auflösungsfehlern und begrenzt Wiederholungen zum selben Ziel über denselben Transport. Andere Pfade bleiben offen. Betreiber brauchen Budgets pro Schicht und eine verknüpfbare Beweiskette.

Aus einer vernünftigen Wiederholung wird eine unvernünftige Summe

Der Stub im Endgerät setzt einen Timer. Ein lokaler Forwarder kann einen zweiten setzen. Ein großer rekursiver Dienst verteilt die Frage womöglich auf mehrere Engines. Jede Engine kennt mehrere autoritative Adressen und kann den Transport wechseln. Keine einzelne Schleife muss aggressiv konfiguriert sein, damit die Komposition aggressiv wirkt.

Genau diese Komposition macht der APNIC-Blogbeitrag von Geoff Huston vom 4. September sichtbar. APNIC Labs ließ ein Skript in Onlineanzeigen zufällige Namen unter experimentellen Zonen auflösen und zählte die beim eigenen autoritativen Dienst eingehenden Anfragen.

Die Endtabelle zeigt sechs Profile. Eine positive Antwort erzeugte durchschnittlich 3,43 Anfragen pro Test. NOERROR/NODATA, also kein Datensatz des gefragten Typs, kam auf 3,93. NXDOMAIN, der nicht vorhandene Name, auf 4,40. Die politische Ablehnung REFUSED stieg auf 11,47. SERVFAIL, das gegenwärtige Unvermögen zu antworten, erreichte 51,73. Ohne Antwort waren es 83,46.

Ein Statuscode ist damit nicht nur Beschreibung, sondern Anreiz. Eine definitive Negation kann wiederverwendet werden. Ein vermutlich vorübergehender Fehler lässt einen anderen Server oder Pfad sinnvoll erscheinen. Schweigen liefert überhaupt keine DNS-Aussage; nur der Ablauf eines Timers beendet den Versuch.

Die Tabelle löst einen Zahlendreher, nicht die Zurechnung

Quelle und Tabelle widersprechen sich an zwei Stellen. Im SERVFAIL-Absatz steht 51,29 als mittlere Anfragezahl; Tabelle 1 nennt 51,73 und führt 51,29 als mittlere Wiederholungszahl. Im Absatz ohne Antwort steht 11,6050,253 Tests und 82,6; die Tabelle nennt 116.050.253 und 83,46. Dieser Bericht verwendet die zusammenfassende Tabelle und legt den Konflikt offen.

Für SERVFAIL wurden 138.643.924 Tests und 7.171.673.166 Anfragen erfasst, darunter 6.920.490.780 Wiederholungen. Nur 3.702.576 Tests kamen mit je einer Anfrage pro verwendeten Typ aus. Beim Schweigen registrierte die Tabelle 9.685.775.212 Anfragen; 9.466.474.491 davon galten als Wiederholungen.

Das belegt eine Lastverteilung unter den Testbedingungen. Es belegt nicht, wer jede Anfrage auslöste. Ein autoritatives Protokoll sieht meist das rekursive System als Absender. Es sieht nicht zwingend den Browser-Stub, den lokalen Forwarder, die Übergabe vom Frontend zur Engine, einen verlorenen Antwortdatensatz oder ein zweites gleichartiges Clientereignis.

Huston fragt selbst, ob rekursive Implementierungen oder komplexe DNS-Systeme mit getrennten Front- und Backends verantwortlich sind, und kündigt weitere Untersuchung an. 51,73 ist daher keine Naturkonstante von SERVFAIL, kein Urteil über ein bestimmtes Produkt und keine Hochrechnungsbasis für das weltweite DNS.

Vier Anfragen bedeuten noch nicht vier Wiederholungen

Die NXDOMAIN-Phase lief vom 5. bis 11. August 2026 mit 115.750.503 über Google Ads gewonnenen Endpunkten. Der Beitrag spricht von breiter geografischer und technischer Vielfalt und nennt Russland als wichtigste Ausnahme.

48 Prozent fragten A und AAAA, 51 Prozent nur A, ein Prozent nur AAAA; 39 Prozent erzeugten zusätzlich eine HTTPS-Frage. Je eine Frage pro beobachtetem Typ hätte rund 218 Millionen ergeben. APNIC erhielt 509.410.787. Die Differenz von 291.919.927 wurde als Wiederholung gezählt. 57 Prozent blieben bei höchstens einer Frage je Typ; in der wiederholenden Gruppe lag der Durchschnitt bei 6,03.

Die Zufallsnamen verhinderten einen zuvor gespeicherten exakten Treffer. Die Zone war nicht DNSSEC-signiert, daher konnte ein validierender Resolver die negative Synthese aus NSEC/NSEC3-Beweisen nach RFC 8198 nicht nutzen. Der autoritative Dienst unterstützte UDP und TCP, nicht DoT oder DoH. Antworten waren kurz und ungekürzt; gezählt wurde 24 Stunden nach der Anzeige.

Diese Grenzen sagen nichts Endgültiges über den Transport vom Client zum Rekursivdienst. Auch der etwas niedrigere Wert von NOERROR/NODATA gegenüber NXDOMAIN erlaubt keinen semantischen Tausch. RFC 2308 regelt den Negativcache; RFC 8020 lässt ein NXDOMAIN Anfragen unterhalb des fehlenden Namens abschneiden. Korrektheit steht vor Verkehrsoptimierung.

RFC 9520 zieht eine konkrete, keine allumfassende Grenze

RFC 9520 macht das Caching von Auflösungsfehlern wie SERVFAIL, unerreichbaren Servern und DNSSEC-Validierungsfehlern verpflichtend. Empfohlen werden zunächst eine Sekunde bis höchstens fünf Minuten, ein konfigurierbares Minimum und Backoff. Nach dem ersten Versuch soll derselbe Server unter derselben Adresse und über denselben Transport höchstens zweimal erneut gefragt werden.

Die Norm erinnert an frühere Verstärkung: mehr als zehnfaches Normalvolumen in einer Dyn-Retry-Storm, 80-fache DNSKEY-Last beim Root-KSK-Rollover, einen Versuch mit rund 50 auf 60.000 Anfragen pro Sekunde unter SERVFAIL und den Anstieg bei .COM/.NET von 7.000 auf 900.000 pro Sekunde während des Facebook-Ausfalls.

Andere Server, Adressen und Transporte bleiben jedoch zulässig. Auch clientnahe Schleifen fallen nicht in dieselbe Zählung. Gleichartige offene Fragen zusammenzuführen ist deshalb ebenso wichtig wie die Höchstzahl in einer einzelnen Schleife.

Ein Extended DNS Error nach RFC 8914 kann den Grund eines SERVFAIL erläutern. Er ist diagnostisch und darf die DNS-Verarbeitung nicht verändern. Mehr Kontext verbessert die Fehlersuche, macht aus einem Fehler aber keine definitive Nichtexistenz.

APNIC als Publikationsort ist keine APNIC-Position

Der Beitrag trägt Geoff Hustons Namen und den Hinweis, dass die Ansichten der Autoren nicht zwingend APNICs Ansichten sind. APNIC stellt den Publikationsort und APNIC Labs das Messsystem. Daraus wird keine Registry-Politik.

Die Evidenz rechtfertigt Reproduktion, Verteilungsanalyse und eine Prüfung der RFC-9520-Implementierung. Sie rechtfertigt weder ein Compliance-Urteil über einen benannten Betreiber noch semantisch falsche Antworten zur Lastsenkung.