Zusammenfassung

  • APNIC Labs beobachtete bei 116.050.253 Tests ohne Antwort insgesamt 9.685.775.212 Abfragen am autoritativen Server. Aus den veröffentlichten Summen folgen 83,46 Abfragen je eindeutigem Test, gegenüber 3,43 für die positive Kontrolle, 3,93 für NODATA, 4,40 für NXDOMAIN, 11,47 für REFUSED und 51,73 für SERVFAIL.
  • Die Verhältnisse belegen im Versuch einen Zusammenhang zwischen Antwortzustand und Abfragelast. Sie identifizieren nicht, ob die Wiederholungen von einem Endgerät, dessen Stub-Resolver, einem Forwarder, einer rekursiven Engine, einer Resolver-Farm oder mehreren gemeinsam handelnden Schichten stammen.
  • Bei zwei Durchschnittswerten widerspricht der Fließtext der Übersichtstabelle. Eine Neuberechnung aus den publizierten Zählern erklärt die Tabellenwerte, nicht aber die Absicht des Autors. Für eine betriebliche Verwendung braucht es deshalb einen Messbeleg, der Nenner, Formel, Topologie, Transport, Sicherheitszustand und die unbekannte Zuordnung bewahrt.

Der Zähler kann exakt und der Handelnde trotzdem unbekannt sein

Die größte Zahl im Bericht von APNIC Labs vom 4. September lautet 9.685.775.212. So viele Abfragen sah der autoritative Server, wenn der Versuch keine Antwort lieferte. Als Nenner nennt die Übersichtstabelle 116.050.253 Tests. Die Division ergibt 83,4619 Abfragen je eindeutigem Test.

Die Rechnung ist einfach. Der Weg, der sie erzeugt hat, ist es nicht.

Ein Skript in einer Onlineanzeige brachte ein Endgerät dazu, einen zufällig gebildeten Namen aufzulösen. Die Resolver-Bibliothek des Endgeräts konnte einen von mehreren eingestellten rekursiven Diensten fragen. Dazwischen konnte ein Forwarder liegen. Ein großer Dienst konnte die Anfrage auf Frontends und Resolver-Engines verteilen. Eine Engine konnte eine weitere Adresse oder einen weiteren Transport ausprobieren. Jede dieser Komponenten kann Arbeit erzeugen, gleiche Anfragen zusammenführen, etwas erneut senden oder die Frage weiterreichen.

Im autoritativen Protokoll von APNIC erscheinen die Abfragen, die die letzte gemessene Grenze erreichen. Es enthält keine signierte Verwahrungskette, die jede Entscheidung stromaufwärts einem Akteur zuordnet.

Wer daraus „83 Abfragen eines Resolvers“ macht, ergänzt eine nicht gemessene Tatsache. Selbst „83 Wiederholungen“ ist zu ungenau. Ein modernes Endgerät kann für denselben Namen nach A, AAAA und HTTPS fragen. Das sind verschiedene Abfragetypen, keine drei Wiederholungen desselben Pakets. APNIC zieht eine erwartete Grundlast ab, bevor zusätzliche Abfragen als Wiederholungen diskutiert werden. Die veröffentlichte Einheit bleibt aber ein eindeutiger Testname, nicht eine Handlung eines Menschen, eine Anwendungsanforderung, eine Stub-Transaktion oder eine rekursive Transaktion.

Diese Grenze schwächt den Befund nicht, sondern verortet ihn. APNIC hat gemessen, was unter sechs Antwortbedingungen an einem autoritativen Dienst ankam. Das ist ein wertvolles Lastbuch. Es ist noch kein Buch darüber, wer jede einzelne Abfrage beschlossen hat.

Sechs Antwortzustände erzeugten sechs sehr verschiedene Lasten

Der Versuch von 2026 nutzte zufällige Namen, damit kein zwischengespeicherter Datensatz für genau diesen Namen antworten konnte. Die Zone war unsigniert. Ein einzelner Dual-Stack-Nameserver nahm UDP und TCP an, jedoch weder DoT noch DoH. Die Antworten waren kurz und erforderten keine Trunkierung. Gezählt wurden Abfragen, die innerhalb von 24 Stunden nach der jeweiligen Anzeigenplatzierung ankamen.

Aus den veröffentlichten Summen ergibt sich folgender Vergleich:

Autoritativer Zustand Tests Beobachtete Abfragen Neu berechnete Abfragen je Test Vielfaches der positiven Kontrolle
Positive A/AAAA-Kontrolle 254.894.985 875.316.423 3,43 1,00×
NOERROR/NODATA 115.571.398 454.213.932 3,93 1,14×
NXDOMAIN 115.750.503 509.410.787 4,40 1,28×
REFUSED 115.415.259 1.324.355.211 11,47 3,34×
SERVFAIL 138.643.924 7.171.673.166 51,73 15,06×
Keine Antwort 116.050.253 9.685.775.212 83,46 24,30×

Das Muster ist aussagekräftiger als ein Vergleich von „Ja“ und „Nein“. Positive Antworten und die beiden definitiven negativen Formen bleiben nahe vier Abfragen je Test. REFUSED liegt deutlich höher. SERVFAIL und Schweigen erreichen eine andere Größenordnung.

Diese Reihenfolge passt zur Bedeutung. NXDOMAIN sagt, dass der Name nicht existiert. NODATA sagt, dass der Name existiert, aber der angefragte Typ nicht. REFUSED sagt, dass der Server die Operation ablehnt, häufig aus Richtliniengründen. SERVFAIL sagt, dass ein Problem die Bearbeitung verhindert hat, und lässt offen, ob ein anderer Server, eine andere Adresse, ein anderer Transport oder ein späterer Versuch erfolgreich wäre. Schweigen sagt gar nichts; erst Zeitgeber entscheiden, was die fehlende Antwort bedeutet.

Plausibilität ist keine Identifikation. Die Tabelle zeigt nicht, welche Implementierung einen RCODE gelesen, welches Frontend erneut gesendet, wie viele gleiche Anforderungen zusammengeführt oder ob nach einem Fehler Serveradressen gewechselt wurden. Sie zeigt auch keine Verteilung nach Produkt und keinen langen Rand, den jeder Mittelwert verdeckt. Der Versuch belegt eine Beziehung zwischen Antwortzustand und Last. Er belegt keine universelle SERVFAIL-Regel mit 51,73 Abfragen.

Schon die erwartete Grundlast ist größer als eins

Für NXDOMAIN berichtet APNIC, dass 48 Prozent der Endgeräte sowohl A als auch AAAA erzeugten, 51 Prozent nur A und ein Prozent nur AAAA. Bei 39 Prozent wurden außerdem HTTPS-Abfragen gesehen. Aus diesem Mix schätzte APNIC 218 Millionen Abfragen, wenn jeder verwendete Typ genau einmal angefordert worden wäre.

Beobachtet wurden 509.410.787. Die übrigen 291.919.927 wurden als Wiederholungen eingestuft. Von 115.750.503 Tests endeten 67.316.541 mit höchstens einer Abfrage je verwendetem Typ. Die anderen 48.433.962 Tests trugen die gesamte Wiederholungslast; das entspricht 6,03 wiederholten Abfragen je Test mit Wiederholung.

Die Arbeit am Nenner ist wesentlich. Wer 509 Millionen Pakete mit ungefähr 116 Millionen Tests vergleicht und die Differenz pauschal „Retries“ nennt, erklärt legitime parallele Typen zu Fehlern. Wer dagegen nur festhält, ob überhaupt eine Antwort eintraf, lässt fast 292 Millionen zusätzliche Abfragen verschwinden. Ein brauchbarer Datensatz muss sowohl die erwartete Typenmenge als auch den darüber hinausgehenden Verkehr enthalten.

Hinzu kommt die Reichweite der Stichprobe. Die Endgeräte kamen über Google Ads aus von diesem System bedienten Regionen; Russland nennt der Bericht als wesentliche Ausnahme. Das ist breite Sichtbarkeit, aber keine Zufallsstichprobe aller Internetnutzer und Resolver. Ein einzelner Dual-Stack-Nameserver ist ein kontrolliertes Instrument, keine gewöhnliche autoritative Flotte mit mehreren Anbietern. Die unsignierte Zone und kurzen Antworten entfernen DNSSEC-Validierung und Trunkierung aus diesem Versuch. Sie beweisen nicht, dass diese Faktoren anderswo bedeutungslos sind.

Auch der Bericht braucht einen Beleg für seine Arithmetik

Die Quelle veröffentlicht genügend Rohzahlen, um ihre Mittelwerte zu prüfen. Dabei treten zwei Abweichungen hervor.

Im SERVFAIL-Abschnitt nennt der Fließtext 51,29 als durchschnittliche Abfragen je Test und 51,59 als Wiederholungsdurchschnitt. Aus den Summen folgen diese Werte nicht. 7.171.673.166 geteilt durch 138.643.924 ergibt 51,7273, in der Übersicht auf 51,73 gerundet. Zieht man 3.702.576 Tests mit einer einzigen Abfrage ab, bleiben 134.941.348 Tests mit Wiederholungen. 6.920.490.780 Wiederholungen geteilt durch diesen Nenner ergeben 51,2852 und damit die 51,29 aus der Tabelle.

Im Abschnitt ohne Antwort steht die Testzahl als 11,6050,253; der Text nennt 82,6 Abfragen je Test. Tabelle 1 führt 116.050.253 Tests und 83,46 auf. Mit diesem Nenner ergibt die Division von 9.685.775.212 genau 83,4619. Auch der Wiederholungsdurchschnitt 83,38 lässt sich reproduzieren: 9.466.474.491 Wiederholungen geteilt durch 113.531.062 Tests mit Wiederholung.

Die angemessene Reaktion besteht weder im ungeprüften Abschreiben der Absätze noch in der Behauptung, die Abweichung widerlege den gesamten Versuch. Rohsummen, Tabelle und Formeln sollten gemeinsam veröffentlicht werden. Dann kann der Leser einen Übertragungs- oder Beschriftungsfehler von einem Messfehler trennen. Nur der Autor der Quelle kann sagen, welcher Fließtextwert beabsichtigt war; die Arithmetik zeigt, welche Werte aus den publizierten Zählern folgen.

Das ist die These im Kleinen. Eine sauber gesetzte Zahl beglaubigt sich nicht selbst. Nenner, Ausschlüsse und Herleitung gehören zum Befund.

Frühere Messungen liefern Hypothesen, nicht die fehlende Identität

APNIC untersuchte 2019 wiederholten NXDOMAIN-Verkehr genauer. Die Studie fand zeitliche Spitzen, Wiederholungen von derselben sichtbaren Resolver-Adresse und Schübe aus Adressgruppen mit gemeinsamer Präfixzugehörigkeit. Diskutiert wurden Happy Eyeballs, Paketverlust, aggressive Zeitgeber, die Konzentration durch Forwarder und Resolver-Farmen. Die Gruppierung über gemeinsame /24- oder /48-Präfixe wurde ausdrücklich als Näherung beschrieben.

Damit werden mehrere Mechanismen plausibel. Die Aggregation von 2026 erhält dadurch keine nachträglich gesicherte Ursache. Eine sichtbare Quelladresse kann mehrere Engines vertreten. Mehrere Adressen können zu einer Farm gehören. Ein Stub kann an zwei Dienste senden, die in demselben rekursiven System zusammenlaufen. Eine weitere Abfrage kann bereits stromaufwärts warten, während die erste noch aktiv ist. Netzverlust kann Frage oder Antwort beseitigen.

Der aktuelle Bericht benennt die Lücke offen: Gehört die Wiederholung zur Implementierung rekursiver Resolver oder zu komplexeren Frontend- und Backend-Systemen? Diese Unbekannte muss in jeder Wiedergabe sichtbar bleiben. Wer sie entfernt, verwandelt eine Forschungsfrage in ein Urteil über eine Implementierung.

Die veröffentlichte Zeitsteuerung des Microsoft-DNS-Clients ist aus demselben Grund nützlich und unzureichend. Sie zeigt einen konkreten Ablauf: Schweigen kann einen Windows-Client zu weiteren Abfragen und zur Ausweitung auf andere konfigurierte Server bringen, während ein Name Error diesen Zweig beendet. APNIC hat die beobachteten Clients aber weder als Windows-Systeme identifiziert noch diesen Ablauf für sie nachgewiesen. Eine Implementationsbeschreibung erklärt einen möglichen Pfad; sie füllt kein unbeobachtetes Feld in einem anderen Experiment aus.

Standards begrenzen Wiederholungen, lösen aber die Zuordnung nicht

RFC 9520 gibt rekursiven Resolvern eine klare Pflicht zur Eindämmung. Für eine Abfrage an eine Serveradresse über einen Transport darf nach der ersten Übertragung höchstens zweimal wiederholt werden. Ausgeschöpfte Auflösungsfehler müssen mindestens eine Sekunde und höchstens fünf Minuten zwischengespeichert werden. Passende eingehende Anforderungen dürfen währenddessen keine neue ausgehende Arbeit erzeugen.

Diese Regeln richten sich gegen eine reale Gefahr von Fehlerstürmen. Sie erlauben einem autoritativen Beobachter trotzdem nicht, jedes eintreffende Paket genau einer RFC-Entscheidung zuzuordnen. Ein Resolver kann eine andere Serveradresse oder einen kompatiblen Transport versuchen. Mehrere Clients können eine rekursive Transaktion speisen; eine Clienthandlung kann sich über mehrere Systeme auffächern. Eine Implementierung kann an einem Tupel regelkonform bleiben und über eine größere Pfadmenge dennoch viele Abfragen beitragen.

RFC 2308 versieht NXDOMAIN und NODATA mit zwischenspeicherbarer negativer Bedeutung und erlaubt in seinem älteren Modell eine begrenzte Zwischenspeicherung von Serverfehlern. RFC 8914 ergänzt diagnostische Angaben über Extended DNS Errors, ohne die RCODE-Verarbeitung zu verändern. Diese Mechanismen machen Zustände verständlicher. Sie erlauben keine falsche negative Antwort, nur weil diese weniger Verkehr erzeugt, und identifizieren keinen Wiederholungsakteur, der nicht gesondert instrumentiert wurde.

Hier liegt die betriebliche Grenze. Antwortsemantik beeinflusst die folgende Arbeit. Wahrheitsgemäße Semantik darf nicht zum Instrument der Verkehrsformung umgedeutet werden. Wer Zeitgeber, Serverauswahl, Zusammenführung oder Fehlerspeicher ändert, muss die lokale Wirkung mit lokalen Daten belegen.

Ein Messbeleg muss den Pfad zeigen, den das Verhältnis verbirgt

Ein schichtensensibler Messbeleg kann knapp bleiben. Er nennt Versuchsfenster, Auslösekanal, Reichweitenausschlüsse und die genaue Analyseeinheit. Bevor zusätzlicher Verkehr als Wiederholung gilt, bewahrt er die abgefragte Typenmenge und die erwartete Grundlast.

Danach dokumentiert er den Aufbau der Antwort auf dem Draht, Serverzahl, Adressfamilien, Anycast-Zustand, unterstützte und beobachtete Transporte, DNSSEC-Zustand, Antwortgröße und Trunkierung. Rohsummen, Wiederholungssummen, Formeln, Rundung und Verteilungen gehören neben den auffälligen Mittelwert.

Vor allem darf der Beleg keine Antwort in ein unbeobachtetes Feld zwingen. Wurden Stub-, Forwarder- und rekursive Schicht nicht getrennt instrumentiert, bleiben ihre Beiträge unbekannt. Wo Datenschutz und Betriebsgrenzen es erlauben, kann ein kontrollierter Versuch Transaktionskennungen an jeder eigenen Stufe ergänzen, das Zusammenführen gleicher Anfragen erfassen und Wiederholungen am selben Adresse-Transport-Tupel von Versuchen über Alternativen trennen. Wo diese Verwahrungskette nicht möglich ist, endet der Bericht an der autoritativen Grenze.

APNIC hat den schwierigen ersten Schritt bereits geleistet: Der Kostenunterschied lässt sich nicht mehr wegreden. Der nächste Schritt ist kein stärkeres Wort für „Sturm“, sondern eine Messung, die sagen kann, welche Schicht welche Wiederholungsbefugnis ausgeübt hat.

Quellen