Qu’est-ce que DNSSEC et comment fonctionne-t-il ?

DNSSEC ajoute des signatures numériques aux données DNS. Un résolveur qui valide ces signatures peut détecter une réponse falsifiée ou une chaîne de confiance rompue. Il protège l’origine et l’intégrité des entrées, sans chiffrer les requêtes ni rendre automatiquement un site fiable.

Comment fonctionne la chaîne de confiance ?

L’opérateur de la zone signe les enregistrements avec une clé privée et publie des entrées DNSKEY et RRSIG. La zone parente contient un enregistrement DS qui relie cette zone à la clé de la zone enfant. Le résolveur suit la chaîne depuis une racine de confiance jusqu’à la réponse. Il accepte les données correctement signées et peut renvoyer une erreur si la chaîne est rompue. La RFC 4033 explique les capacités et limites du mécanisme.

L’absence d’un enregistrement peut également être authentifiée pour éviter une fausse réponse négative. Le visiteur ne voit généralement pas les signatures : tout dépend de la validation faite par son résolveur. Une case DNSSEC activée dans une interface ne prouve pas que le DS parent, les clés et les signatures concordent sur tous les serveurs faisant autorité.

Que protège DNSSEC, et que ne protège-t-il pas ?

Avec la validation, DNSSEC rend plus difficile la modification discrète d’une réponse DNS. Il ne cache pas le nom interrogé au résolveur et ne chiffre pas le transport ; DoH et DoT répondent à un autre besoin de confidentialité. DNSSEC ne remplace pas non plus un certificat TLS, un contenu honnête, la protection du compte du bureau ou une bonne gestion de zone.

Si le propriétaire publie lui-même une mauvaise adresse, DNSSEC peut authentifier fidèlement cette mauvaise donnée. Gardez des entrées A, AAAA, MX et autres correctes indépendamment de la signature. Utilisez une recherche DNS pour comparer les réponses de résolveurs ordinaires et validateurs. Ne désactivez pas la validation pour tout le monde afin de masquer un seul domaine défectueux.

Pourquoi un domaine signé peut-il cesser de répondre ?

Un DS parent resté en place après un changement de fournisseur DNS ou de clés est une cause fréquente. Des signatures expirées, des serveurs faisant autorité incohérents ou une rotation de clés ratée peuvent aussi casser la validation. Examinez la délégation, les DNSKEY et DS actuels, les dates des RRSIG et les réponses de chaque serveur. Notez l’heure et l’erreur précise avant toute modification.

Avant de déplacer une zone signée, coordonnez le changement du DS avec le nouvel opérateur et vérifiez ses clés. Après réparation, tenez compte des réponses positives et négatives encore en cache. Pour un domaine utilisé par le courrier ou une API, préparez une fenêtre de changement et un retour arrière. L’automatisation et la surveillance des signatures comptent davantage qu’un statut « activé » non vérifié.