Domain Name System Security Extensions
| Fonction | Garantir l'authenticité et l'intégrité des réponses DNS. |
|---|---|
| Sigle | DNSSEC |
| Date de création | mars 2005 |
| RFC | RFC 4033[1], RFC 4034[2], RFC 4035[3] |
DNSSEC (« Domain Name System Security Extensions ») est un ensemble d'extensions du système de noms de domaine (DNS) visant à garantir l'authenticité et l'intégrité des données DNS. Standardisé par l'IETF, DNSSEC permet à un résolveur de vérifier qu'une réponse DNS provient bien de la zone faisant autorité et qu'elle n'a pas été modifiée lors de son acheminement.
DNSSEC ne chiffre pas les requêtes DNS et n'assure pas la confidentialité des échanges. Son objectif est uniquement d'empêcher la falsification des réponses DNS.
Historique
[modifier | modifier le code]Le protocole DNS a été conçu dans les années 1980, à une époque où Internet reposait sur un modèle de confince relativement simple. Aucune protection cryptographique n'était prévue pour les réponses DNS, ce qui a progressivement conduit à l'apparition de nombreuses attaques, notamment les attaques par empoisonnement de cache (DNS cache poisoning[4])
Les premières spécifications de DNSSEC apparaissent à la fin des années 1990. Elles seront ensuite profondément révisées afin de simplifier leur déploiement et d'améliorer leur compatibilité. Aujourd'hui, DNSSEC est largement déployé sur les domaines de premier niveau (TLD) et peut être activé par les administrateurs de zone faisant autorité[5].
Le registre suédois a été le premier à signer un domaine de premier niveau (TLD) avec DNSSEC en 2007. Début 2010, environ une dizaine de TLD sont signés et beaucoup d'autres ont annoncé leur intention de le faire à court terme[6].
En , la racine du DNS commence à être signée avec la technologie DNSSEC. Ce processus s'est étalé jusqu'en [7].
Caractéristiques
[modifier | modifier le code]DNSSEC garantie l'authenticité et l'intégrité des échanges ainsi que l'authentification de l'inexistence en prouvant qu'un enregistrement DNS n'existe pas. Contrairement à d'autres protocoles comme TLS, il ne chiffre pas les requêtes DNS et ne garantit pas la confidentialité des échanges.
DNSSEC repose sur la cryptographie asymétrique . Chaque zone DNS possède une ou plusieurs paires de clés cryptographiques:
- Une clé privée, utilisée pour signer les enregistrements DNS.
- Une clé publique, publiée dans la zone afin que les résolveurs puissent vérifier les signatures.
Les signatures sont calculées lors de la génération ou de la mise à jour de la zone et sont publiés sous forme d'enregistrements DNS supplémentaires.
Lorsqu'un résolveur compatible DNSSEC reçoit une réponse, il vérifie la signature numérique à l'aide de la clé publique de la zone. Si la signature est valide, la réponse est considérée comme authentique. Dans le cas contraire, elle est rejetée.
Chaine de confiance
[modifier | modifier le code]L'un des principes fondamentaux de DNSSEC est la chaine de confiance (Chain of Trust).

Chaque zone publie une clé publique qui est validée par la zone parente. Cette dernière contient un enregistrement DS (Delegation Signer) correspondant à l'empreinte cryptographique de la clé de la zone enfant.
Le processus commence par une clé de confiance intégrée au résolveur, appelée Trust Anchor, correspondant à la clé de la zone racine (".").
La validation suit alors les étapes suivantes:
- Le résolveur fait confiance à la clé de la zone racine
- La racine valide le TLD (.fr, .com, .org, etc..)
- Le TLD valide le domaine (example.com, wikipedia.org)
- Le domaine valide ses propres enregistrements
Si l'une de ces étapes échoue, la réponse DNS est considérée comme non valide.
Types d'enregistrements DNSSEC
[modifier | modifier le code]DNSSEC introduit plusieurs nouveaux types d'enregistrements DNS
| Type | Contenu | Informations supplémentaires |
|---|---|---|
DNSKEY |
Clé publique de la zone | Cette clé permet aux résolveurs de vérifier les signatures numériques publiées dans la zone. |
RRSIG |
Signature cryptographique d'un ensemble d'enregistrements DNS (RRsets) | Chaque type d'enregistrement possède sa propre signature. |
DS |
Empreinte cryptographique de la clé publique de la zone enfant. | Publié dans la zone parente, il permet d'établir la chaîne de confiance. |
NSEC |
Permet de prouver cryptographiquement qu'un nom ou un type d'enregistrement n'existe pas dans une zone. Il relie chaque nom de domaine au suivant dans l'ordre canonique de la zone | |
NSEC3 |
Evolution de NSEC qui remplace les noms de domaine par leur empreinte, limitant ainsi les attaques d'énumération de zone. |
Signature des zones
[modifier | modifier le code]La signature d'une zone consiste à générer les enregistrements RRSIG à partir des données DNS. A chaque modification de la zone (ajout, suppression ou modification d'un enregistrement), les signatures concernées doivent être régénérées.
La plupart des serveurs DNS modernes, tels que KnotDNS, BIND, NSD ou PowerDNS sont capables d'effectuer cette opération automatiquement.
Algorithmes cryptographiques
[modifier | modifier le code]Depuis sa standardisation, DNSSEC a pris en charge plusieurs algorithmes de cryptographie asymétrique destinés à la signature numérique des données DNS. Ces algorithmes sont identifiés par un numéro attribué par l'Internet Assigned Numbers Authority (IANA) et sont définis par différentes RFC publiées par l'Internet Engineering Task Force (IETF).
Les premières versions de DNSSEC reposaient principalement sur des algorithmes de la famille RSA, qui bénéficiaient d'un large support logiciel et matériel. Des algorithmes fondés sur DSA ont également été standardisés, mais leur adoption est restée limitée et ils sont aujourd'hui considérés comme obsolètes.
L'évolution des techniques cryptographiques a conduit à l'introduction d'algorithmes reposant sur la cryptographie à courbes elliptiques, notamment ECDSA puis EdDSA. Ceux-ci offrent un niveau de sécurité comparable à celui de RSA avec des clés et des signatures de plus petite taille, tout en réduisant le coût des opérations cryptographiques.
Au fil des années, plusieurs algorithmes historiques ont été abandonnés ou déconseillés à la suite des progrès de la cryptanalyse. Les algorithmes reposant sur MD5 ou SHA-1 ne sont ainsi plus recommandés pour les nouveaux déploiements. Les recommandations actuelles de l'IETF privilégient les algorithmes RSA/SHA-256, ECDSA P-256 et Ed25519, tandis que les autres algorithmes demeurent principalement pris en charge pour assurer la compatibilité avec les infrastructures existantes.
Le tableau suivant présente les principaux algorithmes de signature normalisées pour DNSSEC définis dans la RFC 8624 ainsi que les recommandations d'implémentation pas les logiciels DNSSEC.
| Algorithme | N° IANA | Type de clé | RFC | Signature | Validation |
|---|---|---|---|---|---|
| RSA/MD5 | 1 | RSA | RFC 2537 | Interdit | Interdit |
| DSA | 3 | DSA | RFC 2536 | Interdit | Interdit |
| RSA/SHA1 | 5 | RSA | RFC 3110 | Déconseillé | Obligatoire |
| DSA-NSEC3-SHA1 | 6 | DSA | RFC 5155 | Interdit | Interdit |
| RSA/SHA1-NSEC3-SHA1 | 7 | RSA | Déconseillé | Obligatoire | |
| RSA/SHA256 | 8 | RSA | RFC 5702 | Obligatoire | Obligatoire |
| RSA/SHA512 | 10 | RSA | Déconseillé | Obligatoire | |
| ECC-GOST | 12 | ECC | RFC 5933 | Interdit | Optionnel |
| ECDSAP256/SHA256 | 13 | ECDSA | RFC 6605 | Obligatoire | Obligatoire |
| ECDSAP384/SHA384 | 14 | ECDSA | Optionnel | Recommandé | |
| ED25519 | 15 | EdDSA | RFC 8080 | Recommandé | Recommandé |
| ED448 | 16 | EdDSA | Optionnel | Recommandé |
Rotation des clés
[modifier | modifier le code]Pour des raisons de sécurité, les clés DNSSEC doivent être renouvelées régulièrement. Cette opération est appelée Key Rollover. Elle consiste à remplacer progressivement une clé existante tout en maintenant la chaîne de confiance afin d'éviter toute interruption de validation. Les serveurs DNS modernes automatisent généralement cette procédure.
Le renouvellement de la Root Key Signing Key (Root KSK) de la zone racine constitue l'exemple le plus emblématique d'un Key Rollover. Cette opération est coordonnée par l'IANA et l'ICANN, selon un calendrier publié à l'avance et accompagné de cérémonies de signature publiques. Le premier renouvellement de la Root KSK a été réalisé avec succès en 2018, après plusieurs années de préparation. Afin d'assurer la continuité de la chaîne de confiance, les résolveurs compatibles DNSSEC mettent à jour automatiquement leur ancre de confiance grâce au mécanisme défini par la RFC 5011.
Validation côté résolveur
[modifier | modifier le code]Tous les résolveurs DNS ne valident pas DNSSEC. Un résolveur validant récupère les signatures DNSSEC, vérifie la chaîne de confiance jusqu'à la racine et n'accepte que les réponses dont la signature est valide.
En cas d'échec de validation, le résolveur renvoie généralement une erreur SERVFAIL au client.
Limitations
[modifier | modifier le code]Bien que DNSSEC améliore significativement la sécurité du DNS, il présente plusieurs limites.
Le protocole n'empêche pas l'interception des requêtes DNS, augmente la taille des réponses DNS ce qui favorise parfois l'utilisation d'EDNS ou du protocole TCP. Il ajoute aussi une complexité opérationnelle liée à la gestion des clés et des signatures et nécessite que le résolveur effectue la validation pour que la protection soit effective.
Normalisation et déploiement
[modifier | modifier le code]Aujourd'hui, la quasi-totalité des domaines de premier niveau (TLD) sont signés avec DNSSEC. De nombreux registres et bureaux d'enregistrement permettent également aux titulaires de domaines d'activer DNSSEC simplement en publiant un enregistrement DS auprès du registre.
La validation est désormais activée par défaut sur la majorité des résolveurs DNS publics et de nombreux résolveurs opérés par les fournisseurs d'accès à Internet.
Notes et références
[modifier | modifier le code]- ↑ (en) Request for comments no 4033
- ↑ (en) Request for comments no 4034
- ↑ (en) Request for comments no 4035
- ↑ « Domain names - concepts and facilities », IETF, Internet Engineering Task Force, no RFC 1034, (lire en ligne, consulté le )
- ↑ Donald E. Eastlake 3rd et Charles W. Kaufman, « Domain Name System Security Extensions », IETF, Internet Engineering Task Force, no RFC 2065, (lire en ligne, consulté le )
- ↑ (en-US) « DNSSEC », sur Internetstiftelsen (consulté le )
- ↑ ISC Praises Momentous Step Forward in Securing the Domain Name System, ISC, 15 juillet 2010
- ↑ Paul Wouters et Ondřej Surý, « Algorithm Implementation Requirements and Usage Guidance for DNSSEC », IETF, Internet Engineering Task Force, no RFC 8624, (lire en ligne, consulté le )
Voir aussi
[modifier | modifier le code]Liens externes
[modifier | modifier le code]- Présentation de DNSSEC
- DNSSEC pour le domaine national de premier niveau
.se - Calendrier de déploiement de DNSSEC au niveau de la racine
- Sécuriser les communications sur Internet de bout-en-bout avec le protocole DANE
- Déployer DNSSEC comment, quoi, où ?
- Testez si vous êtes protégé par la validation de signature DNSSEC. Une initiative de la communauté Internet et du gouvernement néerlandais.
- Domain Name System
- DNS over TLS
- DNS over HTTPS
- EDNS
- RFC 4033
- RFC 4034
- RFC 4035