Zusammenfassung

  • RFC 9520 schreibt vor, Auflösungsfehler mindestens eine Sekunde und höchstens fünf Minuten zu cachen. Ein Treffer unterdrückt ausgehende Arbeit; er beweist weder NXDOMAIN noch NODATA.
  • Ein Auflösungsfehler steht erst fest, wenn kein verfügbarer Server und kein verfügbarer Transport Daten, eine untergeordnete Delegation oder eine brauchbare negative Antwort liefert.
  • Die belastbare Spur umfasst alle Wege und Versuche, zusammengeführte Clients, Cache-Schlüssel und Reichweite, Backoff, vermiedene Ahnenabfragen, Ressourcendruck und die erste kontrollierte Wiederherstellungsprobe.

Als eine fehlende Route den gesunden Eltern Lärm brachte

Am 4. Oktober 2021 trennte ein Wartungsbefehl Facebooks Rechenzentren unbeabsichtigt vom globalen Backbone. Der technische Bericht von Meta erklärt, dass die autoritativen DNS-Standorte daraufhin ihre BGP-Ankündigungen zurückzogen: Sie konnten die Rechenzentren nicht mehr erreichen und galten nach der eigenen Gesundheitslogik als gestört. Die DNS-Server liefen weiter, waren aus dem Internet aber nicht mehr erreichbar.

Der Ausfall blieb nicht bei Facebook. Verisign maß für facebook.com, instagram.com und whatsapp.net im Normalbetrieb insgesamt etwa 7.000 Abfragen pro Sekunde an den .com- und .net-Systemen. Während des fast sechsstündigen Ausfalls stieg der Wert auf mehr als 900.000 pro Sekunde. Die aktivsten Resolver-Quellen von Google und Cloudflare erreichten für diese Namen Spitzen von ungefähr dem 7.000- beziehungsweise 2.000-Fachen ihrer üblichen Raten.

Die Delegationen der Eltern waren unverändert. Eine erneute Abfrage konnte die vom Kind zurückgezogene Route nicht wiederherstellen. Trotzdem verlagerte das Wiederholungsverhalten die Kosten einer unerreichbaren Zone auf funktionsfähige Infrastruktur darüber. Der Resolver war nicht Ursache des ersten Ausfalls, wurde aber zum Mechanismus seiner Vergrößerung.

RFC 9520 verlangt eine lokale Bremse. Wenn keiner der verfügbaren Wege eine brauchbare Antwort liefert, muss der Resolver den Auflösungsfehler speichern. Solange eine spätere Anfrage zu diesem Eintrag passt, darf sie bis zum Ablauf keine entsprechende ausgehende Abfrage erzeugen. Gespeichert wird die Entscheidung, Arbeit vorübergehend nicht zu wiederholen – nicht die Behauptung, der Name existiere nicht.

NXDOMAIN und NODATA sind verwertbare negative Informationen. Ein Auflösungsfehler bedeutet gerade, dass keine verwertbare Information über das Vorhandensein der Daten vorliegt. Aus dem ersten kann eine zeitlich begrenzte DNS-Aussage folgen. Aus dem zweiten folgt nur lokaler Rückstau.

Solange ein Weg offen ist, ist der Fehlschlag nicht vollständig

Resolver haben gewöhnlich mehrere Möglichkeiten: mehrere NS-Namen, mehrere Adressen pro Name und gegebenenfalls mehrere Transporte pro Adresse. Ein einzelnes Timeout, SERVFAIL oder REFUSED beendet diese Matrix nicht.

Als brauchbar gilt eine Antwort mit den angeforderten Daten, einer Delegation zu einer untergeordneten Zone oder einem gültigen Hinweis, dass die Daten am Namen nicht vorhanden sind. Liefert irgendein verfügbarer Server eine solche Antwort, liegt kein Auflösungsfehler vor. Vor dem Cache-Eintrag muss daher nachweisbar sein, welche Adressen und Transporte in Frage kamen und wie jeder Versuch endete.

Für dieselbe Frage an dieselbe Adresse über denselben Transport erlaubt RFC 9520 nach dem ersten Versand höchstens zwei Wiederholungen – drei Abfragen insgesamt. Ein anderer bekannter und sicherheitspolitisch zulässiger Transport zur gleichen Adresse darf versucht werden. Einen allgemeinen Timeout schreibt die Norm nicht vor; typische Werte liegen laut Text ungefähr zwischen drei und dreißig Sekunden.

Diese Offenheit ist eine operative Entscheidung, kein Freibrief zur Unklarheit. Pfadlatenz, Handshake, Anycast und Kundenzusagen unterscheiden sich. Der gewählte Wert, der betroffene Pfad und die tatsächliche Dauer gehören in die Evidenz. Server fehlgeschlagen ohne Restwege und Zeitachse ist kein vollständiges Urteil.

SERVFAIL ist ein Ergebnis, keine vollständige Ursache

Ein autoritativer Server kann SERVFAIL senden, weil ihm gültige Zonendaten fehlen. Ein rekursiver Server kann dasselbe RCODE nach erschöpften Wegen oder fehlgeschlagener DNSSEC-Prüfung senden. REFUSED spiegelt häufig Richtlinie oder Zuständigkeit. Ein Timeout besagt nur, dass bis zur lokalen Frist nichts eintraf; ICMP, TCP oder TLS können den Transport früher beenden.

Delegationsschleifen, Alias-Schleifen und FORMERR haben andere Mechanismen. DNSSEC kann an Signaturen, Schlüsseln, Negativbeweisen oder Zeit scheitern. Der Cache darf diese Ursachen unterscheiden. Seine gemeinsame Wirkung bleibt dennoch klein: entsprechende ausgehende Arbeit zeitlich begrenzt anhalten. Er darf REFUSED nicht in SERVFAIL, ungültige Daten nicht in validierte Daten und Schweigen nicht in Nichtexistenz verwandeln.

RFC 8914 bietet Extended DNS Errors wie Cached Error, No Reachable Authority oder DNSSEC Bogus. Sie verbessern Protokollierung und Erklärung, ändern aber die RCODE-Verarbeitung nicht. Ein lesbarer Grund ist weder signierte Evidenz noch neue Autorität.

Viele Kunden, eine ausgehende Auflösung

Während ein beliebter Name auf Timeout wartet, können hunderte Clients dasselbe QNAME/QTYPE/QCLASS-Tripel senden. Ein Resolver mit Query Joining hängt sie an eine laufende Transaktion. Ohne Joining erzeugt jeder Client eigene ausgehende Versuche und Wiederholungen.

Das auf DNS-OARC 35 vorgestellte und von RFC 9520 zitierte Experiment maß bei normal antwortenden autoritativen Servern etwa 50 Abfragen pro Sekunde für eine Botnet-Domain. Als alle Server SERVFAIL zurückgaben, stieg die Rate auf ungefähr 60.000 pro Sekunde. Auch Root und TLD erhielten mehr Verkehr, obwohl ihre Delegationen unverändert blieben.

Joining verringert außerdem die von RFC 5452 beschriebene Birthday-Angriffsfläche: Mehrere gleichwertige offene Transaktionen geben einer gefälschten Antwort mehrere Trefferchancen. Es braucht drei getrennte Kontrollen: identische Nachfrage bündeln, Versuche pro Pfad begrenzen und den erschöpften Fehler cachen.

Joining bestimmt die Zahl gleichzeitiger Transaktionen. Das Dreierlimit bestimmt die Arbeit pro Pfad. Der Cache bestimmt den Beginn der nächsten Arbeit. Keine dieser Aussagen beweist automatisch die anderen.

Zwischen einer Sekunde und fünf Minuten entsteht Wiederherstellungsschuld

Der Cache muss mindestens eine Sekunde halten und darf fünf Minuten nie überschreiten. Die Mindestdauer sollte konfigurierbar sein. Bei anhaltendem Fehlschlag kann ein linearer oder exponentieller Backoff die Zeit erhöhen, bleibt aber unter der Obergrenze.

Längere Zeit schützt Upstream-Systeme besser, kann jedoch nach einer Reparatur die nächste erfolgreiche Abfrage verzögern. Kürzere Zeit erkennt Erholung schneller, erzeugt aber bei dauerhaftem Ausfall mehr Arbeit. Jede Unterdrückung spart Last und nimmt zugleich Wiederherstellungsschuld auf.

Der Eintrag braucht Schlüssel, Reichweite, Ursachen, Einfügezeit, tatsächliche Dauer, Backoff-Stufe, Ablauf und Konfigurationsversion. Nach Ablauf sollte eine kontrollierte Sonde freigegeben werden, nicht die gesamte aufgestaute Nachfrage. Die erste brauchbare Antwort beendet die Grundlage der lokalen Sperre. Gemessen werden muss die Zeit zwischen technischer Erholung und der ersten wieder beim Client ankommenden Antwort.

Auch die Schlüsselung entscheidet. DNSSEC-Fehler können nach Name, Klasse und Typ gespeichert werden; eine unerreichbare IP kann adressweit gelten. Ein SERVFAIL eines Servers muss andere Server nicht sperren. RFC 2308 definierte konkrete Query- und Serverbereiche, als das Caching noch optional war. RFC 9520 macht die Funktion verpflichtend und lässt ihre interne Form offen. Deshalb muss der Hersteller dokumentieren, was ein Eintrag tatsächlich umfasst.

Der Parent ist kein Reparaturknopf

Bei einer völlig stummen Zone fragten manche Resolver den Parent wiederholt nach dem NS-Satz. RFC 4697 untersagte diese aggressive Wiederholung. RFC 9520 erweitert die Grenze auf alle Query-Typen sowie alle weiteren Ahnen: Sie sind so zu begrenzen wie die fehlgeschlagene Zone selbst.

Ein gesunder Parent kann eine korrekte Delegation wiederholen, aber die Netzstörung des Kindes nicht beheben. Das Auslassen der Anfrage erklärt die Delegation nicht für falsch. Es erklärt nur, dass dieselbe Frage im laufenden Fehlerfenster keine neue brauchbare Information liefert.

Betreiber sollten vermiedene Parent- und Ahnenabfragen zählen. Der Wert zeigt, wohin der Ausfall sonst Last verschoben hätte. Eine kontrollierte Probe nach Ablauf kann weiterhin neue Adressen oder eine geänderte Delegation erkennen. Die Sperre ist legitim, weil sie endet.

DNSSEC-BAD: Den Fehlschlag behalten, dem TTL nicht vertrauen

RFC 4035 erlaubte bereits einen BAD-Cache für wiederholte Validierungsfehler. Da nicht validierte Daten kein vertrauenswürdiges TTL liefern, weist der Resolver eine kurze lokale Dauer zu und schützt den Cache vor Missbrauch.

RFC 9520 macht aus der Erlaubnis eine Pflicht. Validierungsfehler müssen gespeichert werden. Das ungültige RRset wird dadurch nicht zu akzeptierten Daten; gespeichert wird, dass die jüngsten Auflösungsversuche keine akzeptable Antwort hervorbrachten.

Ein EDE kann DNSSEC Bogus oder einen gecachten Fehler erklären. Die technische Spur braucht weiterhin Kette, Zeitpunkt, Reichweite und nächste Probe. Verständliche Semantik ersetzt keine kryptografische Evidenz.

Serve Stale liefert alte Daten; der Fehlercache hält Arbeit zurück

RFC 8767 erlaubt unter einer lokalen Richtlinie die Ausgabe abgelaufener Daten, wenn deren Aktualisierung scheitert. Sie empfiehlt, neue Versuche zur fehlerhaften Autorität häufig auf etwa dreißig Sekunden zu begrenzen. Das erhält Kontinuität, wenn alte brauchbare Daten vorhanden sind.

RFC 9520 greift auch ohne solche Daten: neuer Name, neuer Typ oder deaktiviertes Serve Stale. Eine Stale-Antwort sagt, dass frühere Daten vorübergehend wiederverwendet werden. Ein gecachter Fehler sagt, dass kein Weg brauchbare Daten lieferte und Arbeit bis zum Ablauf ausgesetzt wird. Inhalt und Lastkontrolle sind verschiedene Versprechen.

Auch der Schutzcache kann angegriffen werden

Angreifer können viele zufällige Namen und Typen zum Scheitern bringen und damit Speicher sowie CPU verbrauchen. Nötig sind Grenzen und Messwerte zu Einträgen, Bytes, Einfügungen, Verdrängungen, Konzentration und zufälligen Labels.

Fehlermeldungen sind zudem keine signierten DNS-Daten. Eine passende Fälschung kann den Resolver während des Backoffs von einer echten Autorität fernhalten. Die Fünf-Minuten-Grenze beschränkt ein Ereignis, wiederholtes Spoofing kann es verlängern. Wenige offene Transaktionen, Transportbelege und Vergleiche zwischen Servern und Standorten bleiben entscheidend.

Der Cache ist damit ein Leistungsschutzschalter mit Beweispflicht. Ohne Begrenzung wird Wiederholung zum unfreiwilligen Angriff. Ohne Reichweite und Ablauf wird der Schutzschalter zur Sperre.

Der Mindestbeleg für einen vertretbaren Fehler

Zu speichern sind QNAME, QTYPE, QCLASS, Erstzeit und die verbundene Client-Gruppe. Hinzu kommen Zone Cut, NS-Satz, Adressen, Beobachtungspunkt und Transporte. Jeder Versuch erhält Start, Ende, Wiederholungsordinal, Rohresultat und Ergebnis des Useful-Response-Tests.

Nach Erschöpfung werden RCODE, Transportfehler, DNSSEC und EDE getrennt abgelegt. Dazu kommen Cache-Schlüssel, Reichweite, Einfügung, Dauer, Stufe, Ablauf und Verdrängungspriorität. Vermiedene Ahnenabfragen, vorhandene Stale-Daten und die tatsächliche Client-Antwort gehören ebenfalls hinein.

Flottenweit werden Client-Anfragen, gebündelte Gruppen und ausgehende Queries verglichen. Zu veröffentlichen sind Verstärkungsfaktor, Latenz, CPU, Speicher und Kardinalität. Nach Ablauf identifiziert die Evidenz die Sonde, ihr Ziel, die erste brauchbare Antwort und die sichtbare Erholungsverzögerung.

So bleibt die Entscheidung bei dem Betreiber, der ihre Kosten trägt. Er muss nicht Parent oder IETF um Bestätigung seines Timers bitten. Er muss jedoch zeigen, warum die Arbeit endete und wann sie wieder begann.

Quellen