DNSSEC ajoute l'authentification d'origine et l'intégrité aux données DNS lorsqu'un validateur peut établir la chaîne de confiance. Il ne crypte pas les réponses DNS , n'approuve pas un service d'envoi et n'authentifie pas le contenu des messages. Sa valeur pour le courrier électronique réside dans la protection des dépendances DNS , avec des conséquences sur la disponibilité en cas de rupture de la chaîne de validation.
Vérifier une chaîne plutôt que la présence d'une signature
Références : RFC 4033 §3, RFC 4035 §5.
Une réponse signée contient du matériel cryptographique, mais la présence d'un RRSIG à elle seule ne constitue pas une validation réussie. Le validateur a besoin d'un point de départ fiable, d'informations DNSKEY et de délégation appropriées, de signatures utilisables et d'un timing valide. Les données DS parent et les clés enfants doivent rester coordonnées lors des modifications.
Utilisez un résolveur de validation ou un diagnostic capable de validation avec une configuration de confiance connue. Si une application s'appuie sur l'indication de données authentifiées d'un résolveur, le chemin et la relation de confiance avec ce résolveur sont importants. Le simple fait de demander des enregistrements DNSSEC avec un outil ne permet pas à l'outil de les valider, et un indicateur de réponse faisant autorité n'est pas un résultat de validation DNSSEC .
Gardez les états de validation séparés
Références : RFC 4035 §4.3, RFC 7672 §2.1.
Un résultat sécurisé possède une chaîne de confiance validée pour les données renvoyées. Un résultat non sécurisé peut être une branche légitime non signée et n'est pas synonyme de contrefaçon détectée. Un faux résultat signifie que la validation attendue a échoué. Un résultat indéterminé doit également être distingué : RFC 4035 l'utilise lorsque le résolveur ne peut pas déterminer si les données doivent être signées car les enregistrements DNSSEC nécessaires ne peuvent pas être obtenus. RFC 7672 utilise la signification de RFC 4035 pour SMTP DANE et traite une telle condition comme un échec, plutôt que de la traiter silencieusement comme non signée. Conservez le contexte de diagnostic car RFC 4033 décrit l'indétermination différemment.
Un résolveur de validation peut renvoyer SERVFAIL pour de fausses données, mais SERVFAIL seul ne diagnostique pas DNSSEC : d'autres échecs DNS peuvent le produire. Examinez les diagnostics de validation, le DS parent, la DNSKEY enfant, les signatures et l'heure. Ne désactivez pas la validation comme réparation par défaut, car cela modifie la propriété de confiance testée.
Reproduire trois dépendances de messagerie distinctes
Références : RFC 4035 §5.2, RFC 4035 §5.4.
Le cas synthétique A a une zone signée, un DS parent et une DNSKEY enfant correspondants, ainsi que des signatures actuellement valides pour l'enregistrement de courrier interrogé. Le résultat attendu du validateur configuré est sécurisé. Le cas B a un enfant intentionnellement non signé avec une preuve authentifiée de l'absence de DS dans sa délégation. Le résultat attendu n’est pas sûr, pas faux.
Le cas C laisse l'ancienne DS chez le parent après remplacement de la clé enfant sans rollover compatible. Le résultat attendu est une chaîne de validation rompue et, pour le dispositif de résolution de validation défini, SERVFAIL à une requête ordinaire. Une recherche directe non validante peut toujours afficher le TXT ou Enregistrement MX. Cette différence ne prouve pas que le résolveur de validation a tort.
Reproduisez ces cas uniquement dans une hiérarchie de tests signés jetables avec sa propre ancre de confiance. Conservez le DS parent, la DNSKEY enfant, l'enregistrement interrogé, le RRSIG, la configuration du résolveur, l'horloge et la trace de validation détaillée. Recherchez le même propriétaire et le même type dans chaque cas et comparez l'état classifié. Ces scénarios de résolution récursive sont des spécifications de test, et non un déploiement de zone signée en direct ou une exécution de validateur récursif. La dernière section des cas de validation hors ligne capturés documente le dispositif cryptographique distinct et délimité capturé le 7 novembre 2026 ; il n'a pas observé SERVFAIL ni testé SMTP DANE intégré.
Comprendre les exigences supplémentaires DANE
Références : RFC 7672 §2.2, RFC 7672 §3.
SMTP DANE utilise l'authentification DNSSEC TLSA associations et support des expéditeurs pour authentifier le transport. La signature d'un domaine à elle seule ne crée pas les enregistrements TLSA requis ni n'oblige chaque expéditeur à appliquer DANE . Le chemin de découverte MX et TLSA et l'association de certificat nécessitent leur propre vérification selon RFC 7672 .
Un remplacement de certificat ou de clé peut rompre une correspondance TLSA même lorsque DNSSEC reste sain. À l’inverse, une chaîne DNSSEC rompue peut empêcher un expéditeur prenant en charge d’utiliser en toute sécurité des données TLSA autrement correctes. Planifiez les deux couches ensemble et conservez un test SMTP contrôlé. Ni DANE ni DNSSEC ne remplacent SPF, DKIM ou DMARC.
Utiliser la signature comme une dépendance maintenue
Références : RFC 6781 §4.1.
Enregistrez la propriété de la signature, les mises à jour DS du registraire, le roulement des clés et la surveillance. Avant de changer de fournisseur DNS , déterminez si les clés et la chaîne seront conservées ou transférées. Surveillez la validité et la validation des signatures à partir des chemins pertinents et exigez des preuves de récupération avant de résoudre une erreur. Signalez la confiance exacte DNS et le comportement de messagerie observé plutôt que de prétendre que DNS signé sécurise tous les e-mails.
Cas de validation hors ligne capturés
Références : RFC 4035 §5.
La capture conservée, inspectée mais non réexécutée pour cet examen, enregistre qu'un appareil cryptographique isolé s'est exécuté le 7 novembre 2026 à 20:34:42 UTC avec Python 3.12.14 et dnspython 2.9.2. Il a épinglé par exemple une DNSKEY parent générée comme ancre de confiance de laboratoire, généré une clé enfant pour signed.example , signé le DS de l'enfant avec la clé parent et signé un test Enregistrement TXT avec la clé enfant. Les vérifications de signature réelles ont réussi pour le DS et TXT , et un DS SHA-256 calculé correspondait à la DNSKEY de l'enfant. Le résultat capturé était une chaîne hors ligne validée.
Pour un cas de chaîne cassée, l'appareil a généré une clé enfant de remplacement tout en conservant l'ancienne DS. Le DS calculé ne correspondait plus et le projecteur a rejeté la chaîne. Il n'a pas exécuté de validateur récursif et n'a pas observé SERVFAIL . Pour un cas non signé, il a vérifié un NSEC signé par le parent sur unsigned.example dont le bitmap de nom exact contenait NS et omis DS, puis a classé cette délégation comme non sécurisée. Cette preuve étroite n’implémente pas de résolveur général de déni d’existence.
Pour reproduire, créez des clés parent et enfant ECDSA P-256, créez des enregistrements DNSKEY et DS, signez le DS et le TXT avec des délais de création/expiration limités et appelez l'opération de validation DNSSEC de dnspython par rapport aux clés parent épinglées et aux clés enfants correspondantes. Remplacez la clé enfant pour le cas de non-concordance. Pour le cas non signé, validez la signature NSEC de délégation exacte et inspectez son bitmap. Conserver les enregistrements publics des clés, les signatures, l'heure de validation, les versions de dépendances et les résultats ; garder les clés privées de test jetables. Les preuves montrent des opérations cryptographiques locales réelles, et non une validation DNS publique, une production SMTP DANE ou un résolveur récursif déployé.