Zusammenfassung

  • RFC 1794 beschreibt eine Diskussion von 1995 darüber, wie sich DNS-Adressen nach der Serverlast ordnen ließen, ohne das Protokoll zu ändern.
  • Ein autoritativer Server konnte eine Präferenz veröffentlichen; Caches, sekundäre Server und eine lokale Sortierung beim Client machten daraus jedoch keine verbindliche Zielzuweisung.

Eine sortierte Antwort war noch keine Verbindung

Ein Name kann auf mehrere gleichwertige Rechner verweisen. Ist einer davon weniger ausgelastet, liegt es nahe, dessen Adresse zuerst auszugeben. DNS liefert jedoch Resource Records; den Anwendungskontakt stellt es nicht selbst her. RFC 1794 macht diesen Unterschied zum Ausgangspunkt: Die Reihenfolge konnte nützlich und vorhersehbar sein, aber das Protokoll garantierte nicht, dass ein Client sie beibehielt.

Das im April 1995 veröffentlichte Dokument trägt den Status Informational. Es erklärt ausdrücklich, keinen Internetstandard festzulegen. Der Autor wollte einen Vorstoß in der DNS-Arbeitsgruppe und die erwogenen Alternativen festhalten. Zugleich warnte er, dass Teile der Vorgeschichte fehlen könnten. Das Memo belegt daher eine Designdebatte, nicht die Zahl produktiver Installationen oder deren Leistung.

Von der Rotation zur Lastmessung

Der Autor datiert frühe Änderungen an BIND, die die Reihenfolge von Adressdatensätzen variierten, ungefähr auf 1986. Als vermutlich weit verbreitete Beispiele nennt er Bryan Beechers Shuffle-Address-Änderungen und Marshall Roses Round-Robin-Code. Diese Einordnung ist ein späterer Rückblick, keine unabhängige Bestandsaufnahme.

Eine Rotation änderte, welche Adresse vorne stand, erfasste aber nicht die tatsächliche Auslastung eines Rechners. RFC 1794 stellt dem Änderungen gegenüber, die Matt Madison bei TGV zugeschrieben werden: VMS-eigene Funktionen lasen die Systemlast aus und sortierten A-Records vom geringsten zum höchsten Wert. Das bezog den Zustand der Hosts stärker ein, hing aber von einem bestimmten Betriebssystem ab und erforderte Eingriffe in die Record-Verarbeitung. Die einfache Rotation war portabler, sah aber keine Last; die Messung lieferte mehr Kontext, war jedoch weniger allgemein.

Kompatibilität verlagerte die dynamische Arbeit

Zu den Kriterien der Arbeitsgruppe gehörten Rückwärtskompatibilität, häufig wechselnde Informationen, mehrere Adressen pro Antwort, ein stimmiges Zusammenspiel mit anderen Record-Typen, unterschiedliche Lastbegriffe und schnelle Berechnung. Fünf Minuten galten als üblicher Aktualisierungsabstand; sechzig Sekunden wurden als Möglichkeit genannt, nicht als gemessene Leistung. Mehrere Adressen sollten eine Alternative lassen, falls der bevorzugte Rechner vor Ablauf des TTL ausfiel. Eine erfolgreiche Umschaltung war damit nicht zugesichert.

Änderungen am Protokoll oder ein neuer Record-Typ galten angesichts der installierten Basis als riskant. RFC 1794 beschreibt stattdessen einen Vorschlag von Rob Austein: Das Programm für Zonentransfers sollte intelligenter werden. Es könnte Lastdaten beschaffen, die Zonendaten neu sortieren und dem Nameserver übergeben, ohne das Format der DNS-Nachrichten anzutasten. Der Anfragepfad blieb vertraut; dynamisch wurde die Aufbereitung der Zone.

Damit verschwand der Aufwand nicht, sondern wechselte den Ort. Zonentransfers aktualisieren sekundäre Nameserver; der primäre Server verwendet keinen Transfer, um seine eigenen Anfragen zu beantworten. Bei einer volatilen Teilzone kam es deshalb auf das Refresh-Intervall an. Niedrige TTL-Werte sollten dafür sorgen, dass eine neue Reihenfolge schneller bei Resolvern ankam. Außerdem durfte die Berechnung nicht länger dauern als die Gültigkeit ihrer Datengrundlage. Ein frisches Ranking am Ursprung konnte veraltet sein, wenn ein Client einen Cache-Eintrag verwendete.

Die letzte Wahl blieb lokal

RFC 1794 hält fest, dass DNS keine Reihenfolge der Records garantiert. Der Autor nennt die Reihenfolge vorhersagbar, weist aber darauf hin, dass Clients Adressen lokal umsortieren können, etwa mithilfe einer Sortliste. Ein Zonentransferprogramm konnte diese entfernten Entscheidungen nicht vorhersehen. Mehrere zurückgegebene Adressen bewiesen weder, dass der Client alle ausprobierte, noch dass der nächste Host gesund war oder die Anwendung erfolgreich arbeitete.

Historisch geht es weniger darum, DNS zum Load Balancer zu erklären, als darum, die Grenzen der jeweiligen Zuständigkeit sichtbar zu machen. Ein Betreiber konnte eine Präferenz berechnen und veröffentlichen. Sekundäre Server und Caches beeinflussten ihre Verbreitung. Der Client wählte das tatsächliche Ziel. RFC 1794 beschreibt eine Arbeitsweise innerhalb dieser Grenzen, belegt aber weder ihre Verbreitung noch ihren Betriebserfolg.

Quellen