DNSSEC

Aujourd’hui, nous allons nous intéresser à l’extension DNSSEC du protocole DNS qui tarde à être déployée massivement, alors même que l’ICANN incite tous les acteurs intervenant dans la mise en place du DNS de la mettre en œuvre afin d’augmenter considérablement la sécurité et la sûreté de l’Internet dans sa globalité. Aussi, pour comprendre l’intérêt du déploiement de cette extension, il est indispensable de comprendre pour quelles raisons celle-ci fût imaginée et pourquoi il est aujourd’hui important de la déployer dans un soucis de sécurisation des systèmes d’information.

Le problème

Le fond du problème est que le protocole DNS, pour diminuer la latence, et la charge du serveur, utilise essentiellement le protocole de transport UDP. Ce protocole ne nécessite pas d’établissement de connexion avant d’échanger les données.

Cela implique que si l’adresse IP source est mensongère, il n’y a pas de moyen de le détecter. Le protocole de transport TCP n’a pas le même problème puisque l’attaquant qui utiliserait une adresse mensongère ne recevrait pas les réponses et ne pourrait donc pas compléter la connexion. Cela permet plusieurs attaques sur le système DNS comme l’attaque par empoisonnement, où l’attaquant va essayer de répondre à la place du serveur légitime. L’idée de cette attaque est très simple : à partir du moment où un serveur DNS récursif essaye de résoudre un nom de domaine en interrogeant un autre résolveur, l’attaquant répond avec son propre paquet UDP contenant les réponses qu’il désire afin de détourner le futur traffic de sa cible sur ses propres serveurs. Pour que la réponse soit acceptée par le résolveur, il faut que l’attaquant reproduise certaines caractéristiques de la réponse attendue, notamment l’identificateur de la requête, l’adresse IP source et le port source. Cette attaque, et ses probabilités de réussite, est décrite en détail dans le RFC 5452.

La faille Kaminsky, annoncée en juillet 2008, augmente brutalement les chances de succès de cette attaque en utilisant non plus des noms réels, qui font que, si l’attaque rate, la bonne information se retrouve dans le cache, bloquant l’assaillant jusqu’à l’expiration du TTL, mais des noms inexistants. Kaminsky a transformé une attaque bien connue mais assez théorique et lointaine, en une vulnérabilité immédiate.

La parade fût elle aussi immédiate, et l’idée retenue fût de rendre aléatoire la dernière variable qui ne l’était pas : le port source. Ce fut la SPR (Source Port Randomization), déployée massivement à l’été 2008, documentée après coup dans le RFC 5452.

Une solution plus robuste

Les autres idées pour accroître l’entropie de la requête ne permettant plus vraiment de diminuer les chances d’éviter une telle attaque, l’extension DNSSEC est devenu la seule parade envisageable.

En effet, DNSSEC ajoutent deux importantes fonctions au protocole du DNS :

• L’authentification de l’origine des données, qui permet au résolveur de vérifier cryptographiquement que les données qu’il a reçues proviennent bien de la zone qu’il pense être la source des données.
• La protection de l’intégrité des données, qui permet au résolveur de savoir que les données n’ont pas été modifiées en transit puisqu’elles ont été signées à l’origine par le propriétaire de la zone avec la clé privée de la zone.

DNSSEC protège donc les données et non pas le canal de communication. Il assure la vérification de l’origine des données. DNSSEC garantit la possibilité de vérifier qu’un résolveur n’a pas été trompé par un intermédiaire, et que les données sont bien comme à l’origine. DNSSEC ne fournit donc pas de service de confidentialité et ne protège pas l’intégralité de la session utilisateur. Cela signifie simplement que DNSSEC protège de bout en bout. Les techniques de sécurité qui protègent le canal de communication, comme peut le faire le protocole TLS, sont en général plus simples à déployer mais ne protègent pas contre un intermédiaire non fiable. Ainsi, avec SMTP sur TLS, si le courrier est relayé par un serveur de messagerie qui triche, par exemple en modifiant le message, TLS n’empêchera rien. Aussi, il est important de comprendre que si DNSSEC permet d’authentifier le serveur DNS faisant autorité au travers de ses réponses, il n’assure pas la véracité des données qu’elles contiennent !

À souligner également, que le DNSSEC est une extension du protocole DNS, et par conséquent ne modifie pas son fonctionnement. Ainsi, DNSSEC peut fonctionner au travers d’un cache non modifié, et un client ne supportant pas l’extension DNSSEC peut interagir avec un serveur ayant déployé DNSSEC. Et réciproquement. Il n’y a donc, à priori, aucune raison de ne pas le déployer.

Fonctionnement

Pour assurer l’authentification de l’origine et l’intégrité des données, DNSSEC repose sur la cryptographique asymétrique. DNSSEC apporte à une zone DNS donnée des signatures cryptographiques aux enregistrements existants. Ces signatures numériques sont stockées dans les serveurs DNS faisant authorité à côté des types d’enregistrements couramments utilisés. En contrôlant la signature associée, il est alors possible pour un résolveur DNS de vérifier qu’un enregistrement DNS demandé provient du serveur DNS faisant autorité et qu’il n’a pas été modifié en cours de route, contrairement à un faux enregistrement injecté lors d’une attaque de type MITM.

Pour faciliter la validation des signatures, l’extension DNSSEC ajoute quelques nouveaux types d’enregistrements DNS :

• RRSIG – Contient une signature cryptographique
• DNSKEY – Contient une clé de signature publique
• DS – Contient le condensat d’un enregistrement DNSKEY.
• NSEC et NSEC3 – Pour le déni explicite d’existence d’un enregistrement DNS.
• CDNSKEY et CDS – Pour une zone enfant demandant des mises à jour des enregistrements DS de la zone parent.

Clés de signature de zone et clés de signature de clé

Le fonctionnement de DNSSEC repose sur l’usage d’une ou plusieurs paires de clés cryptographiques. On trouve ainsi la clé privée KSK (Key-Signing Key) et la clé privée ZSK (Zone-Signing Key). Cependant, on peut très bien n’avoir qu’une seule clé CSK (Combined Signing Key), mais l’usage de plusieurs paires de clés accroît la souplesse de gestion des rotations induite par l’approche d’une date d’expiration ou la compromission d’une clé.

Chaque zone DNS ayant déployée DNSSEC possède ainsi une paire de clés de signature de zone ZSK : la clé privée est utilisée pour signer numériquement chaque regroupement RRsets d’enregistrements d’un même type, tandis que la clé publique est utilisée pour vérifier la signature précédement obtenue. Pour activer le DNSSEC, un administrateur de zone doit donc générer des signatures numériques pour chaque RRset en utilisant la clé ZSK privée avant de les stocker dans la zone en tant qu’enregistrements RRSIG.

Puisque les résolveurs DNS ne disposent pas d’un moyen de vérifier les signatures contenues dans les enregistrements RRSIG, l’administrateur de zone doit donc également rendre la clé ZSK publique disponible en l’ajoutant à la zone dans un enregistrement DNSKEY.

Ainsi, lorsqu’un résolveur DNSSEC demande un type d’enregistrement particulier pour une zone donnée, le serveur DNS faisant authorité sur cette zone renvoie également l’enregistrement RRSIG correspondant. Le résolveur DNSSEC peut alors extraire de la zone l’enregistrement DNSKEY contenant la clé ZSK publique. Une fois le RRset correspondant au type réclamé, le RRSIG et la clé ZSK publique récupérés, le résolveur DNSSEC est en mesure de pouvoir valider ou invalider la réponse reçue.

Le logiciel dig permet d’interroger facilement un résolveur DNSSEC grâce à l’option +dnssec. Nous allons par exemple analyser la zone afnic.fr. gérée par l’AFNIC en charge de gérer le domaine Internet national de premier niveau de la France (.fr) en interrogeant le résolveur DNSSEC du fournisseur d’accès à Internet associatif FDN.

Par une première requête, nous allons réclamer la valeur de l’enregistrement de type A pour le nom de domaine afnic.fr.

$ dig @ns0.fdn.fr +dnssec afnic.fr A

; <<>> dig 9.10.8-P1 <<>> @ns0.fdn.fr +dnssec afnic.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59665
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;afnic.fr.                      IN      A

;; ANSWER SECTION:
afnic.fr.               600     IN      A       192.134.5.37
afnic.fr.               600     IN      RRSIG   A 13 2 600 20210801220645 20210702170836 43110 afnic.fr. OkycYVLGpQrSgNuxn9Yjq6DadLtDh6XOzv0WBuoc4Y01Q9CIbIfht2CP ZaK1G5VV1qLA1hwiCIxwbziHzyn3uw==

;; Query time: 24 msec
;; SERVER: 80.67.169.12#53(80.67.169.12)
;; WHEN: Fri Jul 09 17:24:03 CEST 2021
;; MSG SIZE  rcvd: 157

On peut remarquer plusieurs choses. D’une part, en plus de l’enregistrement de type A demandé, la réponse contient un enregistrement RRSIG qui n’est autre que la signature de l’enregistrement A par la clé ZSK privée de l’administrateur de la zone afnic.fr.. D’autre part, le flag ad (Authentic Data) indique que le résolveur DNSSEC estime que les réponses sont authentiques, c’est-à-dire validées par le système DNSSEC. Cela signifique que le résolveur DNSSEC de FDN a été en mesure de récupérer la clé ZSK publique depuis l’enregistrement DNSKEY de cette même zone, puis de vérifier que la signature contenue dans l’enregistrement RRSIG était valide.

Seulement, si nous faisons confiance à la clé ZSK publique récupérée dans l’enregistrement DNSKEY, nous pouvons faire confiance à tous les enregistrements de la zone, auquel cas les signatures non plus raison d’être. Nous avons donc besoin d’un autre moyen qui nous permette de pouvoir vérifier l’authenticité de la clé ZSK publique.

De ce fait, en plus d’une paire de clés de signature de zone ZSK, les serveurs de noms DNSSEC possèdent également une paire de clé de signature de clés KSK (Key Signing Key). La paire de clés KSK permet d’assurer l’authenticité de l’enregistrement DNSKEY exactement de la même manière que la paire de clé ZSK permet de sécuriser le reste des RRsets. La clé KSK privée signe la clé ZSK publique qui est stockée dans un enregistrement DNSKEY, en créant un RRSIG.

Tout comme pour la clé ZSK publique, le serveur de noms faisant authorité publie la clé KSK publique dans un autre enregistrement DNSKEY.

En reprennant l’exemple précédent, on peut demander à récupérer les clés publiques ZSK et KSK associées à la zone afnic.fr..

$ dig @ns0.fdn.fr +dnssec afnic.fr DNSKEY

; <<>> dig 9.10.8-P1 <<>> @ns0.fdn.fr +dnssec afnic.fr DNSKEY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21506
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;afnic.fr.                      IN      DNSKEY

;; ANSWER SECTION:
afnic.fr.               86367   IN      DNSKEY  257 3 13 Jj7sU0efcgyyjrOV9l2LSJUGdzly/DxDP9REsSOSrmdLtH2gsEr1P4bi 03bX4LoFqE86cBMqbLr3kJwXs6CGPw==
afnic.fr.               86367   IN      DNSKEY  256 3 13 9OwANVvVCTVl4Jj/5SWJkCbUOw4xXEftnqiKty3rogn/j2tG6PmXYbWT JhAoXq97GsWyFfnXsZp/eaDY1c+T6A==
afnic.fr.               86367   IN      DNSKEY  256 3 13 epWv1hDpRM7nsITic3L3xq+3LMOYgyS7SK0r8HSw+v1FbTaDwc8JS6VA NKGq7x38Lr1m1DX2177PofQ09weGZQ==
afnic.fr.               86367   IN      RRSIG   DNSKEY 13 2 172800 20210807111842 20210708070739 21858 afnic.fr. Vx5yCXbFJ2LFkrX4eAw1yTP1PFk7uB5lCeBXHC7N3BxlO7hPL6hro39w opon9FXJU1p0+/aTD1dKDUF4Ba6cKQ==

;; Query time: 23 msec
;; SERVER: 80.67.169.12#53(80.67.169.12)
;; WHEN: Fri Jul 09 17:22:44 CEST 2021
;; MSG SIZE  rcvd: 381

On a ainsi pu récupérer plusieurs clés publiques, elles mêmes signées par la clé KSK privée comme en atteste l’enregistrement RRSIG dans la réponse. Dans l’enregistrement DNSSKEY, une valeur de 256 indique que l’enregistrement contient la clé ZSK publique et une valeur de 257 indique qu’il contient la clé KSK publique. Nous avons donc ici deux clés ZSK publiques et une clé KSK publique.

Au même titre que précédemment, la confiance établie dans la récupération de la bonne clé KSK publique pour vérifier l’authenticité de la clé ZSK publique ne peut être suffisament garantie.

Nous avons besoin d’un moyen de propager la confiance au-delà de la zone DNS. Bien heureux nous sommes puisque le système DNS est une système, certes décentralisé, mais avant tout hiérarchique ! DNSSEC permet de mettre en place une chaîne de confiance en propageant la confiance au-delà de la zone d’une enregistrement donné.

Enregistrements signataires de délégation

DNSSEC introduit un enregistrement DS (Delegation Signer) pour permettre la propagation de la confiance d’une zone parent à une zone enfant. Un administrateur calcule le condensat de l’enregistrement DNSKEY contenant la clé KSK publique de la zone DNS qu’il gère et le donne à l’administrateur de la zone DNS parent pour que celui-ci soit publié dans un enregistrement DS.

Ainsi, chaque fois qu’un résolveur DNSSEC est dirigé vers une zone enfant, la zone parent fournit également un enregistrement DS. C’est par ailleur grâce à cet enregistrement DS que les résolveurs DNSSEC savent que la zone enfant est compatible avec l’extension DNSSEC. Pour vérifier la validité de la clé KSK publique de la zone enfant, le résolveur DNSSEC calcule le condensat de cette clé, et la compare à l’enregistrement DS de la zone parent. En cas de correspondance, le résolveur peut supposer que la clé KSK publique n’a pas été falsifiée et donc qu’il peut faire confiance à tous les enregistrements de la zone enfant. Il est important de noter ici que toute modification de la clé KSK nécessite de modifier l’enregistrement DS de la zone parent.

Afin d’établir une chaîne de confiance il est nécessaire de s’assurer de l’authenticité de l’enregistrement DS de la zone parent que l’on récupère.

Aussi, l’enregistrement DS est lui-même signé comme tout autre RRset par la clé ZSK occasionnant la présence d’un enregistrement RRSIG correspondant dans sa zone. De cette façon, tout le processus de validation se répète jusqu’à la clé KSK publique de la zone parent. Pour procéder à la vérification, il est nécessaire d’aller à l’enregistrement DS de ce parent, et remonter toute la chaîne de confiance, jusqu’à arriver à la zone DNS racine. Et puisque la zone racine n’a pas de parent, il n’existe donc pas d’enregistrement DS associée à une clé KSK publique de la zone racine. La confiance est alors garantie par une cérémonie publique hautement contrôlée : la Root Signing Ceremony. Lors de cette évènement, plusieurs personnes sélectionnées dans le monde entier se réunissent pour signer le RRset DNSKEY racine en produisant un enregistrement RRSIG qui peut être utilisé pour vérifier la clé KSK publique et la clé ZSK publique du serveur DNS racine.

Toujours selon notre exemple précédent, nous pouvons utiliser l’utilitaire dig pour récupérer l’enregistrement DS contenu dans la zone parente de la zone afnic.fr..

$ dig @ns0.fdn.fr +dnssec afnic.fr DS

; <<>> dig 9.10.8-P1 <<>> @ns0.fdn.fr +dnssec afnic.fr DS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11512
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;afnic.fr.                      IN      DS

;; ANSWER SECTION:
afnic.fr.               86222   IN      DS      21858 13 2 E46E61BFB32AE109AC75F5E80107D6B973C0F47DC3D1E2BA8926251D E1612073
afnic.fr.               86222   IN      RRSIG   DS 8 2 172800 20210804013306 20210628142729 23721 fr. VAeAYDYWd8dMsOYr/eVMK6VSOdD5+uQTx3yFaKJMTTkBnb/s55bxBN8D iaMt0ViS15LrWUqqiXVRgrivzg20ggLHTr5xZr4a02jOSI0VSQa6pEgA Euuft3/XHsVy86fPjmTt1WCshsk4BYM6E6NzxYpv+wH8ZszcQX7B7PEd tuL7fudmCs0s0LczQ8YNzC7WJtFSV738F9y3rB4zpfYz592mN0soOMQ4 DXfmlBXIg12nzwyLwrJEIOFEJH4qGiWBtPIcl+xWOf/TgaQAF9b2imT3 tiDdOBVJdaFmbzjsJgpWrxeSHqTcACBh6tM1TN3KUy6BNBIE3K/X7rya 0O83Uw==

;; Query time: 21 msec
;; SERVER: 80.67.169.12#53(80.67.169.12)
;; WHEN: Sun Jul 11 18:01:50 CEST 2021
;; MSG SIZE  rcvd: 375

Puisque la zone fr. supporte l’extension DNSSEC, nous obtenons bien l’enregistrement DS demandé, accompagné de sa signature dans le RSSIG. On pourrait ainsi manuellement remonter jusqu’à la zone racine afin de nous assurer de la validation de notre chaîne de confiance. Heuresement pour nous, le résolveur DNSSEC que nous interrogons réalise lui même toutes ses vérifications avant de nous répondre. À noter encore une fois, qu’ici, nous faisons confiance à la réponse reçue du résolveur DNSSEC de la FDN, alors même qu’un attaquant actif aurait la capacité de modifier les valeurs en cours de route. Aussi, deux options s’offrent à nous. Soit on considère faire confiance au service de la FDN, auquel cas il suffit d’utiliser un protocole de chiffrement du canal de communication comme TLS pour effectué des requêtes DNSSEC avec leurs serveurs. Soit on administre nous même un résolveur DNSSEC qui après avoir interrogé les différents serveurs DNSSEC faisant authorité nécessaire pour satisfaire à notre requête, se chargera d’effectuer la vérification de la chaîne de confiance.

Le système DNSSEC tend de cette façon à établir une chaîne de confiance robuste en s’appyant sur la hiérarchie du système DNS. Si une partie de la chaîne est rompue, nous ne pouvons pas faire confiance aux enregistrements que nous recevons en réponse.

Conclusion

Nous avons vu dans cet article l’importance de déployer rapidement et massivement l’extension DNSSEC pour assurer la sûreté non pas uniquement de la zone DNS d’une entité, mais bien celle de chacun des usagers de l’Internet. C’est la raison pour laquelle l’ICANN et l’ANSSI insistent régulièrement à ce sujet. Pour finir, il est à noter que n’importe qui peut vérifier facilement quelles sont les zones DNS qui appliquent les bonnes pratiques.

$ dig @ns0.fdn.fr +dnssec syloe.com

; <<>> dig 9.10.8-P1 <<>> @ns0.fdn.fr +dnssec syloe.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52060
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;syloe.com.                     IN      A

;; ANSWER SECTION:
syloe.com.              3580    IN      A       158.255.101.198

;; Query time: 24 msec
;; SERVER: 80.67.169.12#53(80.67.169.12)
;; WHEN: Fri Jul 09 17:31:14 CEST 2021
;; MSG SIZE  rcvd: 54