De nombreuses organisations s'appuient sur des services DNS et GSLB externes pour le routage global du trafic. Le modèle paraît pratique, mais le contenu des zones, les logs de requêtes, les décisions géo et les politiques de routage du trafic sont tous détenus sur une plateforme à l'extérieur de l'organisation. Pour la finance, le gouvernement, la santé et les environnements sensibles à la réglementation, cela soulève de sérieuses questions de souveraineté des données.
Externaliser la couche de décision GSLB introduit aussi un risque de continuité opérationnelle. Une panne, un incident de configuration ou un problème d'accès API chez le fournisseur externe affecte directement la politique de failover DC et de réponse DNS de l'organisation. Vos applications peuvent être up, mais le trafic peut ne pas atteindre le bon DC.
Une déconnexion distincte émerge quand le DNS faisant autorité et le health checking sont des produits différents. Le système de health-check voit qu'un DC est malsain, mais si le système DNS ne le reflète pas automatiquement, un script, un runbook manuel ou une automatisation séparée doit faire le pont. Pendant un incident, ce pont devient le maillon le plus faible.
La bonne approche consiste à consolider le DNS faisant autorité, les scénarios de health-check, le failover DC et les décisions de routage topologique sur la même plateforme locale. Les réponses DNS doivent être régénérées sur l'appliance à partir de la santé réelle des DC et de la politique de trafic ; les données de requête et le contenu de zone doivent rester sous contrôle organisationnel.
TR7 On-Prem GSLB livre ce modèle : le DNS faisant autorité et le moteur de décision GSLB s'exécutent sur la même plateforme, fournissant failover DC et routage géographique sans que les données ne quittent les locaux.
TR7 construit l'architecture GSLB on-prem autour du DNS faisant autorité, d'un modèle de décision sans cloud, de scénarios de santé et d'une chaîne de priorité multi-DC.
TR7 ne sépare pas la gestion de zone et les décisions GSLB sur des systèmes distincts. Les enregistrements DNS, la santé des DC, les règles de topologie et la génération de réponse opèrent tous au sein du même modèle de gestion.
Les bases GeoIP tournent localement et le contexte des requêtes DNS n'est jamais envoyé à un service externe pour la prise de décision. Cette approche fournit un avantage significatif aux organisations avec des exigences de résidence et de souveraineté des données.
Quand un DC ou un enregistrement devient malsain, les IPs correspondantes peuvent être retirées automatiquement des réponses DNS. Il n'y a pas besoin d'un pont par script manuel entre les résultats des health-checks et les réponses DNS.
Chaque enregistrement peut porter plusieurs entrées DC et les évaluer dans l'ordre de priorité. Les chaînes primaires, secondaires, tertiaires ou DR sont gérées au sein d'un modèle d'enregistrement unique.
On-Prem GSLB livre la gestion des enregistrements DNS conjointement avec la santé des DC, le routage topologique, DNSSEC et les statistiques locales.
TR7 utilise la couche DNS faisant autorité avec une base de données d'enregistrements et une logique de décision tournant localement. Les données de zone restent sur site et les réponses DNS sont produites par la plateforme locale. Cela réduit la dépendance aux services DNS externes. L'organisation opère sa politique GSLB sur ses propres appliances.
TR7 supporte un large ensemble d'enregistrements DNS dont A, AAAA, CNAME, MX, TXT, SOA, NS, SRV, PTR, CAA, des enregistrements liés à DNSSEC et d'autres types avancés. Cela fournit la flexibilité nécessaire à la gestion complète de zone, pas seulement au pilotage simple par enregistrement A. Différentes exigences de service et de sécurité peuvent être amenées sous le même modèle de gestion DNS. L'organisation gère son architecture DNS plus uniformément depuis un seul point.
TR7 peut utiliser l'information EDNS Client Subnet pour éviter de prendre les décisions géographiques uniquement à partir de l'IP du résolveur. La sélection de DC ou d'enregistrement peut être basée sur le subnet client réel. Cela réduit le risque que les utilisateurs sur des résolveurs publics soient dirigés vers la mauvaise région. Une distribution de trafic plus précise est obtenue dans les scénarios d'accès mondial.
Les règles de topologie TR7 peuvent sélectionner les réponses DNS à travers les dimensions réseau/CIDR, pays, ville, continent et ASN. Chaque règle peut être écrite comme une condition positive ou négative. Le même domaine peut donc renvoyer des listes d'IP différentes dans différents contextes géographiques ou réseau. Le routage géo devient plus précis qu'une simple division par pays.
Chaque enregistrement peut être géré avec une structure recordConfig qui porte l'ordre des DC. Quand le DC primaire est malsain, les enregistrements de DC secondaire ou tertiaire peuvent être activés. Ce modèle permet de construire une chaîne de priorité multi-DC au sein d'un seul enregistrement. Les opérateurs peuvent appliquer différentes stratégies de continuité par domaine ou par enregistrement.
Le mode noResponse garde un DC passif silencieux dans des conditions normales. Le mode onlyNew peut empêcher un DC qui a été down pendant une période prolongée de servir des réponses basées sur des données obsolètes. Ce comportement cible uniquement les DC dans le bon état — pas seulement ceux qui sont techniquement up. La cohérence des données est préservée pendant le failover et le failback.
TR7 peut faire tourner un processus de forwarder récursif aux côtés du DNS faisant autorité. Les zones internes sont dirigées vers la couche faisant autorité locale tandis que la résolution des domaines externes est gérée via le forwarder. domainBasedForwarding peut router des domaines spécifiques vers différents chemins de résolution. Cela aide à consolider le DNS interne et les décisions GSLB au sein de la même famille d'appliances.
TR7 peut offrir la gestion de zone signée avec le support DNSSEC. NSEC/NSEC3, cache de clés DNSSEC et processus de signature de zone augmentent la vérifiabilité des réponses DNS. DNSSEC peut être activé ou désactivé par domaine. Cela renforce la sécurité d'intégrité des domaines critiques.
TR7 peut supporter le comportement de transfert de zone à la fois dans les rôles DNS primaire et secondaire. AXFR et IXFR permettent aux enregistrements d'être portés entre différents nœuds DNS. Cela simplifie l'intégration avec l'architecture DNS d'entreprise existante. Déployer GSLB on-prem ne nécessite pas d'abandonner complètement le modèle d'opération DNS existant.
Le mode maintenance peut être appliqué par DC. Pendant la maintenance planifiée, un DC peut être retiré des réponses DNS même s'il est sain, et le trafic est dirigé vers un autre DC. Quand la maintenance est terminée, le scénario de santé normal reprend. Ce modèle fournit un basculement contrôlé sans changements manuels de zone.
TR7 peut supporter le comportement de DNS update dynamique, permettant aux enregistrements d'être mis à jour par des systèmes d'automatisation. Cette capacité est précieuse pour l'infrastructure variable, la publication de service automatisée ou les besoins d'enregistrements temporaires. Les mises à jour d'enregistrement peuvent être évaluées aux côtés du modèle de décision GTM. Les équipes d'exploitation peuvent réduire les tâches DNS manuelles.
TR7 peut collecter des statistiques telles que requêtes DNS, cache, rcode, qtype, latence, mémoire et uptime. Les comptes de requêtes par enregistrement révèlent quel enregistrement reçoit combien de requêtes. Ces données sont disponibles pour le reporting local et la planification de capacité sans passer par une plateforme de fournisseur externe. Le DNS devient une couche de trafic mesurable, pas seulement un générateur de réponses.
L'opération GSLB on-prem couvre la séparation des ports, le comportement du TTL de cache, le threading, les défauts SOA, la collecte de statistiques, la persistance des fichiers d'état et l'élection du maître.
Les composants TR7 GTM peuvent utiliser des plages de ports séparées pour les processus DNS faisant autorité, API, forwarder inner et forwarder API. Cette séparation facilite la surveillance et la gestion de chaque service indépendamment. Les équipes d'exploitation peuvent suivre l'accès et l'état de santé de chaque composant individuellement.
Les intervalles de rafraîchissement du cache de requête, du cache de requête négative, du cache de clés DNSSEC et du cache de zone peuvent tous être dérivés de la valeur principale cacheTtl. Cette structure équilibre la performance avec la fraîcheur. Des TTL plus courts permettent une propagation plus rapide des changements ; des TTL plus longs réduisent la charge de requêtes.
Les processus de signature, distributeur, récepteur et récupération peuvent s'étendre selon le nombre de cœurs CPU. Cette approche augmente la capacité de traitement parallèle sous trafic DNS lourd. Les paramètres de threading doivent être planifiés selon la capacité matérielle et le profil de requête.
La structure SOA par défaut pour les nouvelles zones peut être créée avec des valeurs refresh, retry, expire et TTL. Ces valeurs déterminent le comportement de timing fondamental de l'opération DNS. Les valeurs SOA doivent être révisées séparément selon les exigences organisationnelles.
Les statistiques DNS peuvent être lues via API et alimentées dans des structures RRD ou similaires de séries temporelles. Des métriques telles que qtype, rcode, cache hit/miss, requêtes UDP/TCP, latence et utilisation mémoire sont suivies. Ces données sont utilisées pour la planification de capacité et l'investigation d'incidents.
Les informations DC, l'état de santé local, l'état de scénario, la config dynamique et la config dynamique de zone peuvent être stockés au niveau du fichier. Après un redémarrage, GTM peut restaurer son contexte d'évaluation précédent. Cela réduit la fluctuation DNS inutile pendant les redémarrages de service passagers.
Les institutions financières peuvent construire une chaîne DC primaire, secondaire et tertiaire. Les scénarios de health-check Internet et accès retirent un DC malsain des réponses DNS et redirigent le trafic vers le DC de secours.
Les organisations gouvernementales peuvent faire tourner GTM sans envoyer le contenu de zone, les logs de requêtes ou les données de décision géo à des services DNS externes. Le GSLB on-prem supporte la souveraineté des données et les attentes d'audit.
Les systèmes d'information hospitaliers et les services de santé critiques peuvent être surveillés avec des scénarios de health-check. Les endpoints malsains sont retirés automatiquement des réponses DNS, réduisant le besoin d'intervention manuelle.
Les équipes télécom peuvent sélectionner différents DC ou emplacements PoP via des règles de topologie géographiques et basées sur le réseau. Le subnet client, le pays, l'ASN ou l'information CIDR sont inclus dans les décisions de réponse DNS.
Les équipes e-commerce peuvent utiliser le comportement d'enregistrement pondéré pour diriger une petite part de trafic vers un nouveau groupe d'IP. À mesure que les tests réussissent, le poids est augmenté jusqu'à ce que la transition se termine de manière contrôlée.
Les nœuds GTM peuvent opérer dans les rôles master et standby au sein d'un cluster HA. Si le nœud master échoue, le standby prend le rôle et maintient la génération continue de réponses DNS.
DNS faisant autorité, failover DC, routage géographique et scénarios de health-check — tous s'exécutant sur les propres appliances de l'organisation. Parcourons un déploiement qui correspond à votre infrastructure.