DNSSEC est une signature des enregistrements DNS. Le serveur de noms joint une preuve cryptographique à la réponse (enregistrement RRSIG). Le résolveur qui valide cette preuve s’assure que la réponse vient bien de la zone et qu’elle n’a pas été altérée en chemin. Sans DNSSEC, un résolveur doit faire confiance au réseau qui lui a parlé.
Ce que DNSSEC garantit, et ce qu’il ne fait pas
| Sujet | DNSSEC | Autre mécanisme |
|---|---|---|
| La réponse A ou MX n’a pas été falsifiée | Oui, si le résolveur valide et que la chaîne est intacte | — |
| La requête DNS est cachée à l’opérateur | Non | DNS sur HTTPS ou DNS sur TLS, entre le client et son résolveur |
| La page web est chiffrée | Non | Certificat HTTPS |
| Le visiteur est la bonne personne | Non | Authentification du site |
Un site peut avoir un cadenas valide et un DNS non signé. Il peut aussi avoir DNSSEC et un certificat expiré. Les deux contrôles sont indépendants. Pour la date du certificat : vérifier l’expiration SSL.
DNSSEC ne choisit pas non plus « le bon hébergeur ». Il protège l’enregistrement tel qu’il est publié. Si vous signez une mauvaise adresse IP, les résolveurs valident cette mauvaise adresse avec assurance.
La chaîne de confiance, en pratique
La signature ne suffit pas. Il faut une chaîne depuis la racine DNS jusqu’à votre zone.
- La zone est signée par des clés dont le gestionnaire DNS a la partie privée (souvent une option « activer DNSSEC » chez le prestataire DNS).
- Un condensé de la clé de la zone, l’enregistrement DS, est publié chez le parent : le bureau d’enregistrement, pour un
.frou un.com. - Le parent est lui-même signé, jusqu’à la racine.
Si le DS manque, les résolveurs validants considèrent la zone comme non signée : DNSSEC n’apporte rien, mais le site répond. Si le DS est présent et que les signatures manquent, sont expirées, ou ne correspondent plus aux clés (changement de DNS sans copier les clés), la validation échoue.
L’échec se voit ainsi : dig exemple.fr @1.1.1.1 renvoie SERVFAIL, alors que dig exemple.fr @ns1.votredns.example +cd (vérification désactivée) ou une requête directe au NS montre encore l’adresse. Une partie des visiteurs, ceux dont le résolveur valide, ne résolvent plus le nom. Les autres oui. Ce n’est pas une « propagation lente ». Le diagnostic d’un nom injoignable est dans domaine qui ne résout plus.
Les signatures ont une durée. Une zone signée une fois puis plus jamais re-signée finit par échouer de la même façon. L’option du prestataire doit rester active, pas seulement cochée le jour de la mise en place.
Activer sans couper le site
Ordre sûr :
- Les NS définitifs répondent déjà correctement en A, AAAA et MX. Le mode d’emploi des requêtes est dans tester le DNS.
- Activez la signature chez ces NS et vérifiez que les RRSIG sont servis.
- Seulement ensuite, publiez le DS chez le registrar. Copiez le key tag, l’algorithme et le condensé demandés. Un champ décalé casse la chaîne.
- Interrogez un résolveur validant (1.1.1.1, 8.8.8.8, 9.9.9.9). La réponse doit être l’IP, pas
SERVFAIL. L’outildelvoudig +dnssecmontre l’indicateur AD (authentic data) quand la validation a réussi.
Pour retirer DNSSEC, on retire d’abord le DS, on attend que les caches du parent expirent, puis on arrête de signer. Retirer les signatures en laissant le DS en place reproduit la panne.
Lors d’un changement de prestataire DNS, les clés ne suivent pas toutes seules. Soit le nouvel opérateur importe les clés, soit vous retirez le DS avant la bascule et vous le republiez après la nouvelle signature. Les deux chemins évitent une fenêtre où le DS désigne des clés qui ne signent plus.
