Zusammenfassung

  • Gaurav Kansals Bericht zufolge lag der öffentliche NIC-Resolver 1.10.10.10 in einem 91-tägigen RIPE-Atlas-Vergleich bei durchschnittlich 27,0 ms für DNS-Antworten und 17,3 ms für Ping. Das sind vom Autor berichtete Werte, kein unabhängiges Service-Audit.
  • Aussagekraft und Grenzen gehören zusammen: Die populären Testnamen dürften häufig im Cache gelegen haben; Fehler und Paketverlust wurden nicht herausgefiltert; die Beobachtungszahlen weichen voneinander ab; die geprüften öffentlichen Dateien reichen nicht aus, um die Mittelwerte neu zu berechnen.

Eine Zahl ist noch kein Urteil

Im September 2026 veröffentlichte Gaurav Kansal den Beitrag „Monitoring 1.10.10.10 with RIPE Atlas Probes“. Er vergleicht die öffentliche DNS-Adresse des National Informatics Centre (NIC), 1.10.10.10, mit Cloudflare, Google und Quad9. Der angegebene Zeitraum reicht vom 13. November 2025 bis zum 11. Februar 2026. Die folgenden Mittelwerte und Fallzahlen stammen aus seinem Bericht; sie wurden hier nicht anhand von Rohmessungen unabhängig nachgerechnet.

Resolver Mittlerer Ping Ping-Beobachtungen Mittlere DNS-Antwortzeit DNS-Beobachtungen
NIC 1.10.10.10 17,3 ms 1.038.738 27,0 ms 580.916
Cloudflare 1.1.1.1 14,8 ms 1.047.581 43,2 ms 528.540
Google 8.8.8.8 14,8 ms 1.039.961 32,1 ms 596.800
Quad9 9.9.9.9 55,8 ms 1.050.441 112,1 ms 577.032

Beim DNS-Mittelwert liegt das NIC in dieser Messung vor den drei Vergleichsdiensten. Beim Ping schneiden Cloudflare und Google jeweils 2,5 Millisekunden besser ab. Das ist kein Widerspruch: Ping erfasst die Laufzeit eines ICMP-Pakets auf dem Hin- und Rückweg; eine DNS-Anfrage umfasst eine andere Art von Dienstinteraktion. Aus keiner der beiden Größen folgt ein allgemeiner Sieger. „Besser“ könnte Erreichbarkeit, korrekte Antworten, Datenschutz, Sicherheit oder Wiederanlauf nach einem Ausfall bedeuten. Diese Eigenschaften wurden nicht mit einem Latenzmittelwert gemessen.

Der Wert der Arbeit liegt darin, eine öffentliche Infrastruktur vergleichbar zu machen und Zeitraum, Fallzahlen und methodische Einschränkungen zu benennen. Ein nachvollziehbar beschriebener Vergleich ist prüfbarer als eine unbelegte Leistungsbehauptung. Doch eine klare Tabelle beantwortet nur die gestellte Frage. Ihr Ergebnis hängt von den Messpunkten, den abgefragten Namen, dem Cache-Zustand und der Behandlung nicht erfolgreicher Tests ab.

Der tägliche Namenssatz prägt das Ergebnis

Laut Beitrag verwendete der tägliche DNS-Test die zehn im NIC-Verkehr meistabgerufenen Domains des jeweiligen Tages. Dieselben zehn Namen wurden an diesem Tag bei allen vier Resolvern abgefragt; die Liste wechselte täglich. Das ist ein sinnvoller Vergleichsschritt: Innerhalb eines Tages bekommen die Anbieter dieselbe Auswahl statt zufällig verschiedene Anfragen.

Die Auswahl beschreibt zugleich populäre Namen im Umfeld des NIC. Kansal merkt an, dass viele Antworten wahrscheinlich aus dem Cache kamen. Liegt eine Antwort dort bereits vor, muss der Resolver nicht die gesamte hierarchische Namensauflösung erneut durchlaufen. Das macht den Test nicht wertlos. Häufige Domains gehören zum Alltagsverkehr. Es grenzt aber die Aussage ein: Gemessen wird eher das Antwortverhalten bei verbreiteten, möglicherweise wiederholt abgefragten Namen als eine kalte Erstauflösung, seltene Domains oder jede denkbare Anfrage.

Auch die Wahl der Namen ist eine Perspektive: Was im NIC-Verkehr häufig ist, muss nicht die Nutzung sämtlicher indischer Netze abbilden. Das kann für eine betriebliche Fragestellung des NIC passend sein. Es ist keine landesweite Nutzerbefragung. RIPE-Atlas-Sonden bilden die Messpunkte; der Verkehr des NIC bestimmt den Namenssatz. Diese beiden Bezugsgrößen ergeben zusammen noch keine repräsentative Stichprobe des Landes.

Ping ist enger gefasst. Er sagt etwas darüber aus, ob ein ICMP-Paket von der Sonde eine Antwort erhält und wie lange der Netzwerkweg dauert. Er überprüft nicht, ob DNS die richtige Adresse liefert, ob eine Webseite schnell lädt oder eine Anwendung verfügbar ist. Wer Ping und DNS in einer einzigen Kennzahl zusammenzieht, verdeckt die unterschiedlichen Ursachen.

Viele Beobachtungen, offene Nenner

Die gemeldeten Zahlen sind groß: mehr als eine Million Ping-Beobachtungen je Resolver und mehr als eine halbe Million DNS-Beobachtungen. Viele Messungen können einen Mittelwert für die erfassten Vorgänge stabilisieren. Sie erklären aber nicht, welche Vorgänge für den Mittelwert gültig waren, was fehlte oder wie Ausfälle zählten. Bei DNS reichen die Summen von 528.540 für Cloudflare bis 596.800 für Google; auch die Ping-Zahlen sind nicht identisch.

Kansal schreibt, dass Paketverluste und fehlgeschlagene Abfragen nicht aus den Daten herausgefiltert wurden. Das ist eine wichtige Einordnung; der Bericht stellt nicht dar, als wären ungünstige Ergebnisse einfach entfernt worden. Offen bleibt damit noch, wie ein Timeout ohne normale Antwortzeit in den Mittelwert eingeht, ob es Wiederholungsversuche gab und ob die Fallzahl geplante Tests, zurückgegebene Datensätze oder erfolgreiche Antworten meint. Gerade diese Definition des Nenners entscheidet, wie die Zahl zu lesen ist.

Eine Datei im öffentlichen Repository zeigt das Problem, ohne es zu lösen. Die DNS-Zählung vom 13. November 2025 listet Anzahlen je Resolveradresse, aber keine einzelnen Latenzwerte; die Tageszahlen unterscheiden sich. Ein Tag belegt weder Fehler noch Verzerrung oder falsche Mittelwerte. Er macht lediglich deutlich, weshalb die Zählregeln und die zugrunde liegenden Ergebnisse wichtig sind.

Das Repository 1.10.10.10-tests und seine README beschreiben tägliche Zählungen und Diagramme. Im für diese Analyse geprüften öffentlichen Verzeichnisbaum waren keine klar identifizierten Dateien mit Messungs-IDs, vollständigen Latenzprotokollen oder Erfassungsskripten zu finden, anhand derer sich die Mittelwerte rekonstruieren ließen. Diese Feststellung ist auf den geprüften Baum und den Recherchezeitpunkt begrenzt; sie behauptet nicht, dass solche Materialien nirgendwo anders existieren. Die dort sichtbaren Dateien allein reproduzieren die 91-Tage-Mittelwerte nicht.

Ein Mittelwert sagt zudem nichts über die Verteilung. Er zeigt nicht, ob die meisten Antworten nahe 27 ms lagen, ob wenige besonders langsame Tage den Wert verschoben oder ob einzelne Routen deutlich abwichen. Median, hohe Perzentile, Tagesverläufe und Unterschiede zwischen Sonden würden weitere Muster offenlegen. Eine große Zahl von Paketen aus verfügbaren Messpunkten ist nicht automatisch eine repräsentative Stichprobe aller Netze.

RIPE Atlas erweitert Messpunkte, nicht die Unabhängigkeit

Die Dokumentation von RIPE Atlas und zu nutzerdefinierten Messungen beschreibt eine Plattform mit Sonden in unterschiedlichen Netzen. Eine solche Verteilung erweitert die Perspektiven. Sie bedeutet nicht, dass RIPE NCC die Domainliste auswählte, Kansals Aggregation prüfte oder die technischen Schlussfolgerungen bestätigte. Eine von Dritten gehostete Sonde macht eine Messung verteilt; sie macht eine vom Betreiber verfasste Auswertung nicht automatisch zum unabhängigen Audit.

Der Bericht nennt typischerweise 130 bis 145 in Indien platzierte Sonden. Das ist keine ausgewiesene Zufalls- und Gewichtungsstichprobe über Anbieter, Zugangsnetze und Nutzer des Landes. Die Messung kann für die vertretenen Standorte nützlich sein und zugleich offenlassen, wie weit sich das Ergebnis verallgemeinern lässt. Für einen nationalen Mittelwert bräuchte es eine definierte Grundgesamtheit, Auswahlregeln und eine nachvollziehbare Gewichtung.

Rolle und Reichweite auseinanderhalten

Die Autorenbiografie bei APNIC bezeichnet Kansal als Joint Director (IT) beim NIC und schreibt ihm die Leitung von Sarvagya/Bharat Public DNS zu. Sein APNIC-Beitrag ist ein Gasttext; der redaktionelle Hinweis vom August 2026 hält fest, dass die Ansichten dem Autor zuzurechnen sind. Diese Angaben ordnen seine Arbeit institutionell ein. Sie machen ihn nicht zum Sprecher aller indischen Internetnutzer.

Der Cybersicherheitsleitfaden des CGA und ein Beitrag in NIC Informatics vom Juli 2025 nennen 1.10.10.10 und 2409::1 als Konfigurations- beziehungsweise Härtungshinweise. Belegt ist damit eine dokumentierte Empfehlung, nicht die Zahl der Geräte, die sie umsetzen, eine flächendeckende Nutzung oder das Ergebnis für Nutzer.

Kansals persönliche Website nennt außerdem Angaben zu Reichweite, Datenlokalität und Bedrohungsfilterung. Diese Aussagen sind seinem eigenen Profil zuzuordnen. Die Latenzstudie überprüft sie nicht. Eine schnelle DNS-Antwort belegt weder Speicherfristen noch Filtergenauigkeit, Sicherheitsniveau oder Verfügbarkeit. Für jede Eigenschaft braucht es eigene Nachweise.

Das RFC 1034 beschreibt die Grundlagen des Domain Name Systems. Die Antwortzeit eines Resolvers ist nur eine Dimension eines öffentlichen Infrastrukturangebots. Bei einer Konfiguration auf vielen Geräten zählen ebenso Ausweichwege, Datenschutz, Sicherheitsregeln, Änderungsbefugnisse und ein erreichbarer Support im Störungsfall.

Die nächste Messung sollte sich nachrechnen lassen

Eine Folgestudie könnte jede Testreihe mit RIPE-Atlas-Messungs-IDs verknüpfen, Auswahl und Verteilung der Sonden samt Veränderungen dokumentieren, Abfragetyp und Konfiguration genau nennen und die Behandlung von Timeouts, Wiederholungen und fehlgeschlagenen Antworten definieren. Einzelne Ergebnisse und der Aggregationscode würden anderen eine Neuberechnung ermöglichen, soweit Datenschutzgrenzen das zulassen.

Mittelwerte können als kurze Kennzahlen bleiben, sollten aber neben Median, hohen Perzentilen, Tagesverlauf und Anteil fehlender Antworten stehen. Tests populärer, wahrscheinlich gecachter Namen wären von kalten Auflösungen und Abfragen mit bekannter Antwort zu trennen. Verfügbarkeit, Korrektheit, DNSSEC, Datenschutz, Filterung und Sicherheitsreaktion erfordern separate Prüfungen; sie folgen nicht aus einer niedrigeren Latenz.

Auch die Zeitachse ist entscheidend: Die Messperiode endete am 11. Februar 2026, der Beitrag erschien am 17. September. Das Ergebnis ist historisch und keine aktuelle Septembermessung. Wiederholte Erhebungen mit stabilen Definitionen oder transparent erklärten Änderungen könnten zeigen, ob sich das Muster hält.

Die tragfähigste Lesart liegt zwischen zwei Übertreibungen. Weder „das NIC schlägt die großen Resolver“ noch „die Studie sagt nichts“ wird dem Beleg gerecht. Für die berichteten Sonden, Namen, Daten und Methoden lag der vom Autor genannte DNS-Mittelwert des NIC unter den drei Vergleichswerten; beim Ping lag er etwas über Google und Cloudflare. Der Beitrag liefert Kontext und Einschränkungen, doch die geprüften öffentlichen Materialien erlauben keine vollständige Neuberechnung.

Darin liegt die Bedeutung von Kansals Arbeit: Ein Teil eines öffentlichen Dienstes wird durch einen konkreten Vergleich sichtbar. Diese Leistung lässt sich würdigen, ohne aus der Tabelle ein nationales Audit oder aus dem Amt ein Vertretungsmandat abzuleiten. Aussagekräftiger wird ein öffentliches Ranking, wenn seine Grenzen offenliegen und Dritte die Zahlen prüfen können.

Quellen