DNSSEC – Extensions de sécurité du protocole DNS – Améliorations apportées au protocole conçues pour
être interopérables avec les implémentations DNS qui ne proposent pas ces améliorations. L’IETF a exploité
le fait que les RR (Resource Record) avaient été prévus pour être extensibles à de nouveaux RR. L’IETF a
défini un nouveau système de RRs pour les informations relatives à la sécurité et apporter une
authentification forte des zones DNS voulant implémenter DNSSEC. Ces enregistrements s’ajoutent aux RRs
existant, cela permet à des serveurs n’ayant pas de fonctions DNSSEC de répondre aux requêtes d’une
zone sécurisée par DNSSEC.
De façon à être massivement adopté, le groupe de travail DNSSEC de l’IETF permet une compatibilité totale
avec les serveurs et clients DNS antérieurs. En mars 1997, l’IAB (Internet Architecture Board) s’est réuni
pour discuter de l’architecture sécurisée d’Internet. Cette réunion a permis d’identifier des mécanismes
sécurisés et d’autres en développement, pas encore standardisés, pouvant jouer un rôle dans l’architecture
sécurisée d’Internet. Un des protocoles majeurs était DNSSEC qui permettait de résoudre le problème de
cache empoisonné (Cache Poisoning) [RFC 2316].
Les objectifs de DNSSEC
Un des principes fondamentaux de DNS est d’être un service public. Il requiert des réponses correctes aux
requêtes mais les données sont considérées comme étant publiques. Ainsi, les besoins d’authentification et
d’intégrité existent, mais pas le contrôle d’accès ni la confidentialité. L’authentification et l’intégrité des
informations contenues dans les zones DNS sont fournies par l’utilisation de signatures cryptées par un
système de clés publiques.
Les clients et serveurs implémentant DNSSEC peuvent alors garantir l’authenticité des données reçues ainsi
que le fait de ne pas avoir été altérées.
Même si le groupe de travail DNSSEC n’a pas choisi d’intégrer la confidentialité pour les transactions DNS, il
est possible d’utiliser les clés publiques que fournit DNS dans des applications de niveau supérieur pour
garantir la confidentialité. Les PKI pourraient alors jouer un rôle pour stocker les clés publiques.
Etendue de DNSSEC
L’intérêt de DNSSEC s’étend à trois services : la distribution de clés, l’authentification de l’origine des
données et l’authentification des transactions et requêtes.
- Distribution de clés : ce service permet de rapatrier la clé publique d’une entrée DNS pour vérifier
l’authenticité des données de la zone DNS ; mais il permet également d’apporter des nouvelles fonctions
avec lesquelles les clés associées aux entrées DNS peuvent être utilisées dans un autre but que DNS. Les
PKI permettent de supporter différents types de clés ainsi que divers algorithmes de génération de clés.
- Authentification de l’origine des données : c’est le principal objectif de la mise au point de DNSSEC. Il
réduit nettement la possibilité de Cache Poisoning : les divers RRs sont en effet signés. La signature
électronique contient le hash crypté d’un RR. Ce hash est signé (crypté) par la clé privée du serveur origine.
Le destinataire vérifie ensuite la validité des données reçues avec la signature associée au RR. Il décrypte
le hash avec la clé publique du signataire puis crée son propre hash des données reçues en utilisant le
même algorithme et compare ensuite les deux valeurs de hash. Si les deux valeurs sont identiques, les
données sont intègres et l’origine est authentifiée.
- Authentification des requêtes et transactions DNS : cela permet de garantir que la réponse à une requête
correspond bien à la question et que cette réponse provient bien du serveur duquel on l’attendait. La
réponse et la requête sont signées et la signature est également renvoyée avec la réponse. Une autre
utilisation de DNSSEC concerne DDNS où les mises à jour dynamiques du DNS se font avec
authentification forte [RFC 2137].
Les enregistrements de ressources DNSSEC
L’IETF a créé plusieurs nouveaux RRs pour supporter les nouvelles fonctions de sécurité de DNSSEC. Les
plus importants sont les RRs KEY, SIG et NXT. Le RR KEY est utilisé pour stocker les clés publiques, une
clé publique par RR KEY. C’est ce RR qui est utilisé pour vérifier la signature d’un champ d’un RR. La
signature est stockée dans un le RR SIG ; elle est utilisée pour prouver l’authenticité et l’intégrité des
données contenues dans un champ d’un RR. Le RR NXT (pour nonexistent) est utilisé pour certifier la nonexistence
d’un champ d’un RR.
Il existe également un autre RR, le RR CERT mais il n’apporte pas de fonctionnalités de sécurité
supplémentaires à DNS. Il est en fait utilisé pour les applications au-dessus de DNS pour stocker les
certificats de clé publique [RFC 2538]. De la même façon qu’une application génère une requête de type A
pour résoudre un nom d’hôte, une application sécurisée voulant discuter de manière cryptée avec une autre
génère une requête CERT pour rapatrier le certificat de clé publique de l’autre entité. Une première
application est le projet LADON17, qui intègre DNSSEC pour l’authentification avec SSH (Secure Shell, un
protocole sécurisé très utilisé dans le monde Unix remplaçant telnet, pouvant servir de VPN).
- RR KEY : La clé d’un nom DNS est contenue dans un RR KEY. Tout type de requête sur un nom DNS,
contenu dans une zone sécurisée, génère une réponse contenant les informations demandées. Le RR KEY
associé au nom DNS fait partie de la réponse. Le resolver reçoit ainsi les deux informations permettant la
validation sans avoir besoin de générer une requête supplémentaire pour rapatrier la clé. Le RR KEY
contient des informations relatives (dans la section RDATA) aux caractéristiques de la sécurité mise en
oeuvre ainsi que l’utilisation autorisée pour le propriétaire. Il comporte ainsi le type d’algorithme, la clé
publique, le type de protocole et des flags pour indiquer si le nom DNS possède ou non une clé publique par
exemple. Plusieurs algorithmes sont supportés comme RSA/MD5, Diffie-Hellman, DSA (Digital Signature
Algorithm) et les algorithmes à courbe elliptique. Seul le support de DSA est requis. Le champ protocole sert
à indiquer pour quel type de protocole la clé publique est supportée : TLS (Transport Layer Security), email,
DNSSEC et IPsec sont déjà supportés, les autres valeurs (5 à 254) restent libres d’être attribuées par
l’ICANN.
- RR SIG : La signature est contenue dans le RR SIG. Il permet l’authentification d’un RR et fournit
l’expiration de la signature. Dans une zone sécurisée, à un RR peuvent être associés plusieurs RR SIG ; en
effet, certains sites situés dans des pays où il existe des restrictions à l’exportation de matériel
cryptographique peuvent choisir entre plusieurs algorithmes pour effectuer la signature. De même que le RR
KEY, la partie RDATA du RR SIG contient des informations sur le type d’algorithme utilisé, le type de RR
signé, ainsi que plusieurs champs relatifs à l’expiration.
- RR NXT : Le système DNS fournit la possibilité de cacher des réponses négatives. Une réponse négative
indique qu’un RR n’existe pas pour une requête. DNSSEC permet de signer la nonexistence de ces RRs
afin que la non-existence dans une zone puisse être authentifiée.
Toutes ces fonctionnalités impliquent des responsabilités supplémentaires pour les serveurs DNS
implémentant DNSSEC. En effet, s’ajoutent aux fonctions de base d’un serveur DNS (gérer les informations
de la zone sur laquelle il a autorité, gérer le cache DNS, répondre aux requêtes des clients) la gestion des
clés privées [RFC 2541] qui doivent être inaccessibles en dehors du serveur DNS lui-même (on remarque
que ces clés privées ne sont générées qu’une seule fois, à la création du couple clé privé/clé publique donc il
faut faire attention à ne pas être intercepté lors de la création de ces clés), la gestion de l’expiration des RRs
SIG en concurrence avec le TTL originel du système DNS (le TTL est néanmoins conservé pour la
compatibilité ascendante).