Capacité

DNSSEC On-Prem

Signez les zones faisant autorité sur votre propre infrastructure — l'intégrité DNSSEC sans confier la custody des clés à un tiers.

DNSSEC transforme le DNS d'une recherche non authentifiée en un service vérifiable cryptographiquement. Le prix que la plupart des organisations paient est la custody : les fournisseurs DNS cloud gèrent les clés de signature, effectuent la signature et servent les réponses signées — pratique, mais les clés ne se trouvent jamais à l'intérieur de votre périmètre de sécurité. TR7 GTM offre le DNSSEC sign-and-serve sur l'appliance elle-même. L'opt-in DNSSEC par domaine garde le déploiement granulaire. Les 35 types d'enregistrements DNS supportés coexistent avec la couche DNSSEC — les enregistrements DNSKEY, DS, NSEC, NSEC3, NSEC3PARAM, RRSIG, CDS, CDNSKEY sont de première classe dans le schéma, transférés sur AXFR/IXFR comme tout autre type d'enregistrement, et servis avec le reste de la zone. Les modes d'édition SOA (DEFAULT YYYYMMDD01, INCREASE, EPOCH, OFF) donnent aux opérateurs le contrôle de la progression des serials de zone — important à la fois pour DNSSEC et pour la cohérence des slaves en aval. Le transfert de zone porte les enregistrements signés tels quels, afin que les slaves en mode Express servent les réponses signées du maître sans re-signer. Le résultat : un plan DNS faisant autorité capable de DNSSEC qui garde les clés de signature, les décisions de rollover et l'intégrité de zone sous votre contrôle opérationnel — pas sous un contrat SaaS.

Types d'enregistrements DNSSEC — DNSKEY, DS, NSEC, NSEC3, NSEC3PARAM, RRSIG, CDS, CDNSKEY

Par domaine

Opt-in DNSSEC — zones signées et non signées coexistent

DNSSEC

Validé au retour — une réponse forgée n'atteint jamais le cache

On-prem

La custody des clés reste sous contrôle de l'opérateur

L'adoption de DNSSEC est freinée par la custody des clés, pas par la complexité cryptographique.

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.

Notre approche

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.

Opt-in DNSSEC par domaine

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.

Huit types d'enregistrements DNSSEC comme données de première classe

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é.

Les modes d'édition SOA contrôlent la progression du serial

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.

Le transfert de zone porte les enregistrements signés intacts

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.

Capacités

DNSSEC chez TR7 GTM couvre la surface opérationnelle — schéma, transfert, service, intégrité — sans déléguer à un signataire tiers.

Valider, pas seulement signer

Signer prouve vos zones au monde. Valider protège vos propres utilisateurs : les réponses qui reviennent par le résolveur récursif sont vérifiées contre la chaîne de confiance, si bien qu'une réponse forgée ou altérée casse avant d'être mise en cache — et une hausse soudaine des verdicts bogus est une alerte, car c'est soit une attaque, soit une zone cassée, et les deux doivent se savoir tout de suite.

Drapeau booléen DNSSEC par domaine

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.

Gestion des enregistrements DNSKEY

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.

Support des enregistrements DS pour la délégation de zone parente

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.

Déni d'existence authentifié NSEC et NSEC3

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.

Enregistrements de signature RRSIG

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.

CDS et CDNSKEY pour mises à jour parent automatisées

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.

Modes d'édition SOA pour contrôle du serial

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.

IPs de serveurs slaves pour la réplication de zones signées

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é.

Compatible avec le mode Express pour signature hidden-master

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.

35 types d'enregistrements DNS au total dont 8 types DNSSEC

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.

Profondeur opérationnelle

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.

Granularité d'opt-in par domaine

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.

Rotation de clés via la gestion d'enregistrement

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.

Fenêtres de validité RRSIG

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.

Sélection NSEC vs NSEC3

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é.

Coordination de délégation parente

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.

Compatibilité avec les serveurs slaves

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.

Quand l'utiliser

Intégrité DNS gouvernementale et défense

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.

Zones signées pour le secteur financier

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.

Architectures hidden-master avec service signé

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.

DNS multi-fournisseur avec coordination parent basée sur CDS

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.

Questions fréquentes

TR7 gère-t-il les clés DNSSEC, ou dois-je apporter les miennes ?

Les clés DNSSEC (enregistrements DNSKEY) sont gérées comme des enregistrements dans le schéma. Les opérateurs importent des clés existantes ou en génèrent de nouvelles ; TR7 les stocke et les sert, gère leur cycle de vie comme une donnée et les apparie avec les enregistrements RRSIG. L'outillage de génération de clés et l'intégration HSM sont des choix de l'opérateur — le schéma est ouvert quant à ce qui contient les clés.

Puis-je utiliser DNSSEC sur les zones en mode Express ?

Oui. Les zones en mode Express héritent de l'état DNSSEC du maître. Le maître signe ; TR7 tire les enregistrements signés via AXFR/IXFR et les sert. Aucune re-signature n'a lieu au niveau TR7 — les signatures du maître sont servies telles quelles.

Comment le mode d'édition SOA affecte-t-il DNSSEC ?

DNSSEC requiert que le serial SOA progresse à chaque changement de zone afin que les validateurs et résolveurs de cache sachent que la zone a été mise à jour. Les modes d'édition SOA — DEFAULT (YYYYMMDD01), INCREASE (+1), EPOCH (horodatage UNIX), OFF (manuel) — permettent aux opérateurs de choisir comment cette progression est calculée. DEFAULT et INCREASE sont les plus courants pour les zones signées.

Qu'en est-il du zone walking NSEC ?

Les enregistrements NSEC peuvent être parcourus pour énumérer toute la zone, ce qui est parfois une préoccupation de confidentialité ou de reconnaissance. NSEC3 ajoute sel et itérations pour empêcher l'énumération. Le choix entre NSEC et NSEC3 est par zone — les opérateurs arbitrent entre simplicité (NSEC) et résistance au walking (NSEC3).

Comment les serveurs slaves sont-ils gérés avec DNSSEC ?

Les serveurs slaves reçoivent les zones signées via le transfert AXFR/IXFR. Les slaves servent les signatures du maître sans re-signer. TR7 GTM peut agir à la fois comme maître (signature) et comme slave d'un autre maître (servant les signatures en amont). Le service distribué fonctionne sans surcharge de re-signature.

DNSSEC est-il compatible avec les fonctionnalités GSLB et de sélection DC ?

Oui. DNSSEC opère à la couche d'intégrité de zone ; GSLB et sélection DC opèrent à la couche de sélection de réponse. Le GSLB choisit quels enregistrements renvoyer ; la couche DNSSEC garantit que ces enregistrements arrivent avec des signatures valides. Les deux sont orthogonaux — combiner DNSSEC avec GSLB pondéré, géographique et multi-source est supporté.

Signez vos zones sur votre propre infrastructure.

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.