Vérificateur DNSSEC

Le DNS classique n'intègre aucune authentification. Un résolveur pose une question, reçoit une réponse en UDP, et n'a aucun moyen de confirmer qu'elle provient bien du serveur faisant autorité plutôt que d'un attaquant ayant deviné la requête et renvoyé une réponse falsifiée avant la vraie. Les attaques par empoisonnement de cache type Kaminsky fonctionnent précisément parce que rien dans le protocole ne garantit l'origine d'une réponse, en dehors de l'identifiant de transaction qui correspond. DNSSEC comble cette faille non pas en chiffrant quoi que ce soit (les réponses restent tout aussi visibles sur le réseau) mais en attachant une signature à chaque ensemble d'enregistrements, afin qu'un résolveur puisse vérifier l'authenticité même sur un chemin réseau non fiable.

Cette signature doit pouvoir être vérifiée sans confiance aveugle envers le serveur qui a répondu. DNSSEC règle cela avec une chaîne de confiance qui part de la racine DNS et suit le même chemin de délégation que le DNS classique utilise déjà, jusqu'à la zone interrogée : elle ajoute des signatures et des enregistrements de clés aux serveurs déjà interrogés, pas de nouveaux serveurs.

• DNSSEC authentifie les réponses DNS, il ne les chiffre pas : la requête et la réponse restent visibles pour quiconque
• La chaîne de confiance suit le chemin de délégation existant (racine → TLD → domaine), elle n'introduit pas de hiérarchie séparée
• Un résolveur validant obtient soit une signature qui se vérifie, soit rien : il n'existe pas de confiance partielle
• Un domaine sans aucun enregistrement DNSSEC est simplement non signé, ce qui est l'état par défaut et non une erreur en soi

Un enregistrement DNSKEY porte la clé publique de signature d'une zone. La plupart des zones en publient deux : une Zone Signing Key (ZSK) qui signe les ensembles d'enregistrements courants, et une Key Signing Key (KSK) qui signe l'ensemble des DNSKEY eux-mêmes. Cette séparation permet de faire tourner la ZSK fréquemment sans toucher à la KSK, la seule dont la zone parente doit avoir connaissance. Le rdata du DNSKEY porte des flags (257 marque une KSK via le bit Secure Entry Point, 256 marque une ZSK), un champ protocole fixé à 3, un numéro d'algorithme et la clé publique elle-même.

Un enregistrement DS (Delegation Signer) vit dans la zone parente, pas dans l'enfant : un hachage de la KSK de la zone enfant, publié là où le parent porte déjà les enregistrements NS de l'enfant. C'est le véritable maillon de la chaîne de confiance : un résolveur qui fait déjà confiance au parent peut récupérer le DS de l'enfant, calculer le hachage de la DNSKEY présentée par l'enfant, et vérifier qu'ils correspondent avant de faire confiance à quoi que ce soit signé par cette zone. Sans DS chez le parent, la chaîne s'arrête là, même si la zone enfant est elle-même parfaitement signée.

Un enregistrement RRSIG est la signature attachée à un ensemble d'enregistrements signé : un RRSIG par type d'enregistrement et par zone, couvrant tous les enregistrements de ce type à ce nom en une seule signature. Son rdata porte le type couvert, l'algorithme et le key tag identifiant quelle DNSKEY l'a produit, des dates d'expiration et d'entrée en vigueur, et les octets de signature eux-mêmes. Les signatures sont volontairement limitées dans le temps : une zone se re-signe selon un calendrier de rotation, ce qui borne la durée pendant laquelle une signature capturée resterait rejouable si elle avait fuité hors de sa fenêtre prévue.

Un résolveur validant qui vérifie avec succès toute la chaîne d'une zone (le DS chez le parent correspondant au hachage de la DNSKEY de l'enfant, le RRSIG se vérifiant contre cette DNSKEY, jusqu'à la racine) positionne le bit AD (Authenticated Data) sur sa réponse. C'est ce bit que la plupart des applications lisent réellement : un résolveur quelque part sur le chemin a effectué le travail cryptographique et la réponse a passé la vérification. Un résolveur qui obtient un DS mais ne peut pas terminer la validation, ou qui reçoit des enregistrements sans aucune signature, ne positionne pas AD.

Cet outil rapporte trois états de chaîne. Secure signifie que la zone est signée et que le résolveur a validé la chaîne de bout en bout (AD positionné). Unsigned signifie qu'aucun enregistrement DS ou DNSKEY n'a été trouvé, l'état par défaut de la grande majorité des domaines, non un défaut mais l'absence d'activation volontaire. Insecure signifie que la zone porte des enregistrements DNSSEC mais que le résolveur n'a pas obtenu de réponse validée : le plus souvent un DS absent ou périmé chez le parent ne laisse rien à authentifier, et c'est aussi là que se manifeste ici un véritable échec de validation. Ce cas d'échec est celui que DNSSEC existe pour détecter (clé incohérente, RRSIG expiré ou réponse altérée, ce que la RFC 4033 nomme bogus), et un résolveur validant est censé refuser purement et simplement une telle réponse plutôt que de la transmettre comme si de rien n'était.

Le choix d'algorithme ne change rien à cette logique mais affecte la longévité : RSA/SHA-256 (algorithme 8) reste le plus largement déployé, tandis qu'ECDSA P-256 (algorithme 13) et Ed25519 (algorithme 15) produisent des signatures et des clés bien plus courtes pour une marge de sécurité équivalente, ce qui explique pourquoi les déploiements récents les privilégient de plus en plus face à RSA.

La garantie de DNSSEC est étroite : si une réponse arrive avec AD positionné, cet ensemble d'enregistrements est bien celui que le propriétaire de la zone a réellement signé, non modifié en chemin. Cela ne dit rien sur la fiabilité du contenu, sur la bonne configuration d'un serveur mail listé dans un MX, ou sur la sécurité d'un site derrière un enregistrement A : autant de questions distinctes que DNSSEC n'a jamais eu vocation à trancher.

Cela ne masque rien non plus : requête et réponse signée circulent en clair, exactement comme en DNS non signé. La confidentialité est un problème distinct, traité par DNS-over-HTTPS ou DNS-over-TLS au niveau transport, orthogonal à DNSSEC et couramment déployé en complément plutôt qu'à sa place.