Klassisches DNS-Round-Robin verteilt IP-Adressen unter demselben Record annähernd gleichmäßig. Dieses Modell mag für einfaches Load Sharing reichen, es bietet aber nicht die Kontrolle, die für neue Release-Rollouts, A/B-Tests, Blue/Green-Cutover oder Rechenzentrumsmigrationen nötig ist. Operations-Teams möchten typischerweise nur 5 % des Traffics an ein neues Ziel senden und den Rest auf dem bestehenden System belassen.
Ohne Gewichtung auf DNS-Ebene muss das Traffic-Splitting in der Anwendungsschicht oder in einer separaten Traffic-Splitting-Schicht gelöst werden. Das bedeutet zusätzliche Architektur, zusätzliches Monitoring, zusätzliche Zertifikatsverwaltung und zusätzliche Fehlerpunkte. Wird die Entscheidung stattdessen in der DNS-Antwort getroffen, wird der Client von der allerersten Anfrage an zum richtigen Ziel geleitet.
Wartungs- und Drain-Szenarien werden durch das Löschen von Records ebenfalls grob behandelt. Eine IP aus einem DNS-Record zu entfernen, wirkt für neue Anfragen, deckt aber nicht den Bedarf, den Traffic-Anteil schrittweise zu reduzieren oder ein Ziel kontrolliert aus der Rotation zu nehmen. Auch das Client- und Zwischen-Resolver-Cache-Verhalten über das TTL-Fenster muss berücksichtigt werden.
Das richtige Modell besteht darin, jedem DNS-Record ein eigenes Gewicht zuzuweisen und den Algorithmus zum Szenario passend zu wählen. Weighted Round Robin eignet sich für ausgewogene, geordnete Verteilung; Weighted Random ermöglicht statistische prozentbasierte Auswahl. Ein Gewicht von 0 versetzt das Ziel in einen effektiven Drain-Modus und entfernt es aus neuen DNS-Antworten.
TR7 Weighted DNS liefert kontrollierte Traffic-Verteilung auf der DNS-Schicht über Per-Record-Gewichte, Weighted Round Robin, Weighted Random, Live-Konfigurations-Reload und Drain-Verhalten bei Gewicht 0.
TR7 hebt die DNS-Antwort aus einer statischen Record-Liste heraus und macht sie zu einer Traffic-Verteilungsentscheidung, gesteuert durch Gewichtswerte und wählbare Algorithmen.
Für jedes IP- oder Record-Element wird ein ganzzahliges Gewicht definiert. Der Weighted-Round-Robin-Algorithmus nutzt diese Gewichte, um DNS-Antworten proportional über den Pool zu verteilen.
Der Weighted-Random-Algorithmus führt bei jeder Anfrage eine gewichtsproportionale Zufallsauswahl durch. Bei hohem Anfragevolumen konvergiert die beobachtete Traffic-Verteilung zu den definierten Gewichtsverhältnissen.
Gewichtsänderungen gelangen in die Live-Konfigurations-Reload-Pipeline und neue Anfragen erhalten sofort die aktualisierte Verteilung. Da zuvor gecachte Antworten bis zum TTL-Ablauf leben, ist die TTL-Planung in schnellen Übergangsszenarien essenziell.
Wird das Gewicht eines Records auf 0 gesetzt, wird es aus der aktiven Kandidatenliste entfernt. Dieses Verhalten bietet kontrollierten Drain für Wartung, Rollback oder Außerbetriebnahme eines Rechenzentrums.
Weighted DNS verwaltet Per-Record-Gewichtswerte zusammen mit Algorithmusauswahl, Live-Updates, Topologie-Integration und Wartungs-Szenarien.
In TR7 kann jedes Record-Element seinen eigenen Gewichtswert haben. Dieser Wert bestimmt den relativen Traffic-Anteil — Gewichte von 5 und 2 zielen auf ein Verhältnis von etwa 5:2. Wird ein Float angegeben, wird er vor der Verwendung auf eine ganze Zahl gerundet. Das Modell macht es einfach, kapazitätsstärkeren Zielen einen größeren Anteil und Testzielen einen kleineren zu geben.
Weighted Round Robin wählt Records in Rotation gemäß ihren Gewichtsverhältnissen aus. Es ist die bevorzugte Wahl, wenn ausgewogene Verteilung erwartet wird und die sequenzielle Nutzung von Records akzeptabel ist. Es ist ein praktischer Algorithmus für Canary-Releases, schrittweise Rollouts und kapazitätsproportionales Traffic-Sharing. Operatoren formen die Verteilung neu, indem sie schlicht die Gewichtswerte ändern.
Weighted Random erzeugt bei jeder DNS-Anfrage eine gewichtsproportionale Zufallsauswahl. Über kurze Zeitfenster können kleine Abweichungen auftreten; bei hohem Anfragevolumen konvergiert die Verteilung zu den definierten Verhältnissen. Es eignet sich gut für A/B-Tests und experimentelles Traffic-Routing. Neue Ziele mit niedrigem Gewicht können innerhalb desselben Record-Pools sicher erprobt werden.
Wenn sich Gewichtswerte ändern, betritt die GTM-Konfiguration den Live-Reload-Prozess. Ein Debounce-Mechanismus fasst schnelle aufeinanderfolgende Änderungen zusammen und reduziert unnötiges Re-Rendering; die typische Live-Reload-Latenz liegt bei etwa 3 Sekunden. Neue DNS-Anfragen erhalten die aktualisierte Gewichtsverteilung. Zuvor gecachte Antworten in Client- und Resolver-Caches bleiben bis zum TTL-Ablauf bestehen.
Ändert sich ein DNS-Gewicht, aktualisiert das System neue Antworten sofort; bereits ausgegebene DNS-Antworten leben jedoch in Zwischen-Caches bis zum TTL-Ablauf weiter. Für Canary-, Blue/Green- oder schnelle Rollback-Szenarien sollte die TTL niedrig gehalten werden. Werte im Bereich von 5–60 Sekunden lassen Übergänge schneller wirken. In stabilen Betriebsphasen ist eine höhere TTL angemessen.
Wenn das Gewicht einer IP oder eines Record-Elements 0 erreicht, wird dieses Ziel aus neuen DNS-Antworten entfernt. Damit lässt sich ein Record für Wartung drainen, ohne ihn zu löschen. Bestehende gecachte Antworten nutzen die alte Antwort weiter bis zum TTL-Ablauf; neue Anfragen erhalten das Ziel nicht mehr. Es ist eine kontrollierte und reversible Methode für Wartung, Rollback oder Rechenzentrums-Außerbetriebnahme.
In TR7 ist die Verteilung nicht auf eine einzelne IP-Ebene beschränkt — Rechenzentrumsgruppen- und Record-Element-Gewichtslogik können kombiniert arbeiten. Zuerst wird das passende Rechenzentrum oder die Kandidatengruppe ausgewählt; Records innerhalb dieser Gruppe werden dann nach Gewicht verteilt. Dieses Modell hilft, sowohl Kapazität als auch Standort im globalen Traffic-Management zu berücksichtigen. In großen Deployments wird die Verteilung mehrschichtiger und besser handhabbar.
Bei Verwendung geo- oder topologiebasierter Auswahl wird zuerst die passende Kandidatengruppe identifiziert. Die Gewichtsverteilung wird dann innerhalb dieses Kandidatensets angewendet. Europäische Benutzer werden beispielsweise zur europäischen Rechenzentrumsgruppe gelenkt, während IPs innerhalb dieser Gruppe gewichtet werden. Die Topologie-Entscheidung und die Gewichtsentscheidung werden nacheinander angewendet, ohne sich gegenseitig zu stören.
Records, die keine gewichtete Verteilung benötigen, können klassisches Round Robin oder Random nutzen. Round Robin verteilt Records gleichmäßig; Random wählt zufällig aus. Diese Algorithmen reichen für einfache Szenarien und werden über dasselbe Record-Modell verwaltet, sodass der Wechsel zu gewichteten Algorithmen keine strukturellen Änderungen erfordert. Operatoren wählen das passende Verteilungsverhalten für jeden DNS-Record.
Der Closest-Algorithmus steht für A- und AAAA-Records bereit, die eine IP-Nähe-Auswahl benötigen. Anders als gewichtete Verteilung konzentriert er sich darauf, das nächstgelegene oder passendste Ziel für den Client auszuwählen. Topologie, Closest und Gewicht können im globalen Traffic-Management als eigenständige Entscheidungsschichten dienen. Das Ergebnis ist eine DNS-Antwort, die kontextbewusst statt nur zufällig ist.
Weighted DNS wird zusammen mit Gewichtsformat, Algorithmusauswahl, Live-Reload-Latenz, TTL-Auswirkung und Record-Auswahlverhalten betrieben.
Gewicht wird als Zahl definiert und als Ganzzahl verwendet. Wird ein Float angegeben, wird er gerundet. Gewichtsverhältnisse repräsentieren relative Anteile unter Records, keine absoluten Prozente.
Weighted-Round-Robin- und Weighted-Random-Algorithmen nutzen die Record-Liste zusammen mit einer Gewichts-Map. Für jeden Record werden indexierte Gewichtswerte erzeugt. Diese Struktur wird von der Selector-Funktion bei der DNS-Response-Erzeugung ausgewertet.
Konfigurationsänderungen durchlaufen einen entprellten Live-Reload-Prozess. Der typische Debounce-Wert liegt bei 3 Sekunden; bei Bursts schneller aufeinanderfolgender Änderungen kann ein maximales Wartelimit gelten. Dieses Verhalten reduziert unnötig häufige Re-Render-Operationen.
Eine Gewichtsänderung wirkt auf neue DNS-Anfragen. Clients oder Resolver, die bereits eine frühere Antwort erhalten haben, nutzen den gecachten Record bis zum TTL-Ablauf weiter. Daher ist die TTL beim Planen von Übergängen ein ebenso wichtiger Betriebsparameter wie das Gewicht.
Gewicht 0 wird verwendet, um einen Record aus der aktiven Kandidatenliste zu entfernen. So lässt sich Wartung oder Migration durchführen, ohne den Record vollständig zu löschen. Um den Record wieder einzusetzen, wird das Gewicht zurück auf einen positiven Wert gesetzt.
In bestimmten Szenarien kann statt eines Algorithmus eine Zahl angegeben werden, um die ersten N Records aus der Kandidatenliste auszuwählen. Dieses Verhalten ist für einfache, deterministische Record-Begrenzung nützlich. Es ist eine praktische Option für Sonderfälle, in denen keine gewichtete Verteilung erforderlich ist.
Die IP des neuen Releases erhält ein niedriges Gewicht; das aktuelle Release ein hohes. Die neue Version startet bei rund 5 % des Traffics; sehen die Metriken gesund aus, wird das Gewicht schrittweise erhöht. Tritt ein Problem auf, wird das neue Release durch Setzen des Gewichts auf 0 gedraint.
Während die Blue-Umgebung aktiv ist, wird die Green-Umgebung mit niedrigem Gewicht getestet. Beim Cutover wird das Gewicht von Blue auf 0 reduziert und Green wird das einzige aktive Ziel. Wird ein Rollback benötigt, werden die Gewichte umgekehrt, um zur vorherigen Umgebung zurückzukehren.
Zwei Landing-Pages oder zwei Service-Varianten werden mit separaten IP-Records definiert. Gewichte können 1:1 für einen gleichberechtigten Test oder 9:1 für ein begrenztes Experiment gesetzt werden. Basierend auf der Ergebnisauswertung wird das Traffic-Verhältnis auf DNS-Ebene angepasst.
Das alte Rechenzentrum startet mit hohem Gewicht; das neue Rechenzentrum wird mit niedrigem Gewicht eingeführt. Das Operations-Team verschiebt Traffic über eine gestufte Reduktion wie 100 → 80 → 50 → 20 → 0 zum neuen Zentrum. Wird die TTL niedrig gehalten, ist die Auswirkung jedes Schritts schneller beobachtbar.
Backends mit höherer Kapazität erhalten ein höheres Gewicht; eingeschränktere Ressourcen ein niedrigeres. Die Traffic-Verteilung wird proportional zur Serverkapazität. Operatoren formen die Verteilung allein durch Aktualisierung der Gewichtswerte neu.
Das Gewicht des in Wartung genommenen Backends wird auf 0 reduziert. Neue DNS-Anfragen werden nicht mehr zu diesem Ziel geroutet; zuvor gecachte Antworten werden bis zum TTL-Ablauf weiter genutzt. Nach Abschluss der Wartung wird das Gewicht auf einen positiven Wert zurückgesetzt und das Backend kehrt in den Dienst zurück.
Per-Record-Gewichte und Live-Reload für Canary-Releases, Blue/Green-Cutover, A/B-Tests und Rechenzentrumsmigrationen. Gehen wir gemeinsam ein Live-Setup in Ihrer Umgebung durch.