La plupart des solutions GSLB se concentrent sur les enregistrements A, AAAA et CNAME pour un routage de trafic de base. Cela peut suffire pour un pilotage applicatif simple, mais les opérations DNS d'entreprise réelles couvrent une surface beaucoup plus large : MX, TXT, SRV, PTR, CAA, TLSA, enregistrements DNSSEC, zones inverses, mises à jour DNS dynamiques et transferts de zone.
Quand cette couverture manque, l'organisation doit faire fonctionner deux couches DNS distinctes. Une interface pour GSLB, un autre serveur faisant autorité pour les enregistrements DNS avancés, des opérations CLI distinctes pour DNSSEC, des transferts manuels pour l'import de zone et des scripts supplémentaires pour la migration. Le résultat est une propriété fragmentée sur le même domaine et un risque opérationnel accru.
La gestion DNSSEC est l'un des points les plus sensibles de cette fragmentation. Une zone signée nécessite la génération et la publication correctes des enregistrements DNSKEY, DS, RRSIG, NSEC et NSEC3. Laisser cela entièrement à des commandes CLI ou à l'édition manuelle de fichiers augmente le risque d'erreur.
La migration de zone et les architectures multi-autoritaires créent des problèmes similaires. Récupérer les enregistrements d'une source DNS legacy, gérer les enregistrements conflictuels, définir correctement le comportement du serial SOA et fournir les transferts de zone aux serveurs secondaires nécessitent tous une politique cohérente. Les workflows de copie manuelle de fichiers de zone et de rechargement sont insuffisants pour les opérations GSLB modernes.
TR7 DNS Record Management fait de la gestion DNS complète une partie native de la plateforme GTM à travers 35 types d'enregistrements, DNSSEC, AXFR primary/secondary, DNS UPDATE, modes d'édition SOA et politiques de collision smart AXFR.
TR7 traite la gestion DNS non comme un écran de saisie d'enregistrements, mais comme une couche d'opérations qui unifie la capacité DNS faisant autorité avec le moteur de décision GSLB.
TR7 combine les capacités DNS faisant autorité avec une API REST et une interface de gestion. Les opérateurs gèrent les types d'enregistrements, les paramètres de zone, les valeurs TTL et les comportements GTM depuis une seule interface.
Le support DNSSEC peut être activé au niveau du domaine. Les types d'enregistrements DNSKEY, DS, RRSIG, NSEC, NSEC3 et apparentés sont traités comme faisant partie du modèle de gestion DNS.
TR7 peut agir comme primary et servir les transferts de zone aux serveurs secondaires, ou opérer comme secondary et tirer les zones depuis une source externe faisant autorité via AXFR. Ce modèle est utilisé pour la migration, la redondance et les architectures DNS distribuées.
Quand les enregistrements arrivant via AXFR sont en conflit avec des enregistrements existants, l'opérateur peut sélectionner le comportement useNew, preserveCurrent ou combine. La migration de zone et la consolidation multi-source ne deviennent donc jamais un écrasement aveugle.
DNS Record Management consolide la couverture des enregistrements DNS classiques, DNSSEC, le transfert de zone, les mises à jour dynamiques et les comportements d'enregistrement GTM dans un seul modèle.
TR7 couvre A, AAAA, CNAME, MX, TXT, SOA, NS, SRV, PTR, CAA, DNSKEY, DS, RRSIG, NSEC, NSEC3, NSEC3PARAM, ALIAS, AFSDB, CERT, CDNSKEY, CDS, DNAME, HINFO, KEY, LOC, LUA, NAPTR, OPENPGPKEY, RP, SMIMEA, SPF, SSHFP, TLSA, TKEY, TSIG et URI. Cette ampleur compte pour les opérations DNS complètes au-delà des enregistrements GSLB. Les besoins de messagerie, sécurité de certificat, découverte de service, DNS inverse et DNSSEC peuvent tous être servis sur la même plateforme, sans outil DNS séparé.
DNSSEC peut être activé au niveau du domaine. Les types d'enregistrements NSEC, NSEC3, NSEC3PARAM, RRSIG, DNSKEY, DS, CDS et CDNSKEY sont supportés dans le cadre des opérations DNSSEC. Cela augmente la vérifiabilité de la zone et ajoute une couche de sécurité contre les risques de spoofing DNS. Les opérateurs n'ont plus besoin de traiter DNSSEC comme un processus manuel séparé hors de la gestion d'enregistrements GSLB.
En mode primary, TR7 peut agir comme source de zone faisant autorité et servir les transferts de zone aux serveurs secondaires. Le comportement de transfert de zone complet et incrémental peut être utilisé selon l'architecture DNS. C'est requis pour les déploiements haute disponibilité et multi-serveurs DNS. Gérer la zone depuis un point unique et la propager aux autres serveurs assure la cohérence opérationnelle.
En mode secondary, TR7 peut recevoir une zone depuis une autre source faisant autorité via AXFR. Ce modèle est utile pour la migration, la gestion express ou la transition vers la couche TR7 GTM sans perturber l'infrastructure DNS existante. Alors que les enregistrements sont tirés d'une source externe, la gestion et l'intégration du moteur de décision peuvent être établies du côté TR7. Une migration graduelle est possible sans abandonner d'un coup les investissements DNS existants.
DNS NOTIFY permet aux parties secondaires d'apprendre le besoin d'une mise à jour après un changement de zone. TR7 peut évaluer les statistiques de notification entrante dans son périmètre de monitoring. Cette visibilité est importante pour comprendre si le comportement de transfert de zone fonctionne réellement. Dans les grandes architectures DNS, les délais de transfert et les chaînes de mise à jour sont plus faciles à suivre.
DNS UPDATE permet aux composants d'application ou d'infrastructure de mettre à jour les enregistrements DNS de manière programmatique. Par exemple, un serveur applicatif peut publier dynamiquement son propre enregistrement A. Ce comportement est précieux dans les scénarios d'automatisation et d'infrastructure élastique. Les permissions de mise à jour dynamique doivent être soigneusement restreintes et planifiées aux côtés d'une politique de sécurité.
Le mode DEFAULT peut utiliser une approche de serial basée sur la date ; le mode EPOCH cible le temps Unix, le mode INCREASE cible l'incrément +1 et le mode OFF désactive l'ajustement automatique. Le comportement du serial SOA est critique pour la chaîne de transfert primary/secondary. Une gestion incorrecte du serial peut faire manquer des changements aux serveurs secondaires. TR7 rend ce comportement configurable comme paramètre du domaine.
Le TTL est géré par enregistrement via recordObj.ttl ; le défaut est 3600 secondes. Un TTL faible sur les enregistrements GTM critiques permet une bascule et un failover rapides, tandis que les enregistrements plus statiques peuvent utiliser un TTL élevé pour l'efficacité du cache. Le TTL est le compromis fondamental entre performance et taux de changement dans les opérations DNS. TR7 présente cette valeur comme une partie naturelle de la gestion d'enregistrement.
En mode local TR7 possède la zone et les enregistrements deviennent entièrement éditables. En mode express, les enregistrements sont tirés depuis une source DNS externe via AXFR, permettant un modèle pass-through ou de transition graduelle. Cette distinction compte pour les organisations qui ne peuvent pas migrer toute leur infrastructure DNS en une seule étape. Le processus de migration devient plus contrôlé et réversible.
Lors de l'import AXFR, les enregistrements entrants peuvent être en conflit avec ceux existants. Le mode useNew promeut le nouvel enregistrement, preserveCurrent conserve l'existant et combine fusionne les deux. Ces options réduisent le risque de perte de données ou d'écrasements inattendus pendant la migration. L'opérateur peut choisir la bonne stratégie de collision pour chaque processus d'import de zone.
La validation de domaine et sous-domaine garantit que les enregistrements sont définis sous la bonne zone. Les adresses IPv4 et IPv6 sont normalisées sous forme canonique. Le comportement du point final est aligné avec le standard DNS. Ces contrôles réduisent les erreurs typographiques et de format couramment observées dans la saisie manuelle d'enregistrement.
Les champs de métadonnées de domaine peuvent porter des informations supplémentaires pour le comportement de zone ou les intégrations avec systèmes externes. L'accès à l'API REST peut être géré par instance DNS avec une clé API. Cette structure compte pour l'automatisation, l'intégration et les opérations DNS multi-instances. La gestion d'enregistrement n'est pas limitée à l'UI — elle est aussi ouverte aux processus pilotés par API.
La gestion des enregistrements DNS fonctionne conjointement avec la standardisation des domaines, la normalisation IP, le comportement AXFR, les plages de ports, le cache et la gestion du serial SOA.
Le contrôle de sous-domaine vérifie qu'un enregistrement saisi appartient bien à la zone concernée. Le point final et la correspondance de domaine sont tous deux pris en compte. Ce comportement réduit le risque de saisie d'enregistrement sous la mauvaise zone.
Les chaînes de domaine DNS sont gérées avec un point final sous forme canonique. Un point final manquant peut être complété automatiquement. Cela garde le comportement de nom de domaine absolu cohérent.
Les enregistrements A sont normalisés en utilisant la logique correctForm IPv4, les enregistrements AAAA en utilisant la logique correctForm IPv6. Cela empêche différentes notations de la même IP de créer du bruit dans l'inventaire d'enregistrements. La normalisation simplifie les opérations d'audit et de comparaison.
Dans les opérations de sync AXFR, les types d'enregistrements autres que SOA peuvent être inclus dans le périmètre de synchronisation. SOA porte un comportement de serial et d'autorité distinct et est traité spécialement. Cette distinction augmente le contrôle sur les transferts de zone.
Les options useNew, preserveCurrent et combine déterminent comment les enregistrements conflictuels sont gérés pendant l'import. useNew favorise les données entrantes, preserveCurrent favorise les données existantes et combine vise à conserver les deux enregistrements. Le bon comportement doit être sélectionné selon le plan de migration.
Les plages de ports inner, API, forwarder inner et forwarder API pour les instances DNS peuvent être planifiées séparément. Cette séparation réduit les conflits de ports dans les architectures multi-instances et forwarder. L'équipe d'exploitation peut placer les services DNS de manière plus organisée.
Le TTL de cache de requête, le TTL de cache de requête négative et les valeurs d'entrées de cache maximum peuvent être gérés au niveau instance. Le cache a un effet direct sur le temps de réponse DNS et la charge sur le backend faisant autorité. Les enregistrements GTM nécessitant un TTL faible doivent être planifiés conjointement avec le comportement de cache global.
Le mode d'édition SOA détermine comment la valeur de serial change sur les écritures primary. Un paramètre distinct peut être utilisé pour le comportement de serial inférieur côté secondary. Une gestion correcte du serial est la fondation du transfert de zone continu.
Une organisation peut activer DNSSEC pour ses domaines et amener la chaîne DNSKEY, DS, RRSIG et NSEC/NSEC3 sous gestion. La zone devient vérifiable. La sécurité DNS est gérée à l'intérieur de la gestion DNS TR7 sans être fragmentée à travers des opérations CLI manuelles.
La zone est tirée via AXFR depuis la source legacy faisant autorité et les enregistrements sont examinés côté TR7. En cas de conflit, une politique useNew, preserveCurrent ou combine est appliquée. L'organisation peut migrer de manière contrôlée sans déplacer tout le DNS en une seule étape.
Les enregistrements de zone détenus dans plusieurs DC peuvent être collectés via le processus smart AXFR. Les enregistrements conflictuels sont fusionnés ou préservés selon la politique choisie. C'est utilisé pour centraliser un inventaire DNS fragmenté.
Un serveur applicatif ou système d'automatisation peut mettre à jour son propre enregistrement via DNS UPDATE. Dans les infrastructures élastiques, un enregistrement DNS peut être automatiquement créé quand un nouveau nœud entre en ligne. Les permissions de mise à jour doivent être restreintes à travers une politique de sécurité.
Les structures de zone inverse in-addr.arpa ou IPv6 peuvent être maintenues sous la gestion DNS TR7. Les enregistrements PTR sont gérés pour les besoins d'inventaire réseau et de résolution inverse. La sécurité de zone inverse peut aussi être renforcée conjointement avec DNSSEC.
Les enregistrements CAA peuvent être utilisés pour restreindre quelles autorités de certification peuvent émettre des certificats pour le domaine. Les enregistrements TLSA publient le contexte de liaison de certificat sur DNS dans les scénarios DANE. Ces enregistrements unifient la sécurité DNS avec les opérations applicatives et de certificat.
35 types d'enregistrements, DNSSEC, transfert de zone AXFR et DNS UPDATE — dans une seule couche de gestion. Laissez-nous vous présenter un déploiement en direct sur votre propre infrastructure.