Zusammenfassung

  • RFC 3568 ist eine Informational-Bestandsaufnahme von 2003 zu Mechanismen, die bis Dezember 2000 bekannt oder im Einsatz waren. DNS, Transport und Anwendung sehen jeweils andere Anfrager und Felder.
  • „Best“ ist eine befristete Entscheidung aus Beobachter, sichtbarer Identität, Kandidaten, Messrichtung und -alter, Policy und Übergabe. Erst Dienst- und Anwendungsergebnis schließen die Beweiskette.

Anycast kann mehreren DNS-Entscheidern dieselbe Adresse geben. Das Routing stellt die Anfrage an eine Instanz zu, die dem Client-Site-DNS nach OSPF/BGP nahe erscheint. Damit ist der Ort der Entscheidung gefunden.

Nicht gefunden ist automatisch der beste Inhaltsserver. Routingprotokolle sind üblicherweise nicht lastempfindlich; routingnah bedeutet nicht zwingend latenzarm; die Last des DNS-Servers spielt in diesem Schritt nicht mit. Vor allem ist der Resolver nicht der Client.

DNS leiht sich die Identität des Resolvers

Ein spezieller DNS-Server kann A-, NS- oder CNAME-Antworten anhand von Regeln und Messungen variieren. Eine Antwort benennt ein Surrogat oder eine virtuelle Gruppe; mehrere A-Einträge bieten eine Menge, die ein Resolver durchlaufen kann.

Die Clientadresse wird jedoch normalerweise nicht in der DNS-Anfrage weitergegeben. Sichtbar ist der lokale Resolver. Bei rekursiver Auflösung sieht der Entscheider womöglich nur einen weiteren DNS, der in dessen Namen fragt. Eine RTT zu diesem Host ist eine RTT zum sichtbaren Resolver, nicht zu jedem Nutzer dahinter.

Geteilte Resolver geben während des TTL-Intervalls vielen Clients dieselbe Adressmenge. Das kann eine Flash-Crowd auf ein Surrogat bündeln. Kurze TTLs erlauben schnellere Reaktion, erhöhen aber DNS-Last; Implementierungen halten TTLs nicht immer ein. Die Antwort kann also länger leben als Messung und Policy, die sie erzeugten.

Der Beleg muss Client, Client-Site-DNS und sichtbaren Rekursor trennen. Er muss Cachebereich, TTL, Messzeit und Policyversion verbinden. „Nächster“ ohne Bezugsobjekt ist kein vollständiger Messwert.

Mehrstufige Auflösung verteilt Autorität

NS- und CNAME-Weiterleitungen lassen mehrere spezialisierte DNS an einer Auflösung mitwirken. NS ist durch Namensbestandteile begrenzt, kann Sonderfall-Timeouts und Zusatzverzögerung erzeugen und dem letzten DNS Einfluss auf die Cachezeit geben. CNAME wechselt in eine neue Domain und verursacht eine weitere Auflösung.

Das Endergebnis muss die Stufen behalten: Eingang, Kandidaten, Entscheidung, Ausgang und Ablaufzeit. Sonst erscheint eine Kette verteilter Verantwortung als anonyme letzte Adresse.

DNS sieht außerdem Namen statt Objekte. Objekttyp oder Hash können im Namen codiert werden, doch eine Webseite braucht dann womöglich mehrere Auflösungen. Feinere Auswahl bezahlt man mit mehr Arbeit.

Transport macht den Client sichtbar und den Pfad asymmetrisch

Die Untersuchung des ersten Pakets liefert Client-IP, Port und Layer-4-Protokoll. Damit lässt sich die DNS-Vorauswahl verfeinern. Wie eine Sitzung übergeben wird, lässt RFC 3568 außerhalb seines Umfangs.

Der Hinverkehr zum neu gewählten Surrogat kann weiter über das ursprünglich per DNS gewählte Surrogat laufen. Der umfangreichere Rückverkehr kann direkt zum Client gehen. Ein Vorgang besitzt damit Auswahl-, Hin- und Rückpfad.

Messwerte brauchen Richtung und Ziel. Übergaben brauchen Annahme, Wirksamkeitszeit und tatsächlichen Pfad. Ein direkter Rückweg beweist nicht, dass die Anfrage denselben günstigen Weg nahm.

Anwendungssicht kostet Eingriffsbefugnis

Auf Anwendungsebene sind URL, Header, Cookies, Sprache und User-Agent sichtbar. Der Entscheider kann objektbezogen umleiten, eine Verbindung im Pfad abfangen und spleißen oder eingebettete URLs umschreiben.

Ein 302-artiger Redirect fügt eine Runde hinzu und ist erst mit der Folgeanfrage wirksam. Ein In-Path-Element bringt Parsing und Zustand in den Datenpfad. URL-Umschreibung lässt die erste Anfrage am Origin und konserviert die Auswahl in einer Seite. Bleibt sie im Cache, können alte URLs auf ausgefallene oder schlechte Surrogate zeigen.

TLS setzt die Machtgrenze. Ohne Terminierung sieht das Content Network die vollständige URL nicht. Wer sie sehen will, übernimmt Zertifikatsverantwortung und Zugriff auf Anfragedaten. Mehr Auswahlkontext ist daher zugleich mehr kryptografische Autorität.

Messungen behalten ihren Standort

Der RFC nennt RTT, Hopzahl, BGP-Informationen, Last und Inhaltsverfügbarkeit. In DNS-Systemen wird Nähe häufig zum lokalen Resolver gemessen. Manche Werte betreffen nur eine Richtung; Internetpfade können asymmetrisch sein.

Aktive Probes sind periodisch, werden durch NAT oder Firewall blockiert und können Alarm auslösen. Ausbleibende Antwort ist nicht eindeutig Entfernung oder Ausfall. HTTP-Probes liefern Last nicht zuverlässig in Echtzeit; alte Rückmeldungen können falsch sein. Selbst BGP AS_PATH kann laut RFC als Auswahlmetrik bedeutungslos sein.

Zu jedem Wert gehören Quelle, Ziel, Methode, Richtung, Zeit, Rohwert und Fehlersemantik. Zur Policy gehören Version, Einschränkungen, Gewichte und Tie-Break. Nur dann lässt sich die Auswahl reproduzieren.

Der Beleg endet nicht bei der Wahl

Die Kette erfasst sichtbaren Anfrager, Anfrage, Resolverfolge, Cache, Kandidaten, Objektverfügbarkeit und Messungen. Dann folgen Policy, Wahl und Ablauf. Danach DNS-Antwort, Redirect, Rewrite, Interception oder Handoff; TLS-Terminierung; Annahme, Last beim Dienst, tatsächlicher Rückpfad, Abschluss, Retry und Anwendungsergebnis.

DNS-Antwort ist keine Verbindung. Redirect ist keine Folgeanfrage. Rewrite ist keine Lieferung. Auswahl ist keine Annahme. Keine Schicht darf für die nächste quittieren.

Evidenzgrenze

Dieser Artikel nennt kein CDN, keinen Betreiber, Resolver, Client, Origin, Lieferknoten, Anbieter, Vorfall oder gemessenen Gewinn. RFC 3568 ist eine historische Informational-Übersicht, kein Standard oder heutiger Betriebsnachweis.

RFC 3466 liefert das damalige Modell, RFC 3238 die Vermittlergrenze. RFC 2782, RFC 1546, RFC 1034, RFC 1035 und RFC 2181 geben DNS-Kontext; RFC 3272, RFC 2386 und RFC 3221 Routing-Kontext. RFC 7336 und RFC 8008 sind spätere CDNI-Evolution, nicht rückwirkende Belege.

Heng Lus Texte zu Running-Code Primacy und Minimum Initial Specification sind offengelegte redaktionelle Blickwinkel. Sie begründen die Prüfung laufender Lieferung und eine kleine gemeinsame Schnittstelle, nicht die Absicht der RFC-Autoren oder ein Betriebsergebnis.

Die begrenzte Folgerung lautet: Anycast kann einen Entscheider finden; nur eine durchgehende Belegkette kann zeigen, ob dessen Auswahl den richtigen Client, das richtige Objekt und den tatsächlichen Dienst traf.

Sources