DNSSEC est un standard depuis plus d'une décennie, pourtant l'adoption reste inégale. La cryptographie est bien comprise ; le modèle opérationnel est bien documenté. Ce qui empêche de nombreuses organisations de l'activer est la custody : la clé de signature (KSK) et la clé de signature de zone (ZSK) sont les racines de confiance de la zone entière, et la plupart des entreprises ne veulent pas voir ces clés entre les mains d'un fournisseur.
Les fournisseurs DNS cloud offrent DNSSEC sign-and-serve, mais les clés vivent dans le KMS du fournisseur. Le fournisseur peut révoquer, faire tourner ou être assigné en justice — l'intégrité de votre zone est conditionnelle à la continuité d'exploitation du fournisseur. Certaines organisations acceptent ce compromis ; beaucoup, dans les secteurs réglementés (gouvernement, défense, finance), ne le peuvent pas.
L'alternative historique est d'exploiter un pipeline de signature DNSSEC auto-géré : BIND avec gestion de clés personnalisée, scripts pour faire tourner les clés selon un calendrier, intégration HSM externe, configuration des slaves pour recevoir les enregistrements signés. Cela fonctionne, mais la charge opérationnelle est significative et les modes d'échec sont silencieux (RRSIG expiré, chaîne NSEC manquante).
TR7 GTM amène DNSSEC dans la même surface opérateur que le reste du plan DNS faisant autorité — opt-in par domaine, enregistrements signés comme données de première classe, transfert de zone qui porte la signature — sans dépendre d'un service de signature externe.
DNSSEC est un drapeau de fonctionnalité par domaine combiné à un support de première classe pour tous les types d'enregistrements DNSSEC. Sign-and-serve a lieu sur le nœud TR7 GTM ; la custody des clés reste avec l'opérateur.
Chaque domaine DNS dans TR7 GTM active ou désactive indépendamment DNSSEC via un champ booléen du schéma. Les déploiements mixtes — certaines zones signées, d'autres non — coexistent sur la même flotte sans imposer un engagement à l'échelle de la flotte.
DNSKEY, DS, NSEC, NSEC3, NSEC3PARAM, RRSIG, CDS, CDNSKEY font partie de la liste des types d'enregistrements supportés aux côtés de A, AAAA, CNAME, MX et du reste. Le schéma les traite comme des données, pas comme un sous-système séparé.
L'opérateur choisit comment le serial SOA s'incrémente : DEFAULT (format YYYYMMDD01), INCREASE (+1 par changement), EPOCH (horodatage UNIX) ou OFF (contrôle manuel). La progression du serial compte pour les validateurs DNSSEC et pour les slaves en aval.
AXFR/IXFR transfère les enregistrements DNSSEC aux côtés des autres types. Les slaves en mode Express servent les réponses signées du maître sans re-signer — point unique de signature, multiples points de service.
DNSSEC chez TR7 GTM couvre la surface opérationnelle — schéma, transfert, service, intégrité — sans déléguer à un signataire tiers.
Chaque domaine DNS porte un champ booléen `dnssec`. Quand il vaut true, la zone est traitée comme DNSSEC-active : les enregistrements DNSKEY et DS sont attendus, les enregistrements RRSIG accompagnent chaque RRset sur le fil, et les enregistrements NSEC/NSEC3 couvrent l'espace de noms de la zone.
Les enregistrements DNSKEY (les clés publiques de la zone) sont gérés comme des enregistrements réguliers dans le schéma. Les opérateurs importent ou définissent le contenu DNSKEY ; la rotation est gérée en ajoutant de nouveaux enregistrements DNSKEY avant le retrait des anciens, suivant les motifs standard de rollover pre-publish.
Les enregistrements DS (Delegation Signer) sont gérés dans la zone parente. Lorsque les zones parente et enfant sont toutes deux hébergées sur TR7 GTM, les enregistrements DS se propagent naturellement ; lorsque le parent est ailleurs, les opérateurs exportent les enregistrements DS pour soumission en amont.
Les enregistrements NSEC et NSEC3 prouvent qu'un nom requis n'existe pas. NSEC3 ajoute sel et itérations pour empêcher l'énumération de zone. Les deux types d'enregistrements sont de première classe dans le schéma et servent comme partie intégrante de la zone.
Les enregistrements RRSIG portent les signatures cryptographiques sur les RRsets. Le schéma supporte RRSIG comme type d'enregistrement ; le transfert AXFR/IXFR porte les RRSIG aux côtés des RRsets signés.
Les enregistrements CDS et CDNSKEY communiquent l'état DS prévu de la zone enfant au parent — permettant l'automatisation côté parent (RFC 7344). Utile pour les organisations exploitant des délégations à travers plusieurs fournisseurs DNS.
Quatre modes sélectionnables par l'opérateur pour la progression du serial SOA : DEFAULT (basé sur la date YYYYMMDD01), INCREASE (+1 par changement), EPOCH (horodatage UNIX), OFF (contrôle manuel). Les valeurs de serial sont critiques pour DNSSEC car les zones signées doivent faire progresser le serial à chaque changement pour invalider les signatures mises en cache.
Chaque domaine peut lister les IPs de serveurs slaves vers lesquels il pousse les mises à jour de zone signées via NOTIFY. Les opérateurs font tourner leurs propres slaves en aval (PowerDNS, BIND, NSD) et reçoivent des copies signées pour un service distribué.
Les domaines en mode Express tirés depuis un maître en amont héritent de l'état DNSSEC du maître. Si le maître signe, TR7 sert les réponses signées ; si le maître ne signe pas, TR7 sert sans signature. La décision de signature appartient au maître.
La liste complète des types d'enregistrements (A, AAAA, AFSDB, ALIAS, CAA, CERT, CDNSKEY, CDS, CNAME, DNSKEY, DNAME, DS, HINFO, KEY, LOC, MX, NAPTR, NS, NSEC, NSEC3, NSEC3PARAM, OPENPGPKEY, PTR, RP, RRSIG, SOA, SPF, SSHFP, SRV, TKEY, TSIG, TLSA, SMIMEA, TXT, URI) inclut huit types liés à DNSSEC comme membres de première classe.
DNSSEC chez TR7 GTM est exploité conjointement avec le transfert de zone, la rotation des clés, la délégation parente et les attentes des validateurs.
DNSSEC est activé par domaine. Les opérateurs déploient DNSSEC zone par zone, validant chacune avant d'étendre. Les états mixtes sont supportés indéfiniment — certaines zones signées, d'autres non, sur la même flotte TR7.
Le rollover DNSKEY suit les motifs standard pre-publish / double-signature : ajouter la nouvelle clé comme enregistrement DNSKEY, attendre le rafraîchissement des caches, basculer le signataire actif, retirer l'ancienne clé. Le schéma traite chaque clé comme une donnée ; le calendrier de rollover est contrôlé par l'opérateur.
Les enregistrements RRSIG portent des intervalles de validité. Les opérateurs définissent la cadence de rafraîchissement — typiquement les signatures sont rafraîchies avant l'expiration pour éviter les échecs de validateur pendant des problèmes passagers du pipeline de signature. La plateforme met en évidence les expirations à venir pour action de l'opérateur.
NSEC permet le zone walking (un attaquant peut énumérer tous les noms) ; NSEC3 ajoute sel et itérations pour empêcher le walking. Les opérateurs choisissent par zone — les zones exposées au public utilisent souvent NSEC3 pour empêcher l'énumération ; les zones fermées peuvent utiliser NSEC pour la simplicité.
La délégation de zone-cut nécessite que le parent publie un enregistrement DS. Quand la zone parente est hébergée sur TR7, les enregistrements DS font partie de l'ensemble d'enregistrements du parent. Quand le parent est ailleurs, les opérateurs exportent les valeurs DS depuis les enregistrements CDS et les soumettent en amont.
Les serveurs slaves en aval reçoivent les zones signées via AXFR/IXFR et les servent. Les slaves ne re-signent pas ; ils font confiance aux signatures du maître. Cela supporte le service distribué (multiples POP slaves, caches régionaux) sans surcharge de re-signature.
Les zones du secteur public nécessitant l'intégrité DNSSEC pour la conformité doivent souvent garder les clés de signature à l'intérieur du périmètre de sécurité. Le DNSSEC on-prem de TR7 supporte cette exigence sans déléguer à un fournisseur cloud.
Les zones bancaires et de traitement de paiement utilisent DNSSEC pour prévenir les attaques de spoofing DNS contre les services clients. L'opt-in par domaine permet aux banques de déployer DNSSEC zone par zone, validant chacune avant un déploiement plus large.
Le maître signe la zone ; les nœuds TR7 agissent comme slaves Express et servent les réponses signées du maître. La signature a lieu une fois ; le service a lieu à l'échelle sans surcharge de re-signature par edge.
Les organisations utilisant plusieurs fournisseurs DNS pour la redondance publient les enregistrements CDS via TR7 afin que la zone parente puisse apprendre automatiquement les valeurs DS courantes. L'automatisation côté parent réduit la coordination manuelle de rollover.
Parcourez DNSSEC on-prem avec TR7 GTM : opt-in par domaine, tous les types d'enregistrements DNSSEC comme données de première classe, transfert de zone qui porte les signatures intactes.