DNSSEC en 2026 : sécuriser vos résolutions DNS avec la chaîne de confiance

Le DNS reste l'une des couches critiques de l'infrastructure internet, pourtant seulement 35% des requêtes DNS mondiales bénéficient d'une validation DNSSEC. En Europe, cette proportion grimpe à 49%, mais reste largement insuffisante. Sans DNSSEC, vos résolutions DNS sont vulnérables aux attaques de cache poisoning et aux détournements MITM (man-in-the-middle).

Depuis 2010, DNSSEC est devenu un standard mature. La zone racine elle-même est signée depuis 2012 (92% d'adoption), et des registres comme .se, .no et .dk dépassent les 70% de validation. Pourtant, des domaines de premier ordre comme .com (4.3%) et .net (5.3%) stagnent. Cette asymétrie crée un faux sentiment de sécurité.

Ce guide vous montrera comment mettre en place une infrastructure DNSSEC robuste sur Bind9, de la génération des clés à la validation côté client, en passant par les bonnes pratiques de rotation et d'opérations critiques.

• Qu'est-ce que DNSSEC ? — Architecture et chaîne de confiance
• Les records DNSSEC — Types, structure, rôles
• Configurer DNSSEC sur Bind9 — Étapes et commands pratiques
• Vérifier et diagnostiquer — Outils et diagnostics
• Bonnes pratiques — Rotation, timing, sécurité
• Perspectives complémentaires — Ressources supplémentaires

DNSSEC (Domain Name System Security Extension) ajoute une chaîne cryptographique de confiance au DNS. Au lieu de simplement transmettre une réponse DNS, un serveur autorisé signe cette réponse avec une clé privée. Les clients valident la signature en remontant la chaîne jusqu'à la zone racine (trust anchor).

La chaîne de confiance (Trust Chain)

1. Zone racine — Signée et publiée mondialement
2. Registre du TLD (ex: .fr, .com) — Signe les délégations des domaines
3. Votre domaine — Vous signez vos propres records et publiez une clé de délégation (DS)
4. Résolveur client (ex: Unbound, systemd-resolved) — Valide la chaîne complète

Sans cette chaîne intacte, la validation échoue et la requête est rejetée (SERVFAIL). C'est la sécurité par défaut — le refus plutôt que l'acceptation du doute.

Authentification vs. Confidentialité

Important : DNSSEC authentifie l'origine des records DNS, mais ne les chiffre pas. Les requêtes et réponses restent en clair sur le réseau. Pour le chiffrement, vous avez besoin de DoH (DNS over HTTPS), DoT (DNS over TLS) ou DNSCrypt.

DNSSEC introduit quatre nouveaux types de records. Comprendre leur rôle est essentiel pour configurer et dépanner.

Clés de signature (ZSK) vs. clés de délégation (KSK)

• KSK (Key Signing Key) — Flag 257, signe d'autres DNSKEY, rarement changée
• ZSK (Zone Signing Key) — Flag 256, signe tous les records de la zone, changée plus fréquemment

Cette séparation permet une rotation des clés de zone sans modifier le registre parent.

Nous allons configurer DNSSEC sur un domaine exemple avec Bind9 (BIND 9.16+). Les étapes sont :

1. Générer les clés KSK et ZSK
2. Signer la zone
3. Configurer Bind9 pour valider
4. Publier les DS au registre parent

Étape 1 : Générer les clés

Rendez-vous dans le répertoire de configuration de Bind :

cd /etc/bind/keys

Générez la clé de signature de zone (KSK) — 4096 bits pour la sécurité :

dnssec-keygen -a ECDSAP256SHA256 -b 2048 -f KSK example.com

Générez la clé de zone (ZSK) — 2048 bits, suffisant :

dnssec-keygen -a ECDSAP256SHA256 -b 2048 example.com

Vous obtenez deux fichiers .key et .private pour chaque clé :

Kexample.com.+007+12345.key       (KSK public)
Kexample.com.+007+12345.private   (KSK private)
Kexample.com.+007+54321.key       (ZSK public)
Kexample.com.+007+54321.private   (ZSK private)

Étape 2 : Signer la zone

Incluez les clés publiques dans votre zone :

cat Kexample.com.+007+*.key >> /etc/bind/zones/db.example.com

Signez la zone avec dnssec-signzone :

dnssec-signzone -o example.com -k Kexample.com.+007+12345.key \
  /etc/bind/zones/db.example.com Kexample.com.+007+54321.key

Cela crée /etc/bind/zones/db.example.com.signed avec toutes les signatures RRSIG.

Étape 3 : Configurer Bind9

Mettez à jour /etc/bind/named.conf.local :

zone "example.com" {
    type master;
    file "/etc/bind/zones/db.example.com.signed";

    # Nouvelles clés de zone
    auto-dnssec maintain;
    inline-signing yes;

    # Permet à Bind de re-signer automatiquement
    dnssec-policy default;
};

Avec auto-dnssec maintain et inline-signing yes, Bind9 gère automatiquement la rotation des clés et la signature en mémoire.

Redémarrez Bind :

systemctl restart bind9
systemctl status bind9

Étape 4 : Publier le DS au registre

Extrayez le digest DS de votre clé KSK :

dnssec-dsfromkey Kexample.com.+007+12345.key

Résultat (exemple) :

DS 12345 7 2 8B7C3A9E1F2D4E6A8C9B0D1E2F3A4B5C6D7E8F

Connectez-vous à l'interface de gestion de votre registre (Gandi, OVH, etc.) et ajoutez ce DS record. C'est l'étape critique — sans elle, DNSSEC ne valide pas.

Vérification basique avec dig

dig @ns1.example.com example.com A +dnssec

Cherchez des flags ad (Authenticated Data) dans la réponse. Si absent, la validation a échoué.

Vérifiez les signatures RRSIG :

dig @ns1.example.com example.com RRSIG +short

Validation côté client avec delv

delv (DNSSEC Lookaside Validation) valide une réponse en remontant toute la chaîne :

delv +root=/etc/bind/root.key @127.0.0.1 example.com A

Résultat en cas de succès :

; delv +root=/etc/bind/root.key @127.0.0.1 example.com A
; fully validated
example.com.        3600    IN  A   192.0.2.1

En cas d'erreur :

error: SERVFAIL

Diagnostiquer les certificats expirés

Les signatures RRSIG ont une date d'expiration. Vérifiez :

dig example.com RRSIG +short | grep -oP 'Signature expiration: \K[^ ]+'

ou plus simplement, re-signez régulièrement avec :

dnssec-signzone -o example.com /etc/bind/zones/db.example.com

Outils en ligne

• https://dnssec-analyzer.verisignlabs.com/ — Analyse complète de votre DNSSEC
• https://dnsviz.net/ — Visualisation graphique de la chaîne de confiance
• https://www.zonemaster.net/ — Audit complet de zone

Calendrier de rotation

• KSK — Changez tous les 2 à 3 ans (faible rotation, il faut mettre à jour le registre)
• ZSK — Changez tous les 6 à 12 mois (haute rotation, interne)

Avec auto-dnssec et inline-signing, Bind9 gère les pré-publications automatiquement.

Timing critique

Quand vous changez une ZSK :

1. La nouvelle clé est publiée (période de pré-publication : généralement 2 semaines)
2. Les anciens records restent signés avec l'ancienne clé pendant le TTL max
3. Après le TTL, les records sont signés avec la nouvelle clé

Pour les KSK, la rotation est plus délicate — il faut mettre à jour le DS au registre.

Surveillance

Mettez en place une alerte pour les signatures proches de l'expiration :

#!/bin/bash
for sig in $(dig example.com RRSIG +short | grep -oP 'Signature expiration: \K[^ ]+'); do
  expire=$(date -d "$sig" +%s)
  now=$(date +%s)
  days=$((($expire - $now) / 86400))
  if [ $days -lt 30 ]; then
    echo "ALERTE: Signature expire dans $days jours"
  fi
done

Sauvegarde des clés privées

Protégez vos clés privées avec des permissions restrictives :

chmod 600 /etc/bind/keys/*.private
chown bind:bind /etc/bind/keys/*

Envisagez un HSM (Hardware Security Module) pour les environnements critiques.

Pour approfondir votre infrastructure DNS sécurisée :

• Configuration DNS avec Bind9 — Fondamentaux, zones, ACLs
• Dépannage et diagnostics DNS — Outils et troubleshooting avancé
• Résolveurs validants avec Unbound — Recurseurs sécurisés et caching DNSSEC

Les données et recommandations de ce guide proviennent de :

• APNIC DNSSEC Statistics — https://stats.labs.apnic.net/dnssec — Taux de validation mondial, par TLD et région
• SIDN DNSSEC Report — https://www.sidn.nl/en/news-and-blogs/dnssec-adoption-heavily-dependent-on-incentives-and-active-promotion — Analyse des facteurs d'adoption en Europe
• RFC 4034 (DNSSEC) & RFC 5034 — Standards officiels IETF
• ISC Bind9 Documentation — https://bind9.readthedocs.io/ — Configuration, DNSSEC, auto-signing
• Verisign DNSSEC Suite — Outils et analytics

DNSSEC n'est plus une option. Avec 35% de validation mondiale, l'asymétrie de sécurité s'aggrave — vos utilisateurs en zones DNSSEC-validantes reçoivent une protection, d'autres non. Signer votre zone prend moins d'une heure et renforce la confiance de tous vos usagers.

Chez SHPV, nous accompagnons la gestion complète de vos résolutions DNS, y compris la mise en place de DNSSEC, la surveillance des rotations de clés, et l'intégration avec vos services d'infrastructure. Si votre infrastructure DNS critique a besoin d'audit ou de déploiement DNSSEC 👉 contactez nos experts infogérance.

La chaîne de confiance commence par une signature. Commencez dès aujourd'hui.