Zusammenfassung

  • Der Lauf mit einem Nameserver umfasste 254.894.985 Tests und im Mittel 3,43 autoritative Abfragen je Test; der spätere Lauf mit zwei Nameservern umfasste 150.221.951 Tests und kam auf 2,57.
  • Der Anteil der Tests mit genau einer Abfrage stieg von 58 auf 71 Prozent. Da die Läufe getrennt und mit ungleichen Populationen stattfanden, belegen die Summen nicht, dass der zusätzliche Nameserver den Unterschied verursacht hat.
  • Nötig ist ein Reproduktionsbeleg: randomisierte Varianten im selben Zeitfenster, vergleichbare Resolver- und Netzkohorten, eine eingefrorene autoritative Topologie, die offengelegte Normalisierung und Zeitverteilungen für konkurrierende Erklärungen.

Ein großer Messunterschied ohne fertigen Mechanismus

APNIC Labs stellte eine praktische Frage: Ändert ein Angebot von zwei autoritativen Nameservern die Zahl der Abfragen rekursiver Resolver? Im ersten Datensatz mit einem Server erzeugten 254.894.985 Tests insgesamt 875.316.423 autoritative Abfragen, im Mittel 3,43. Bei 147.233.117 Tests, laut Bericht 58 Prozent, blieb es bei einer Abfrage.

Der spätere Datensatz mit zwei Servern enthielt 150.221.951 Tests und 385.725.364 Abfragen, also 2,57 je Test. 106.376.529 Tests beziehungsweise 71 Prozent erzeugten nur eine Abfrage. Wo es Wiederholungen gab, sank auch deren berichteter Mittelwert von 3,80 auf 2,56.

Die Größenordnung macht die Beobachtung relevant: Der zweite Lauf hatte weniger Abfragen je Test und mehr Einzelfälle. Sie macht aus der Konfiguration aber noch keine Ursache. Der Autor nennt das Ergebnis selbst unerwartet und schreibt, dass er keine definitive Erklärung liefern könne.

Ungleiche Größen sind nicht das eigentliche Problem

Rund 255 Millionen Tests mit 150 Millionen zu vergleichen ist nicht grundsätzlich unzulässig. Große Beobachtungsdatensätze werden über Raten und Normalisierungen verglichen; APNIC normalisierte die beiden Reihen vor der Betrachtung ihrer Zeitprofile. Entscheidend ist, ob die Messbedingungen hinreichend vergleichbar waren.

Der vorangehende Versuch beschreibt eindeutige Zufallsnamen, die über Google-Werbemesspunkte ausgelöst wurden, eine unsignierte Zone, kurze ungekürzte Antworten, UDP- und TCP-Dienst sowie ein Beobachtungsfenster von 24 Stunden. Er zeigt zudem geografische Unterschiede, wobei Russland deutlich herausfiel. Für die Ein-Server-Konfiguration stand in sechs Großräumen jeweils ein Dual-Stack-Nameserver: Nordamerika, Südamerika, Europa und Afrika, Indien, Asien und China.

Eine kausale Auswertung benötigt weitere Konstanten. Liefen beide Varianten an denselben Tagen und Stunden? Blieb die Mischung aus Ländern, Zugangsnetzen, Resolver-Adressen und IP-Familien stabil? Waren Standort, Routing, Anycast oder Unicast, TTL, Antwortcode, Paketgröße und Beobachtungsfrist identisch? Eine Normalisierung gleicht Nenner an. Sie gleicht keine nicht ausgewiesene Änderung der Population oder des Netzpfads aus.

Darum lautet der Befund nicht, dass ungleiche Stichprobengrößen den Versuch wertlos machten. Vielmehr fehlt der Beleg, der Behandlung und Kontrolle verbindet. Ein kleinerer zweiter Lauf kann bei transparenter Zuteilung überzeugen; auch Hunderte Millionen Beobachtungen lassen Kausalität offen, wenn gleichzeitig Uhr oder Population wechseln.

Die Zeitkurven liefern den besseren Hinweis

Die Verteilungen enthalten mehr Information als die Mittelwerte. Mit einem Server trafen mehr als 85 Prozent der Duplikate in der ersten Sekunde ein, mit zwei Servern waren es 75 Prozent. In beiden Reihen kamen etwa 90 Prozent innerhalb von fünf Sekunden. Die Zwei-Server-Kurve zeigte außerdem Spitzen bei ungefähr 0,75, 1,5 und 3 Sekunden.

Am schnellen Ende lagen 17 Prozent der Wiederholungen aus dem Ein-Server-Lauf unter 10 Millisekunden, im Zwei-Server-Lauf 12 Prozent. Nach der Normalisierung konzentrierte sich der größte Unterschied auf 10 bis 70 Millisekunden, besonders 10 bis 40. Das ist kürzer als ein typisches UDP-Zeitlimit eines rekursiven Resolvers und passt daher nicht ohne Weiteres zu einer einfachen Folge aus Warten, Fehlschlag und Wiederholung.

Der Autor nennt eine Resolver-Farm als Möglichkeit. Ein DNS-bewusster Verteiler kann Anfragen auf mehrere rekursive Backends aufteilen; mehrere Backends könnten denselben Namen verfolgen. PowerDNS beschreibt dnsdist als DNS-Loadbalancer vor rekursiven Servern. Das belegt die Existenz einer solchen Architektur, nicht ihren Einsatz oder ihre Wirkung in APNICs Stichprobe. Ohne interne Spuren kann eine sichtbare Quelladresse Frontend-Fan-out, Backend-Rennen, IPv4/IPv6-Auswahl, Cache-Zustand oder implementierungsspezifische Auswahl verbergen.

Resolver wählen autoritative Server ohnehin nicht nach einem einheitlichen Verfahren. APNICs Bericht von DNS-OARC 43 beschreibt unterschiedliche Startwerte, Latenzlernen und IPv6-Präferenzen bei BIND, PowerDNS Recursor, Knot Resolver und Unbound. Ein zweiter Dual-Stack-Name erzeugt mehrere Namens- und Adressoptionen; sein Effekt hängt von Software und Topologie ab.

So sieht ein belastbarer Reproduktionsbeleg aus

Ein Folgelauf sollte Tests im selben Messfenster zufällig auf die Ein- und Zwei-Server-Variante verteilen oder beide in kurzen, vorab festgelegten Blöcken abwechseln. Die Anzahl je Block gehört in den Bericht, damit ein Wechsel von Tag, Kampagne oder Verkehr nicht als Servereffekt erscheint.

In datenschutzgerechten Summen sollte die Zusammensetzung nach Großregion, Zugangsnetz, stabiler Resolver-Adresse und IP-Familie folgen. Es geht nicht um Nutzeridentifikation, sondern um die Frage, ob hinter 58 und 71 Prozent vergleichbare Populationen stehen und der Unterschied innerhalb der Schichten erhalten bleibt.

Bis auf den zusätzlichen Namen muss die autoritative Oberfläche gleich bleiben: Software, Zoneninhalt, TTL, DNSSEC-Zustand, Antwortcode und -größe, Trunkierung, UDP/TCP, Beobachtungszeit, Adressen, Standorte und Routing. Ob ein Endpunkt Unicast oder Anycast verwendet, muss genannt werden. Zwei Namen hinter demselben Standort prüfen eine andere Resilienz als zwei topologisch getrennte Dienste.

Schließlich gehören Normalisierungsformel, Ausschlüsse, Nenner, rohe und normalisierte Kurven sowie Unsicherheitsintervalle in den Beleg. Bereiche unter 10 ms, von 10 bis 70 ms, spätere Timer-Spitzen und der Ausläufer nach fünf Sekunden sollten getrennt werden. Frontend-Verteilung, Backend-Parallelität, IP-Familie, Resolver-Software, Cache und Kampagnengeografie sind vorab als alternative Mechanismen zu benennen.

Zwei Server bleiben aus einem anderen Grund sinnvoll

Diese Prüfung stellt mehrere autoritative Server nicht infrage. RFC 2182 empfiehlt mehrere physisch und topologisch getrennte Server für Zuverlässigkeit und Lastverteilung. Eine frühere APNIC-Studie kam ebenfalls zu mindestens zwei getrennten, dual-stack-fähigen und geografisch vielfältigen Diensten; oberhalb von zwei wurden die zusätzlichen Gewinne in ihren Messungen kleiner.

Der Grund ist Kontinuität: Fällt ein Server, Pfad oder Standort aus, kann ein anderer die Zone erreichbar halten. Dafür muss nicht behauptet werden, ein zweiter Server senke jede rekursive Last von 3,43 auf 2,57. Betreiber können die Resilienzregel heute anwenden und zugleich eine kontrollierte Reproduktion verlangen, bevor sie den beobachteten Unterschied für Kapazität, Softwaredesign oder Prognosen verwenden.

Die tragfähige Aussage bleibt begrenzt. APNIC hat eine deutliche Verschiebung zwischen zwei veröffentlichten Baselines gemessen und die Ursache offengelassen. Ein gemeinsamer Beleg für Zeit, Kohorte und Topologie würde ehrliche Unsicherheit in ein reproduzierbares Betriebsergebnis verwandeln.

Quellen