Funktion

Geografisches DNS-Routing

Formen Sie DNS-Antworten anhand des realen Client-Subnetzes des Benutzers — nicht des Standorts des Resolvers.

TR7 Geografisches DNS-Routing trifft DNS-Entscheidungen nicht ausschließlich anhand der IP des weiterleitenden Resolvers. Mit der Unterstützung von EDNS Client Subnet kann das reale Client-Subnetz einbezogen werden, was genauere Antworten auf Regions-, Länder-, Stadt-, Netzwerk- oder ASN-Ebene erzeugt. Geografisches Routing endet nicht bei "DC nach Land auswählen". TR7 lässt Sie Topologie-Regeln über fünf Dimensionen definieren: Netzwerk/CIDR, Land, Stadt, Kontinent und ASN. Jede Regel kann als positive oder negative Bedingung formuliert werden — eine bestimmte Antwort für bestimmte Länder, eine andere IP für bestimmte ASNs oder ein alternativer Record unter Ausschluss bestimmter Netzwerke. GeoIP-Entscheidungen werden über Offline-Datenbanken auf dem Gerät getroffen. DNS-Anfrage-Kontext wird niemals an einen externen Dienst zur geografischen Auflösung gesendet — ein wichtiger Vorteil in Umgebungen mit Anforderungen an Datenresidenz oder Datenschutz. Das Ergebnis: TR7 GTM hebt geografisches DNS-Routing über die einfache länderbasierte Auswahl hinaus und verwandelt es in eine präzise, kontrollierte, On-Prem-DNS-Entscheidungsschicht, getrieben durch Client-Subnetz, CIDR, Stadt, ASN, Fallback-Logik und Selector-Verhalten.

5
Geografische Entscheidungsdimensionen: Netzwerk, Land, Stadt, Kontinent, ASN
3
Offline-GeoLite2-Datenbanken: ASN, City, Country
32-Bit
IPv4-ECS-Subnet-Präzision

DNS-Routing basierend auf der Resolver-IP spiegelt nicht immer den realen Standort des Benutzers wider.

In klassischen geografischen DNS-Lösungen werden Entscheidungen üblicherweise anhand der IP-Adresse des DNS-Resolvers getroffen. Verwendet ein Benutzer jedoch einen entfernten öffentlichen Resolver, sieht das DNS-System den Standort des Resolvers statt der tatsächlichen Position des Benutzers. Ein Benutzer in der Türkei kann dadurch in ein Rechenzentrum in der falschen Region oder zu einem unnötig entfernten PoP geleitet werden.

Einschichtiges, rein länderbasiertes Routing reicht für die meisten Unternehmensszenarien ebenfalls nicht aus. Innerhalb desselben Landes können unterschiedliche Carrier, unterschiedliche ASNs, unterschiedliche Städte oder unterschiedliche private Netzblöcke jeweils ein separates Routing erfordern. Anforderungen wie Telco-Peering, Compliance, Latenz, CDN-ähnliche PoP-Auswahl und Kampagnen-Routing verlangen feinere Granularität.

Der Einsatz einer Online-GeoIP-API für geografische Entscheidungen bringt zusätzliches Risiko. Den DNS-Anfrage-Kontext an einen externen Dienst zu senden, kann Probleme für Datenresidenz und Anfragedatenschutz verursachen. Eine kritische Traffic-Entscheidungsschicht wie GTM von einer externen API abhängig zu machen, ist außerdem ein Schwachpunkt für den Betriebskontinuität.

Das richtige Modell unterstützt Client-Subnet-Informationen, trifft geografische Entscheidungen mit Offline-Datenbanken auf dem Gerät und erweitert Topologie-Regeln über die Landesebene hinaus auf Stadt, ASN und CIDR. Eine kontrollierte Endantwort über Fallback-Records bei fehlendem Match sollte Teil desselben Modells sein.

TR7 Geografisches DNS-Routing liefert genau das: EDNS Client Subnet, fünfdimensionale Topologie-Regeln, Offline-GeoIP-Datenbanken und selector-basierte Record-Auswahl bringen DNS-Antworten näher an den realen Benutzerkontext.

Unser Ansatz

TR7 setzt geografische DNS-Entscheidungen über Client-Subnet, mehrdimensionale Topologie, Offline-GeoIP und eine Lua-basierte Auswahlpipeline um.

EDNS Client Subnet nutzt das reale Client-Subnetz statt des Resolver-Standorts

Mit EDNS Client Subnet ist die DNS-Entscheidung nicht mehr nur an die Resolver-IP gebunden. Geografische Entscheidungen werden anhand des tatsächlichen Client-Subnetzes getroffen, was eine genauere DC- oder PoP-Auswahl ermöglicht.

Fünfdimensionale Topologie geht über länderbasierte Entscheidungen hinaus

TR7 kann Regeln über Netzwerk/CIDR, Land, Stadt, Kontinent und ASN definieren. Jede Regel kann mit normalem oder Negate-Verhalten formuliert werden.

Offline-GeoIP-Datenbanken halten den Query-Kontext auf dem Gerät

Geografische Entscheidungen werden über lokal auf dem Gerät gespeicherte ASN-, City- und Country-Datenbanken getroffen. Der DNS-Anfrage-Kontext wird niemals an einen externen GeoIP-Dienst gesendet.

Die Topologie-Pipeline wertet Regeln, Bedingungen und Records gemeinsam aus

TR7 wertet Topologie-Regeln in Reihenfolge aus und wählt passende Record-Kandidaten über Selector-Logik. Unterschiedliche Verteilungsstrategien lassen sich mit den Verhalten all, closest, Round Robin, weighted oder random aufbauen.

Funktionen

Geografisches DNS-Routing erzeugt länder-, stadt-, ASN- und CIDR-basierte DNS-Antworten mit Client-Subnet-Präzision.

EDNS Client Subnet ermöglicht Entscheidungen näher am realen Standort des Benutzers

TR7 kann Client-Subnet-Informationen einbeziehen, statt sich auf die Resolver-IP zu verlassen. Das reduziert das Risiko, dass Clients, die öffentliche Resolver verwenden, in die falsche Region geleitet werden. Geografische DNS-Entscheidungen rücken näher an das reale Benutzernetzwerk. Besonders bei Diensten mit globalem Benutzerverkehr ist das für eine präzise DC-Auswahl entscheidend.

Länderbasiertes Routing erfüllt Compliance- und Performance-Anforderungen

Die Länder-Granularität erlaubt unterschiedliche DNS-Antworten basierend auf dem Ländercode des Clients. Die DC-Auswahl lässt sich auf Europa, die Türkei, den Nahen Osten oder ein bestimmtes Land zuschneiden. Länderkontrolle ist wichtig für Finanzinstitute, öffentliche Einrichtungen und Umgebungen mit Datenresidenz-Anforderungen. Ländercodes werden für konsistenteres Matching normalisiert.

Kontinentbasiertes Routing ermöglicht breite regionale Verkehrsverteilung

Die Kontinent-Granularität lenkt Clients auf Kontinentebene zu unterschiedlichen Record-Gruppen. Separate PoP- oder DC-Sätze können für Europa, Asien, Nordamerika oder andere Regionen definiert werden. Dieser Ansatz bietet eine einfache Lösung, wenn Land-Detail nicht nötig ist, regionale Nähe aber zählt. Er ist nützlich in globalen SaaS- und Content-Delivery-Szenarien.

Stadtbasiertes Routing unterstützt lokale Kampagnen und PoP-Auswahl

Die Stadt-Granularität ordnet Benutzer aus bestimmten Städten verschiedenen Records zu. Separate Landing-Page-, Edge-PoP- oder Rechenzentrumsantworten können für Istanbul, Ankara oder andere Städte erzeugt werden. Das ist nützlich für lokale Kampagnen, Stadt-Compliance oder Low-Latency-Verkehrsverteilungsziele. Stadt-Informationen werden über die Offline-GeoIP-Datenbank ausgewertet.

CIDR-basierte Netzwerkregeln trennen private Netzwerke und Kundensegmente

Die Netzwerk-/CIDR-Granularität ermöglicht benutzerdefinierte DNS-Antworten für bestimmte IPv4- oder IPv6-Netzblöcke. Unternehmenskunden-Subnetze, Partnernetzwerke, private Carrier-Bereiche oder interne Zugangsblöcke lassen sich so trennen. CIDR-Routing ist deterministischer als Land oder Stadt. Es ist mächtig für kundenspezifische Endpunkte oder Peering-DC-Auswahl.

ASN-basiertes Routing verfeinert Carrier- und Peering-Entscheidungen

Die ASN-Granularität wählt eine DNS-Antwort basierend auf dem Carrier oder Netzwerkeigentümer, mit dem der Client verbunden ist. Separate DC-Records lassen sich für bestimmte Telekommunikations-Carrier, ISP-Netzwerke oder CDN-Peering-Präferenzen zurückgeben. Dieser Ansatz schafft Mehrwert dort, wo verschiedene Carrier im selben Land unterschiedliche Netzwerkqualität haben. Der Verkehr wird nach realer Netzwerktopologie statt einer Landesgrenze geroutet.

Das Negate-Flag ermöglicht ausschlussbasierte geografische Regeln

Das Negate-Verhalten kann auf jede Topologie-Regel angewendet werden. Damit lassen sich inverse Regeln wie "jedes Land außer diesem", "jedes ASN außer diesem" oder "jedes Netzwerk außer diesem CIDR" formulieren. Ausschlusslogik ist nützlich für Enforcement, Zugangs-Trennung, alternative IP-Auslieferung oder den Ausschluss hochriskanter Regionen. Operatoren können sowohl matchende als auch ausschließende Richtlinien aufbauen.

Fallback-Records erzeugen eine kontrollierte Antwort, wenn kein Match gefunden wird

Liefert die geografische Topologie-Regel keine Record-Kandidaten, können fallbackRecords aktiviert werden. Diese Records können ein Standard-DC, einen Wartungsdienst oder einen globalen Endpunkt repräsentieren. Fallback-Verhalten sichert eine kontrollierte Last-Resort-Antwort statt einer leeren oder unerwarteten DNS-Antwort. Besonders wichtig für neue Regionen oder fehlende GeoIP-Treffer.

Per-Record-Geo-Policy etabliert unterschiedliches Verhalten innerhalb derselben Domain

TR7 kann unabhängige Topologie-Richtlinien für jeden Record definieren. Unter derselben Domain können A-Records, AAAA-Records oder verschiedene Service-Records mit unterschiedlichen geografischen Entscheidungen arbeiten. Damit lassen sich unterschiedliche Routing-Strategien auf verschiedene Anwendungskomponenten unter einer einzigen Domain anwenden. Operatoren verwalten Topologie-Verhalten auf Record-Ebene statt global.

Selector-Optionen verteilen über passende Record-Kandidaten

Ein geografischer Match kann mehrere Record-Kandidaten erzeugen. TR7 kann dann über Selector-Verhalten wie all, closest, Round Robin, weighted Round Robin, Random oder weighted Random unter diesen Kandidaten auswählen. Geografische Filterung und Lastverteilung werden so in derselben Kette kombiniert. Beispielsweise lässt sich eine gewichtete Auswahl zwischen zwei DCs im selben Land anwenden.

Offline-GeoLite2-Datenbanken reduzieren das Datenresidenz-Risiko

ASN-, City- und Country-Datenbanken werden auf dem Gerät gespeichert und geografische Entscheidungen werden lokal getroffen. Der DNS-Anfrage-Kontext wird niemals an eine externe GeoIP-API gesendet. Das ist ein wichtiger Vorteil für Organisationen mit Erwartungen an Anfragedatenschutz und Datenresidenz. Der Update-Flow sollte separat geplant werden; das Verhalten der Seite stützt sich auf das Offline-Entscheidungsmodell.

TTL-Bewusstsein wird gemeinsam mit dem Geo-Cache-Verhalten geplant

Der TTL-Wert jedes DNS-Records beeinflusst das geografische Routing-Verhalten. Kürzere TTL bietet Vorteile bei schnellen Policy-Änderungen und Failover; längere TTL reduziert die Resolver-Cache-Last. Beim Entwurf des Geo-Routings sollten TTL, DC-Health und Verkehrsverteilungsziele gemeinsam geplant werden. Der Operator legt das Gleichgewicht zwischen Performance und Änderungsgeschwindigkeit fest.

Betriebliche Tiefe

Geografisches DNS-Routing wird zusammen mit Topologie-Regeltypen, normalisierten Feldern, CIDR-Rendering-Verhalten, Fallback-Logik und Lua-Ausführungslimits betrieben.

01

Topologie-Regeltypen

Die Topologie-Entscheidungspipeline verwendet die Regeltypen network, country, city, continent und ASN. Jeder Regeltyp kann mit positivem oder Negate-Verhalten ausgewertet werden. Diese Struktur erlaubt die Kombination mehrerer geografischer Entscheidungsdimensionen innerhalb desselben Records.

02

Normalisierung von Land und Kontinent

Länder- und Kontinentcodes werden vor dem Vergleich in Kleinbuchstaben umgewandelt. Das verhindert, dass Groß-/Kleinschreibungsunterschiede aus verschiedenen Quellen Matches brechen. Normalisierte Werte machen das Verfassen von Richtlinien konsistenter.

03

CIDR-Rendering-Verhalten

Netzwerk-Regeln werten IP und CIDR gemeinsam aus. Wird kein CIDR angegeben, kann für IPv4 ein Per-IP-Präzisionsverhalten genutzt werden. Dieses Modell erlaubt es, sowohl private Netzblöcke als auch einzelne IP-Ziele innerhalb derselben Richtlinienstruktur zu behandeln.

04

GeoIP-Datenbankabdeckung

TR7 kann geografische Entscheidungen über ASN-, City- und Country-Datenbanken treffen. Diese drei Datenquellen bilden die Grundlage für ASN-, Stadt-, Länder- und Kontinententscheidungen. Da die Datenbanken auf dem Gerät liegen, hängen Laufzeitentscheidungen nicht von einem externen Dienst ab.

05

Verhalten bei fehlendem Match

Liefert die Topologie-Auswertung keine Record-Kandidaten, werden fallbackRecords geprüft. Existiert ein Fallback, kann eine Endantwort mit failSafe-Status erzeugt werden. Ist kein Fallback definiert, kann ein leeres oder Standard-DNS-Verhalten eintreten — für alle Produktions-Records wird daher ein Fallback-Plan empfohlen.

06

Lua-Ausführungslimits

Die Topologie-Auswahl läuft über eine Lua-basierte Entscheidungspipeline. Ausführungslimits und Health-Check-Intervalle helfen, DNS-Entscheidungen deterministisch und kontrolliert zu halten. Die Performance-Auswirkungen sollten bei sehr komplexen Regelsätzen berücksichtigt werden.

Wann einsetzen

Carrier-basiertes Routing mit ASN-Trennung innerhalb der Türkei

Für verschiedene Carrier-Netzwerke in der Türkei lassen sich unterschiedliche Peering-DC-Records zurückgeben. Die ASN-Topologie-Regel hilft, Benutzer innerhalb desselben Landes auf einen genaueren Netzwerkpfad zu leiten.

Länderbasierte DC-Auswahl für europäische Finanzdienstleister

Für Länder wie Deutschland, Frankreich oder Italien lassen sich unterschiedliche Compliance- oder Datenresidenz-Ziele definieren. Die Länder-Regel liefert anhand des Landes des Clients den passenden DC-Record.

Kontinentbasiertes PoP-Routing für globale Verteilung

Globale Dienste können Clients auf Kontinentebene zu der passendsten PoP- oder Rechenzentrumsgruppe lenken. Kontinent-Regeln und Selector-Verhalten lassen sich für regionale Lastverteilung kombinieren.

Geografischer Ausschluss für alternative Antwortzustellung

Mit dem Negate-Flag lassen sich Clients außerhalb bestimmter Länder, ASNs oder CIDRs unterschiedliche Records zurückgeben. Dieses Modell ist nützlich für Enforcement, Lizenzierung, Compliance oder die Trennung hochriskanter Regionen.

Stadtbasiertes Kampagnen- und Landing-Page-Routing

Für Benutzer aus Städten wie Istanbul oder Ankara lässt sich eine eigene Landing-Page-IP zurückgeben. Die Stadt-Regel ermöglicht präzises DNS-Routing für Marketing- und lokale Service-Delivery-Szenarien.

Häufig gestellte Fragen

Wie funktioniert EDNS Client Subnet und warum ist es wichtig?
Im klassischen DNS basiert die Entscheidung auf der IP-Adresse des weiterleitenden Resolvers. Ist EDNS Client Subnet (RFC 7871) aktiv, hängt der Resolver das reale Client-Subnetz an die Anfrage an. TR7 nutzt diese Information, um die Entscheidung am tatsächlichen Netzwerkstandort des Benutzers statt an der Position des Resolvers auszurichten. Das reduziert das Risiko, dass Benutzer, die öffentliche Resolver nutzen, ins falsche DC geleitet werden.
Für welche geografischen Dimensionen lassen sich Topologie-Regeln definieren?
TR7 unterstützt Topologie-Regeln über fünf Dimensionen: Netzwerk/CIDR, Land, Stadt, Kontinent und ASN. Jede Regel kann mit positivem oder Negate-Verhalten arbeiten. Mehrere Dimensionen lassen sich innerhalb desselben Records kombinieren — z. B. kann der gesamte Türkei-Traffic außer einem bestimmten ASN unter derselben Regel platziert werden.
Hängt die GeoIP-Entscheidung von einem externen Dienst ab?
Nein. TR7 hält ASN-, City- und Country-Datenbanken offline auf dem Gerät. Geografische Entscheidungen werden anhand dieser lokalen Datenbanken getroffen; der DNS-Anfrage-Kontext wird niemals an eine externe GeoIP-API gesendet. Dieser Ansatz erfüllt sowohl Datenresidenz-Anforderungen als auch eliminiert externe Abhängigkeiten.
Wann und wie aktivieren sich Fallback-Records?
Liefert die Topologie-Auswertung keine Record-Kandidaten, aktiviert sich fallbackRecords und es wird eine Antwort mit failSafe-Status erzeugt. Ist kein Fallback definiert, kann ein leeres oder Standard-DNS-Verhalten eintreten. Für Produktionsumgebungen wird empfohlen, für alle Records einen Fallback zu definieren — besonders kritisch bei neuen Regionen oder fehlenden GeoIP-Treffern.
Wie arbeiten Selector-Verhalten mit geografischem Routing zusammen?
Ein geografischer Match kann mehrere Record-Kandidaten zurückgeben. Der Selector bestimmt, wie unter ihnen ausgewählt wird: all gibt alle Kandidaten zurück, closest wählt den nächsten, Round Robin und weighted Round Robin liefern zyklische Verteilung, Random und weighted Random sorgen für stochastische Auswahl. Geografische Filterung und Lastverteilung werden so in derselben Pipeline kombiniert.
In welchen Szenarien wird das Negate-Flag verwendet?
Das Negate-Flag wird verwendet, um die Umkehrung einer geografischen Bedingung als Regel zu definieren. Beispielsweise werden "diese IP an alle Benutzer außer diesem Land senden" oder "dieses DC für alle Clients außer diesem ASN verwenden" mit Negate geschrieben. Es schafft Mehrwert bei Enforcement, Lizenzeinschränkung, Ausschluss hochriskanter Regionen oder alternativen Record-Szenarien.

Binden Sie DNS-Entscheidungen an den realen Standort des Benutzers

Geografisches DNS-Routing mit EDNS Client Subnet, fünfdimensionalen Topologie-Regeln und Offline-GeoIP. Gehen wir gemeinsam ein Live-Setup auf Ihrer eigenen Infrastruktur durch.