Dans les solutions DNS géographiques classiques, les décisions sont généralement prises à partir de l'adresse IP du résolveur DNS. Quand un utilisateur s'appuie sur un résolveur public distant, cependant, le système DNS voit la localisation du résolveur plutôt que la position réelle de l'utilisateur. Par conséquent, un utilisateur en Turquie peut être dirigé vers un centre de données dans la mauvaise région ou un PoP inutilement distant.
Le routage à une couche, basé uniquement sur le pays, est également insuffisant pour la plupart des scénarios d'entreprise. Au sein du même pays, différents opérateurs, différents ASN, différentes villes ou différents blocs réseau privés peuvent chacun nécessiter un routage séparé. Les besoins tels que le peering télécom, la conformité, la latence, la sélection de PoP de type CDN et le routage de campagne exigent tous une granularité plus fine.
Utiliser une API GeoIP en ligne pour les décisions géographiques introduit un risque supplémentaire. Envoyer le contexte de la requête DNS à un service externe peut créer des problèmes de résidence des données et de confidentialité des requêtes. Faire dépendre une couche de décision de trafic critique comme GTM d'une API externe est également un point faible pour la continuité opérationnelle.
Le bon modèle consiste à supporter l'information de subnet client, à prendre les décisions géographiques à partir de bases hors-ligne sur l'appareil et à étendre les règles de topologie au-delà du niveau pays pour inclure ville, ASN et CIDR. Produire une réponse finale contrôlée via des enregistrements de fallback quand aucune correspondance n'est trouvée doit faire partie du même modèle.
TR7 DNS Geographic Routing livre exactement cela : EDNS Client Subnet, règles de topologie à cinq dimensions, bases GeoIP hors-ligne et sélection d'enregistrements basée sur des sélecteurs rapprochent les réponses DNS du contexte réel de l'utilisateur.
TR7 implémente les décisions DNS géographiques via le subnet client, la topologie multi-dimensionnelle, le GeoIP hors-ligne et un pipeline de sélection basé sur Lua.
Avec le support EDNS Client Subnet, la décision DNS n'est plus liée uniquement à l'IP du résolveur. Les décisions géographiques sont prises à partir du subnet client réel, permettant une sélection plus précise du DC ou du PoP.
TR7 peut définir des règles à travers réseau/CIDR, pays, ville, continent et ASN. Chaque règle peut être écrite avec un comportement normal ou negate.
Les décisions géographiques sont prises à partir des bases ASN, City et Country stockées localement sur l'appareil. Le contexte de la requête DNS n'est jamais envoyé à un service GeoIP externe.
TR7 évalue les règles de topologie dans l'ordre et sélectionne les candidats d'enregistrements correspondants en utilisant une logique de sélecteur. Différentes stratégies de distribution peuvent être construites avec un comportement all, closest, round-robin, pondéré ou aléatoire.
DNS Geographic Routing produit des réponses DNS basées sur pays, ville, ASN et CIDR avec la précision du subnet client.
TR7 peut prendre en compte l'information de subnet client au lieu de s'appuyer sur l'IP du résolveur. Cela réduit le risque que les clients utilisant des résolveurs publics soient dirigés vers la mauvaise région. Les décisions DNS géographiques se rapprochent du réseau utilisateur réel. C'est particulièrement critique pour une sélection précise de DC dans les services à trafic utilisateur mondial.
La granularité par pays permet de produire différentes réponses DNS selon le code pays du client. La sélection du centre de données peut être adaptée à l'Europe, la Turquie, le Moyen-Orient ou un pays spécifique. Le contrôle au niveau pays est important pour les institutions financières, les organisations du secteur public et les environnements avec exigences de résidence des données. Les codes pays sont normalisés pour une correspondance plus cohérente.
La granularité par continent permet de diriger les clients vers différents groupes d'enregistrements au niveau du continent. Des ensembles PoP ou DC distincts peuvent être définis pour l'Europe, l'Asie, l'Amérique du Nord ou d'autres régions. Cette approche offre une solution simple lorsque le détail au niveau pays n'est pas requis mais que la proximité régionale importe. C'est utile dans les scénarios SaaS mondiaux et de diffusion de contenu.
La granularité par ville fait correspondre les utilisateurs de villes spécifiques à différents enregistrements. Des réponses de landing page, edge PoP ou centre de données distinctes peuvent être produites pour Istanbul, Ankara ou d'autres villes. C'est utile pour les campagnes locales, la conformité au niveau ville ou les objectifs de distribution de trafic à faible latence. L'information de ville est évaluée à partir de la base GeoIP hors-ligne.
La granularité réseau/CIDR permet de définir des réponses DNS personnalisées pour des blocs réseau IPv4 ou IPv6 spécifiques. Les subnets de clients entreprise, les réseaux partenaires, les plages d'opérateurs privés ou les blocs d'accès internes peuvent être séparés ainsi. Le routage au niveau CIDR est plus déterministe que celui par pays ou ville. Il est puissant pour les endpoints par client ou la sélection de DC de peering.
La granularité ASN sélectionne une réponse DNS selon l'opérateur ou le propriétaire du réseau auquel le client est connecté. Des enregistrements DC distincts peuvent être renvoyés pour des opérateurs télécom spécifiques, des réseaux FAI ou des préférences de peering CDN. Cette approche crée de la valeur là où différents opérateurs au sein du même pays ont une qualité de réseau différente. Le trafic est routé selon la topologie réseau réelle plutôt qu'une frontière nationale.
Le comportement negate peut être appliqué à toute règle de topologie. Cela permet des règles inverses telles que « tous les pays sauf celui-ci », « tous les ASN sauf celui-ci » ou « tous les réseaux sauf ce CIDR ». La logique d'exclusion est utile pour l'enforcement, la séparation d'accès, la diffusion d'IP alternative ou les scénarios d'exclusion de régions à risque élevé. Les opérateurs peuvent construire des politiques de correspondance et d'exclusion.
Si la règle de topologie géographique ne produit aucun candidat d'enregistrement, fallbackRecords peut être activé. Ces enregistrements peuvent représenter un DC par défaut, un service de maintenance ou un endpoint global. Le comportement de fallback garantit une réponse de dernier recours contrôlée au lieu d'une réponse DNS vide ou inattendue. C'est particulièrement important pour les nouvelles régions ou les correspondances GeoIP manquantes.
TR7 peut définir des politiques de topologie indépendantes pour chaque enregistrement. Sous le même domaine, les enregistrements A, AAAA ou différents enregistrements de service peuvent opérer avec différentes décisions géographiques. Cela permet d'appliquer différentes stratégies de routage à différents composants applicatifs sous un seul domaine. Les opérateurs gèrent le comportement topologique au niveau de l'enregistrement plutôt que globalement.
Une correspondance géographique peut produire plusieurs candidats d'enregistrement. TR7 peut alors sélectionner parmi ces candidats en utilisant des comportements de sélecteur tels que all, closest, round-robin, round-robin pondéré, aléatoire ou aléatoire pondéré. Le filtrage géographique et la distribution de charge sont ainsi combinés dans la même chaîne. Par exemple, une sélection pondérée peut être appliquée entre deux DC au sein du même pays.
Les bases ASN, City et Country sont stockées sur l'appareil et les décisions géographiques sont prises localement. Le contexte de la requête DNS n'est jamais envoyé à une API GeoIP externe. C'est un avantage important pour les organisations avec des attentes de confidentialité des requêtes et de résidence des données. Le flux de mise à jour doit être planifié séparément ; le comportement de la page repose sur le modèle de décision hors-ligne.
La valeur TTL pour chaque enregistrement DNS affecte le comportement de routage géographique. Un TTL plus court offre des avantages pour les changements de politique rapides et le failover ; un TTL plus long réduit la charge du cache résolveur. Lors de la conception du routage géo, TTL, santé DC et objectifs de distribution du trafic doivent être planifiés ensemble. L'opérateur définit l'équilibre entre performance et vitesse de changement.
Le routage DNS géographique est exploité aux côtés des types de règles de topologie, des champs normalisés, du comportement de rendu CIDR, de la logique de fallback et des limites d'exécution Lua.
Le pipeline de décision topologique utilise les types de règles network, country, city, continent et ASN. Chaque type de règle peut être évalué avec un comportement positif ou negate. Cette structure permet de combiner plusieurs dimensions de décision géographique au sein du même enregistrement.
Les codes pays et continent sont mis en minuscules avant comparaison. Cela empêche les différences de casse provenant de sources diverses de casser les correspondances. Les valeurs normalisées rendent l'écriture de politiques plus cohérente.
Les règles réseau évaluent IP et CIDR ensemble. Si aucun CIDR n'est spécifié, un comportement de précision par IP peut être utilisé pour IPv4. Ce modèle permet aux blocs réseau privés et aux cibles IP uniques d'être gérés au sein de la même structure de politique.
TR7 peut prendre des décisions géographiques en utilisant les bases ASN, City et Country. Ces trois sources de données forment la fondation des décisions ASN, ville, pays et continent. Comme les bases résident sur l'appareil, les décisions à l'exécution ne dépendent pas d'un service externe.
Si l'évaluation topologique ne produit aucun candidat d'enregistrement, fallbackRecords est vérifié. Si un fallback existe, une réponse finale peut être produite avec le statut failSafe. Si aucun fallback n'est défini, un comportement DNS vide ou standard peut se produire — un plan de fallback est donc recommandé pour tous les enregistrements en production.
La sélection topologique passe par un pipeline de décision basé sur Lua. Les limites d'exécution et les intervalles de health-check aident à garder les décisions DNS déterministes et contrôlées. L'impact de performance doit être considéré pour des ensembles de règles très complexes.
Différents enregistrements DC de peering peuvent être renvoyés pour différents réseaux d'opérateur en Turquie. La règle de topologie ASN aide à diriger les utilisateurs au sein du même pays vers un chemin réseau plus précis.
Différentes cibles de conformité ou résidence des données peuvent être définies pour des pays tels que l'Allemagne, la France ou l'Italie. La règle de pays renvoie l'enregistrement DC approprié selon le pays du client.
Les services mondiaux peuvent diriger les clients vers le groupe PoP ou centre de données le plus approprié au niveau du continent. Les règles de continent et le comportement de sélecteur peuvent être combinés pour la distribution de charge régionale.
Avec le flag negate, différents enregistrements peuvent être renvoyés aux clients hors de pays, ASN ou CIDR spécifiques. Ce modèle est utile pour l'enforcement, le licensing, la conformité ou la séparation de régions à risque élevé.
Une IP de landing page personnalisée peut être renvoyée aux utilisateurs de villes telles qu'Istanbul ou Ankara. La règle de ville fournit un routage DNS précis pour les scénarios marketing et de diffusion de service local.
Routage DNS géographique avec EDNS Client Subnet, règles de topologie à cinq dimensions et GeoIP hors-ligne. Parcourons un déploiement en direct sur votre propre infrastructure.