Funktion

On-Prem-GSLB

Setzen Sie souveränes Traffic-Management ein, das in Ihrem eigenen Rechenzentrum läuft — keine externe Cloud für DNS- oder GSLB-Entscheidungen erforderlich.

TR7 On-Prem-GSLB vereint autoritatives DNS und die Entscheidungs-Engine für globales Traffic-Routing auf derselben Plattform. Zoneninhalte, Anfrage-Records, geografische Mapping-Daten und DC-Health-Zustand bleiben alle innerhalb der eigenen Infrastruktur der Organisation — GSLB-Entscheidungen werden nie an die Cloud eines externen Anbieters delegiert. TR7 GTM liefert DC-Failover, geografisches Routing, Health-Check-Szenarien, DNSSEC, AXFR/IXFR, dynamische Record-Updates und Topologie-Regeln unter einem einzigen Management-Modell. Records eines unhealthy DC können automatisch aus DNS-Antworten entfernt werden; Client-Subnetz, Land, Stadt, ASN oder CIDR können differenzierte Antworten steuern. Diese Architektur ist besonders für Finanzen, Behörden, Gesundheitswesen, Telekommunikation und jede Organisation mit Datenresidenz-Verpflichtungen relevant. DNS ist nicht nur eine Auflösungsschicht — es ist der Entscheidungspunkt für Anwendungszugriff und Kontinuität. Diesen Entscheidungspunkt On-Prem zu halten, stärkt die operative Kontrolle. Das Ergebnis: TR7 entfernt die SaaS-DNS-Abhängigkeit aus dem GSLB; es macht autoritatives DNS, DC-Failover, Geo-Routing und Health-Szenarien zu einer lokalen Traffic-Management-Schicht, die auf den eigenen Appliances der Organisation läuft.

Unterstützte DNS-Record-Typen

Automatische Health-Check-Typen pro DC

<3 s

Dynamische Konfigurations-Regenerierungszeit

Werden Ihre GSLB-Entscheidungen in der Cloud getroffen, haben Ihre Zonendaten und Traffic-Policy das Gebäude bereits verlassen.

Viele Organisationen setzen für globales Traffic-Routing auf externe DNS- und GSLB-Dienste. Das Modell erscheint praktikabel, doch Zoneninhalte, Query-Logs, Geo-Entscheidungen und Routing-Richtlinien liegen allesamt auf einer Plattform außerhalb der Organisation. Für Finanz-, Behörden-, Gesundheitssektor und regulierungssensible Umgebungen wirft das gewichtige Fragen zur Datensouveränität auf.

Das Auslagern der GSLB-Entscheidungsschicht bringt zusätzlich Risiken für die Betriebskontinuität. Ein Ausfall, Konfigurationsvorfall oder API-Zugriffsproblem beim externen Anbieter wirkt sich direkt auf die DC-Failover- und DNS-Response-Policy der Organisation aus. Ihre Anwendungen können up sein, aber der Traffic erreicht möglicherweise nicht das richtige DC.

Eine weitere Lücke entsteht, wenn autoritatives DNS und Health Checking unterschiedliche Produkte sind. Das Health-Check-System sieht, dass ein DC unhealthy ist, doch wenn das DNS-System das nicht automatisch widerspiegelt, muss ein Skript, manuelles Runbook oder eine separate Automatisierung die Lücke überbrücken. In einem Vorfall wird diese Brücke zum schwächsten Glied.

Der richtige Ansatz besteht darin, autoritatives DNS, Health-Check-Szenarien, DC-Failover und Topologie-Routing-Entscheidungen auf derselben lokalen Plattform zusammenzuführen. DNS-Antworten sollten auf der Appliance auf Basis realer DC-Health und Traffic-Policy neu erzeugt werden; Query-Daten und Zoneninhalte müssen unter organisatorischer Kontrolle bleiben.

TR7 On-Prem-GSLB liefert dieses Modell: Autoritatives DNS und die GSLB-Entscheidungs-Engine laufen auf derselben Plattform und ermöglichen DC-Failover und geografisches Routing, ohne dass Daten die Räumlichkeiten verlassen.

Unser Ansatz

TR7 baut die On-Prem-GSLB-Architektur rund um autoritatives DNS, ein Cloud-freies Entscheidungsmodell, Health-Szenarien und eine Multi-DC-Prioritätskette auf.

Autoritatives DNS und GSLB konvergieren in einer einzigen Entscheidungs-Engine

TR7 trennt Zonen-Management und GSLB-Entscheidungen nicht in separate Systeme. DNS-Records, DC-Health, Topologie-Regeln und Response-Generierung arbeiten alle innerhalb desselben Management-Modells.

Zonen-, Query- und Geo-Entscheidungsdaten bleiben On-Prem

GeoIP-Datenbanken laufen lokal und DNS-Anfrage-Kontext wird nie an einen externen Dienst zur Entscheidung gesendet. Dieser Ansatz bietet Organisationen mit Datenresidenz- und Souveränitätsanforderungen einen klaren Vorteil.

Health-Szenarien formen DNS-Antworten automatisch

Wird ein DC oder Record unhealthy, können die entsprechenden IPs automatisch aus DNS-Antworten entfernt werden. Es ist keine manuelle Skript-Brücke zwischen Health-Check-Ergebnissen und DNS-Antworten erforderlich.

Multi-DC-Prioritätskette steuert Failover- und Backup-Flows

Jeder Record kann mehrere DC-Einträge tragen und sie in Prioritätsreihenfolge auswerten. Primäre, sekundäre, tertiäre oder DR-Ketten werden innerhalb eines einzigen Record-Modells verwaltet.

Funktionen

On-Prem-GSLB liefert DNS-Record-Management zusammen mit DC-Health, Topologie-Routing, DNSSEC und lokalen Statistiken.

Autoritatives DNS-Backend bietet lokale Record-Speicherung und Response-Generierung

TR7 nutzt die autoritative DNS-Schicht zusammen mit einer lokal laufenden Record-Datenbank und Entscheidungslogik. Zonendaten bleiben On-Prem und DNS-Antworten werden von der lokalen Plattform erzeugt. Das reduziert die Abhängigkeit von externen DNS-Diensten. Die Organisation betreibt ihre GSLB-Policy auf den eigenen Appliances.

35 DNS-Record-Typen bieten breite Zonen-Management-Abdeckung

TR7 unterstützt einen breiten DNS-Record-Satz, einschließlich A, AAAA, CNAME, MX, TXT, SOA, NS, SRV, PTR, CAA, DNSSEC-bezogener Records und weiterer fortgeschrittener Typen. Das bietet die Flexibilität für vollständiges Zonen-Management, nicht nur für einfache A-Record-Steuerung. Unterschiedliche Service- und Sicherheitsanforderungen lassen sich unter dasselbe DNS-Management-Modell bringen. Die Organisation verwaltet ihre DNS-Architektur konsistenter aus einem einzigen Punkt.

EDNS Client Subnet bringt geografische Entscheidungen näher an den tatsächlichen Client

TR7 kann EDNS Client Subnet-Informationen nutzen, um geografische Entscheidungen nicht ausschließlich anhand der Resolver-IP zu treffen. DC- oder Record-Auswahl kann auf dem realen Client-Subnetz basieren. Das reduziert das Risiko, dass Benutzer öffentlicher Resolver in die falsche Region geleitet werden. In globalen Zugriffsszenarien wird eine genauere Traffic-Verteilung erreicht.

Topologie-Regeln unterstützen Entscheidungen nach Land, Stadt, Kontinent, ASN und CIDR

TR7-Topologie-Regeln können DNS-Antworten über Netzwerk/CIDR-, Land-, Stadt-, Kontinent- und ASN-Dimensionen auswählen. Jede Regel kann als positive oder negative Bedingung geschrieben werden. Dieselbe Domain kann daher in unterschiedlichen geografischen oder Netzwerkkontexten unterschiedliche IP-Listen zurückgeben. Geo-Routing wird präziser als ein einfacher länderbasierter Split.

DC-Prioritätskette steuert Primary- und Backup-Verhalten auf Record-Ebene

Jeder Record kann mit einer recordConfig-Struktur verwaltet werden, die die DC-Reihenfolge trägt. Wenn das primäre DC unhealthy ist, können sekundäre oder tertiäre DC-Records aktiviert werden. Dieses Modell erlaubt es, eine Multi-DC-Prioritätskette innerhalb eines einzigen Records aufzubauen. Operatoren können pro Domain oder pro Record unterschiedliche Kontinuitätsstrategien anwenden.

backupBehavior-Modi steuern passive DCs und das Risiko veralteter Daten

Der Modus noResponse hält ein passives DC unter normalen Bedingungen still. Der Modus onlyNew kann verhindern, dass ein lange ausgefallenes DC Antworten auf Basis veralteter Daten serviert. Dieses Verhalten zielt nur auf DCs im korrekten Zustand — nicht nur auf die, die technisch laufen. Die Datenkonsistenz bleibt während Failover und Failback erhalten.

Recursive Forwarder verwaltet interne und externe Auflösung gemeinsam

TR7 kann neben dem autoritativen DNS einen Recursive-Forwarder-Prozess betreiben. Interne Zonen werden an die lokale autoritative Schicht geleitet, während die Auflösung externer Domains über den Forwarder erfolgt. domainBasedForwarding kann bestimmte Domains an unterschiedliche Auflösungspfade routen. Das hilft, internes DNS und GSLB-Entscheidungen innerhalb derselben Appliance-Familie zu konsolidieren.

DNSSEC-Unterstützung stärkt Zonen-Integrität und -Verifizierbarkeit

TR7 kann mit DNSSEC-Unterstützung signiertes Zonen-Management anbieten. NSEC/NSEC3, DNSSEC-Key-Cache und Zonen-Signing-Prozesse erhöhen die Verifizierbarkeit von DNS-Antworten. DNSSEC lässt sich pro Domain aktivieren oder deaktivieren. Das stärkt die Integritätssicherheit kritischer Domains.

AXFR- und IXFR-Unterstützung trägt die Primary-Secondary-DNS-Architektur

TR7 kann sowohl in Primary- als auch in Secondary-DNS-Rollen Zonentransfer-Verhalten unterstützen. AXFR und IXFR erlauben das Übertragen von Records zwischen verschiedenen DNS-Knoten. Das vereinfacht die Integration in bestehende Unternehmens-DNS-Architekturen. Der Einsatz von On-Prem-GSLB erfordert nicht, das bestehende DNS-Betriebsmodell vollständig aufzugeben.

Wartungsmodus verwaltet geplante DC-Wartung auf DNS-Ebene

Der Wartungsmodus kann pro DC angewendet werden. Während geplanter Wartung kann ein DC aus DNS-Antworten entfernt werden, auch wenn es gesund ist, und der Datenverkehr wird auf ein anderes DC gelenkt. Nach Abschluss der Wartung wird das normale Health-Szenario fortgesetzt. Dieses Modell bietet eine kontrollierte Umschaltung ohne manuelle Zonen-Änderungen.

Dynamic DNS Update unterstützt Record-Automatisierung

TR7 kann dynamisches DNS-Update-Verhalten unterstützen, sodass Records von Automatisierungssystemen aktualisiert werden können. Diese Fähigkeit ist wertvoll für variable Infrastrukturen, automatisierte Service-Veröffentlichung oder vorübergehende Record-Bedarfe. Record-Updates können neben dem GTM-Entscheidungsmodell bewertet werden. Operations-Teams können manuelle DNS-Aufgaben reduzieren.

Lokale Statistiken und Record-Counter halten die Query-Sichtbarkeit On-Prem

TR7 kann Statistiken wie DNS-Queries, Cache, rcode, qtype, Latenz, Speicher und Uptime sammeln. Per-Record-Query-Counts zeigen, wie viele Queries jeder Record erhält. Diese Daten stehen für lokale Reports und Kapazitätsplanung zur Verfügung, ohne an eine externe Anbieterplattform zu gehen. DNS wird zu einer messbaren Traffic-Schicht, nicht nur zu einem Response-Generator.

Betriebliche Tiefe

Der On-Prem-GSLB-Betrieb umfasst Port-Trennung, Cache-TTL-Verhalten, Threading, SOA-Defaults, Statistik-Sammlung, State-File-Persistenz und Master-Election.

Interne Port-Trennung

TR7-GTM-Komponenten können separate Port-Bereiche für autoritatives DNS-, API-, Forwarder-Inner- und Forwarder-API-Prozesse verwenden. Diese Trennung erleichtert es, jeden Dienst unabhängig zu überwachen und zu verwalten. Operations-Teams können den Zugriffs- und Health-Status jeder Komponente einzeln nachverfolgen.

Cache-TTL-Verhalten

Query-Cache, Negative-Query-Cache, DNSSEC-Key-Cache und Zone-Cache-Refresh-Intervalle können alle vom primären cacheTtl-Wert abgeleitet werden. Diese Struktur gleicht Performance und Aktualität aus. Kürzere TTLs erlauben schnellere Propagation von Änderungen; längere TTLs reduzieren die Query-Last.

Thread-Konfiguration

Signing-, Distributor-, Receiver- und Retrieval-Prozesse können entsprechend der CPU-Kern-Anzahl skalieren. Dieser Ansatz erhöht die parallele Verarbeitungskapazität unter hohem DNS-Verkehr. Threading-Einstellungen sollten auf Basis von Hardware-Kapazität und Query-Profil geplant werden.

Standard-SOA-Verhalten

Die Standard-SOA-Struktur für neue Zonen kann mit Refresh-, Retry-, Expire- und TTL-Werten erstellt werden. Diese Werte bestimmen das grundlegende Timing-Verhalten des DNS-Betriebs. SOA-Werte sollten separat gemäß organisatorischen Anforderungen geprüft werden.

Statistik-Sammelpipeline

DNS-Statistiken können über API gelesen und in RRD oder ähnliche Zeitreihenstrukturen eingespeist werden. Metriken wie qtype, rcode, Cache-Hit/Miss, UDP/TCP-Queries, Latenz und Speichernutzung werden nachverfolgt. Diese Daten werden für Kapazitätsplanung und Incident-Untersuchung verwendet.

On-Disk-State-Persistenz

DC-Informationen, lokaler Health-State, Szenario-State, dynamische Konfiguration und Zonen-dynamische-Konfiguration können auf Dateiebene gespeichert werden. Nach einem Neustart kann GTM seinen vorherigen Auswertungskontext wiederherstellen. Das reduziert unnötige DNS-Schwankungen bei vorübergehenden Service-Neustarts.

Wann einsetzen

Drei-DC-Kontinuitätskette in einer Finanzinstitution

Finanzinstitute können eine primäre, sekundäre und tertiäre DC-Kette aufbauen. Internet- und Zugriffs-Health-Check-Szenarien entfernen ein unhealthy DC aus DNS-Antworten und leiten Traffic auf das Backup-DC um.

GSLB-Betrieb für Behörden ohne dass Daten die Räumlichkeiten verlassen

Behörden können GTM betreiben, ohne Zoneninhalte, Query-Logs oder Geo-Entscheidungsdaten an externe DNS-Dienste zu senden. On-Prem-GSLB unterstützt Datensouveränität und Audit-Erwartungen.

DNS-Antworten im Gesundheitswesen an Service-Health gebunden

Krankenhausinformationssysteme und kritische Gesundheitsdienste lassen sich mit Health-Check-Szenarien überwachen. Unhealthy Endpunkte werden automatisch aus DNS-Antworten entfernt, was den Bedarf an manuellen Eingriffen reduziert.

Multi-DC- und Geo-Routing in einer Carrier-Umgebung

Telekommunikations-Teams können mit geografischen und netzwerkbasierten Topologie-Regeln verschiedene DCs oder PoP-Standorte auswählen. Client-Subnetz, Land, ASN oder CIDR werden in DNS-Antwort-Entscheidungen einbezogen.

Blue-Green-DNS-Übergang im E-Commerce

E-Commerce-Teams können gewichtetes Record-Verhalten nutzen, um einen kleinen Anteil des Traffics auf eine neue IP-Gruppe zu lenken. Mit erfolgreichem Test wird das Gewicht erhöht, bis der Übergang kontrolliert abgeschlossen ist.

Lokale GTM-Kontinuität innerhalb eines HA-Clusters

GTM-Knoten können innerhalb eines HA-Clusters in Master- und Standby-Rollen arbeiten. Fällt der Master-Knoten aus, übernimmt der Standby die Rolle und sichert die kontinuierliche DNS-Response-Generierung.

Häufig gestellte Fragen

Was ist der grundlegende Unterschied zwischen On-Prem-GSLB und SaaS-DNS?

Bei SaaS-DNS werden Zoneninhalte, Query-Logs und Geo-Entscheidungsdaten an die Plattform eines externen Anbieters übertragen. TR7 On-Prem-GSLB trifft diese Entscheidungen auf den eigenen Appliances der Organisation — Zonendaten und Traffic-Policy verlassen die Räumlichkeiten nicht. Für Finanz-, Behörden- und Gesundheitsorganisationen, die für Datensouveränität und regulatorische Compliance sensibel sind, ist diese Unterscheidung entscheidend.

Wie wird ein unhealthy DC aus DNS-Antworten entfernt?

TR7 GTM integriert Health-Check-Szenario-Ergebnisse direkt mit der autoritativen DNS-Response-Generierung. Wird ein DC unhealthy, werden die entsprechenden IPs automatisch aus DNS-Antworten entfernt — es ist kein manuelles Skript oder Runbook erforderlich. Bei Nutzung des Wartungsmodus kann ein DC auch dann aus DNS-Antworten entfernt werden, wenn es physisch gesund ist.

Wie granular können Topologie-Regeln sein?

TR7-Topologie-Regeln können DNS-Antworten über Netzwerk/CIDR-, Land-, Stadt-, Kontinent- und ASN-Dimensionen auswählen. Jede Regel kann als positive oder negative Bedingung geschrieben werden, und EDNS Client Subnet erlaubt es, das reale Client-Subnetz zu verwenden. Dieselbe Domain kann daher in unterschiedlichen geografischen oder Netzwerkkontexten unterschiedliche IP-Listen zurückgeben.

Lässt sich die DNSSEC-Konfiguration pro Domain verwalten?

Ja. Die DNSSEC-Unterstützung von TR7 lässt sich pro Domain aktivieren oder deaktivieren. Zone-Signing ist mit NSEC/NSEC3 und DNSSEC-Key-Cache möglich; die Integritätssicherheit kann für kritische Domains gestärkt werden, ohne andere zu beeinträchtigen.

Wie wird die Integration in eine bestehende DNS-Architektur erreicht?

TR7 kann über AXFR- und IXFR-Zonentransfer-Unterstützung neben einer bestehenden Primary-Secondary-DNS-Architektur arbeiten. Der Recursive-Forwarder-Prozess läuft separat und kann bestimmte Domains über domainBasedForwarding an unterschiedliche Auflösungspfade routen. Diese Struktur erfordert nicht, das bestehende DNS-Betriebsmodell vollständig aufzugeben.

Wo werden DNS-Statistiken und Query-Daten gehalten?

TR7 sammelt Query-, Cache-, rcode-, qtype-, Latenz-, Speicher- und Uptime-Statistiken lokal. Per-Record-Query-Counts zeigen, wie viele Queries jeder Record erhält. Diese Daten gehen nicht an eine externe Anbieterplattform und stehen für lokale Reports und Kapazitätsplanung zur Verfügung.

Bringen Sie GSLB-Entscheidungen in Ihr eigenes Rechenzentrum

Autoritatives DNS, DC-Failover, geografisches Routing und Health-Check-Szenarien — alles laufend auf den eigenen Appliances der Organisation. Lassen Sie uns gemeinsam ein Setup durchgehen, das zu Ihrer Infrastruktur passt.