Zusammenfassung

  • APNIC PING berichtete am 3. September über eine kontrollierte Studie vom Januar 2026, die gewöhnlichen Root-Abfrageverkehr mit dem Aufwand für lokale Root-Zonen vergleicht.
  • Über vier Tage lagen die Mittelwerte bei 4,35 MB pro Resolver und Tag für BIND mit IXFR, 3,93 MB für Unbound über DNS und 2,65 MB für Knot Resolver mit ungefähr einem HTTPS-Update pro Tag.
  • Die 105,12 MB von Unbound über HTTPS entstanden durch 48 vollständige Downloads zu je 2,19 MB. Die Studie bezeichnet das als bestätigten Fehler, nicht als Eigenschaft von HTTPS.

Vier Resolver können in einer Bestandsliste denselben Haken tragen und dennoch völlig unterschiedliche Datenströme erzeugen. Im Versuch warteten BIND und eine Unbound-Instanz auf eine Änderung der SOA-Seriennummer. Knot holte ungefähr einmal täglich eine vollständige Zone. Die zweite Unbound-Instanz lud sie alle 30 Minuten neu.

Darauf lenkt der APNIC-PING-Beitrag vom 3. September den Blick. George Michaelson bespricht das Projekt des Amsterdamer Forschers Ilyas Rahimi mit ihm und Willem Toorop von NLnet Labs. Die Untersuchung fragt nicht, ob eine lokale Kopie Autorität über die DNS-Wurzel gewinnt. Sie misst, welcher Verteilungsaufwand an die Stelle vieler kleiner Anfragen tritt.

Die Aktualisierung entscheidet

Rahimis Forschungsbericht rechnet beide Modelle in Megabyte pro Resolver und Tag um. Für das konventionelle Modell nutzt er RSSAC002-Daten vom 1. bis 7. Januar. Die meisten Root-Buchstaben liegen zwischen 0,67 und 1,34 MB; F-root ist mit 11,18 MB der Ausreißer. Die lokalen Paketmitschnitte stammen aus einer kontrollierten virtuellen Umgebung vom 20. bis 23. Januar.

Getestete Konfiguration Beobachtetes Verhalten MB/Resolver/Tag
BIND, DNS IXFR Transfer nach Serienwechsel, 2-4-mal täglich 4,35
Unbound, DNS IXFR Transfer nach Serienwechsel, 2-4-mal täglich 3,93
Knot Resolver, HTTPS Etwa ein vollständiges Update täglich 2,65
Unbound, HTTPS Vollständiger Download alle 30 Minuten 105,12

BIND übertrug je inkrementellem Update etwa 1,45 MB, Unbound über DNS 1,31 MB. Die Root-Zone änderte sich an den vier Tagen zwei-, drei-, vier- und dreimal. Entsprechend folgte der Tageswert den tatsächlichen Änderungen.

Knot erzeugte im Versuch den niedrigsten lokalen Wert, akzeptierte dafür aber einen zurückhaltenderen Zeitplan. Das ist kein allgemeiner Siegerbeweis: Weniger Updates können Änderungen später sichtbar machen. Beim Wert von 105,12 MB gilt die umgekehrte Vorsicht. Unbound lud die ganze Zone, ohne zuerst eine Serienänderung festzustellen. Laut Bericht bestätigte ein Entwickler den Fehler; die beabsichtigte Korrektur sollte den vollständigen Abruf auf echte Änderungen beschränken. HTTPS selbst verlangt diese Wiederholung nicht.

Die Messung entscheidet keine Einführung

Alle vier lokalen Konfigurationen lagen in den gewählten Fenstern über der konventionellen Vergleichsgröße. Die lokale Beobachtung dauerte jedoch vier Tage, die Basis sieben. Gemessen wurden Bytes, nicht Latenz, DNSSEC-Rechenaufwand, Betriebskomplexität oder Wiederherstellung. Auch der Nutzen geringerer Abhängigkeit von öffentlichen Root-Pfaden erhielt keinen Preis.

Die Hochrechnung ist ebenfalls kein Zensus. Eindeutige RSSAC002-Quelladressen dienen als Näherung für Resolver. NAT und IPv6-Aggregation verhindern eine Eins-zu-eins-Zuordnung. Die Multiplikation mit rund 59,1 Millionen Quellen illustriert lineare Skalierung, sagt aber keine reale Zahl an Terabyte voraus.

RFC 8806 hält die stabile Grenze fest: vollständig, aktuell, DNSSEC-validierbar und Wechsel zu nichtlokalen Roots, bevor veraltete Daten ausgeliefert werden. Der neuere individuelle Internet-Draft 07 behandelt eine Zustandsprüfung vor dem vollständigen Abruf und effiziente HTTPS-Verteilung. Trotz „bcp“ im historischen Dateinamen sagt die redaktionelle Notiz, dass er nicht als BCP verfolgt wird. Er ist keine geltende IETF-Regel.

Für den Betrieb zählen daher Seriennummer, Transferart, Bytes je Update, Zahl der Updates, Validierung und Alter der Kopie. „Lokal“ beschreibt den Ort, nicht die Qualität dieser Schleife.