How DNSSEC Works

The domain name system (DNS) is the phone book of the Internet: it tells computers where to send and retrieve information. Unfortunately, it also accepts any address given to it, no questions asked.

Email servers use DNS to route their messages, which means they’re vulnerable to security issues in the DNS infrastructure. In September 2014 researchers at CMU found email supposed to be sent through Yahoo!, Hotmail, and Gmail servers routing instead through rogue mail servers. Attackers were exploiting a decades-old vulnerability in the Domain Name System (DNS)—it doesn’t check for credentials before accepting an answer.

The solution is a protocol called DNSSEC; it adds a layer of trust on top of DNS by providing authentication. When a DNS resolver is looking for blog.cloudflare.com, the .com name servers help the resolver verify the records returned for cloudflare, and cloudflare helps verify the records returned for blog. The root DNS name servers help verify .com, and information published by the root is vetted by a thorough security procedure, including the Root Signing Ceremony.

Petite introduction à DNSSEC

DNSSEC crée un système de noms de domaine sécurisé en ajoutant des signatures cryptographiques aux enregistrements DNS existants. Ces signatures numériques sont stockées dans des serveurs de noms DNS parallèlement à des types d'enregistrement courants comme A, AAAA, MX, CNAME, etc. En vérifiant sa signature associée, vous pouvez vérifier qu'un enregistrement DNS demandé provient de son serveur de noms faisant autorité et qu'il n'a pas été modifié en chemin, contrairement à un faux enregistrement injecté dans une attaque de l'homme du milieu.

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

  • RRSIG : contient une signature cryptographique
  • DNSKEY : contient une clé de signature publique
  • DS : contient le hachage d'un enregistrement DNSKEY
  • NSEC et NSEC3 : pour le déni d'existence explicite d'un enregistrement DNS
  • CDNSKEY et CDS : pour une zone fille demandant des mises à jour d'un ou de plusieurs enregistrements DS dans la zone parent.

Dans cet article, nous allons aborder l'interaction entre les enregistrements RRSIG, DNSKEY et DS, ainsi que la façon dont ils ajoutent une couche de confiance en haut du DNS.

RRsets

La première étape pour sécuriser une zone avec DNSSEC consiste à regrouper tous les enregistrements de même type dans un ensemble d'enregistrements de ressources (RRset). Par exemple, si trois enregistrements AAAA dans votre zone ont la même étiquette (c'est-à-dire label.example.com), ils seront tous regroupés en un seul RRset AAAA.

Schéma - RRsets

C'est en fait ce RRset complet qui est signé numériquement, contrairement aux enregistrements DNS individuels. Bien sûr, cela signifie également que vous devez demander et valider tous les enregistrements AAAA d'une zone portant la même étiquette au lieu de ne valider qu'un seul d'entre eux.

Clés de signature de zone

Chaque zone dans le DNSSEC possède une paire de clés de signature de zone (ZSK) : la partie privée de la clé signe numériquement chaque RRset de la zone, tandis que la partie publique vérifie la signature. Pour activer DNSSEC, un opérateur de zone crée des signatures numériques pour chaque RRset à l'aide de la ZSK privée et les stocke dans son serveur de noms en tant qu'enregistrements RRSIG. Cela revient à dire « Ce sont mes enregistrements DNS, ils proviennent de mon serveur et ils devraient ressembler à ça ».

Schéma - Clés de signature de zone 1

Cependant, ces enregistrements RRSIG sont inutiles à moins que les résolveurs DNS puissent vérifier les signatures. L'opérateur de la zone doit également rendre sa ZSK publique disponible en l'ajoutant à son serveur de noms dans un enregistrement DNSKEY.

Lorsqu'un résolveur DNSSEC demande un type d'enregistrement particulier (par exemple, AAAA), le serveur de noms renvoie également le RRSIG correspondant. Le résolveur peut alors extraire du serveur de noms l'enregistrement DNSKEY contenant la ZSK publique. Ensemble, le RRset, le RRSIG et la ZSK publique peuvent valider la réponse.

Schéma - Clés de signature de zone 2

Si nous faisons confiance à la clé de signature de zone dans l'enregistrement DNSKEY, nous pouvons faire confiance à tous les enregistrements de la zone. Mais qu'en est-il si la clé de signature de zone est compromise ? Nous devons trouver un moyen de valider la ZSK publique.

Clés de signature de clé

En plus d'une clé de signature de zone, les serveurs de noms DNSSEC disposent également d'une clé de signature de clés (KSK). La KSK valide l'enregistrement DNSKEY exactement de la même manière que notre ZSK a sécurisé le reste de nos RRsets dans la section précédente : elle signe la ZSK publique (qui est stockée dans un enregistrement DNSKEY), créant ainsi un RRSIG pour le DNSKEY.

Schéma - Clés de signature de clé 1

Tout comme la ZSK publique, le serveur de noms publie la KSK publique dans un autre enregistrement DNSKEY, ce qui nous donne le RRset DNSKEY indiqué ci-dessus. La KSK publique et la ZSK publique sont toutes deux signées par la KSK privée. Les résolveurs peuvent ensuite utiliser la KSK publique pour valider la ZSK publique.

Pour les résolveurs, la validation ressemble maintenant à ce qui suit :

  • Demande du RRset souhaité, qui renvoie également l'enregistrement RRSIG correspondant.
  • Demande des enregistrements DNSKEY contenant la ZSK publique et la KSK publique, qui renvoient également le RRSIG pour le RRset DNSKEY.
  • Vérification du RRSIG du RRset demandé à l'aide de la ZSK publique.
  • Vérification du RRSIG du RRset DNSKEY à l'aide de la KSK publique.
Schéma - Clés de signature de clé 2

Bien entendu, le RRset DNSKEY et les enregistrements RRSIG correspondants peuvent être mis en cache, ainsi les serveurs de noms DNS ne sont pas constamment bombardés de requêtes inutiles.

Pourquoi utilisons-nous des clés de signature de zone et des clés de signature de clé distinctes ? Comme nous le verrons dans la section suivante, il est difficile de remplacer une KSK obsolète ou compromise. Changer la ZSK, en revanche, est beaucoup plus facile. Nous pouvons ainsi utiliser une ZSK plus petite sans compromettre la sécurité du serveur, en réduisant la quantité de données que le serveur doit envoyer avec chaque réponse.

Nous avons maintenant établi la confiance au sein de notre zone, mais le DNS est un système hiérarchique et les zones fonctionnent rarement de manière indépendante. Pour compliquer encore les choses, la clé de signature de clé est signée par elle-même, ce qui n'apporte rien de plus à la confiance. Nous avons besoin d'un moyen de propager la confiance dans notre zone à sa zone parent.

Enregistrements signataires de délégation

DNSSEC introduit un enregistrement Delegation Signer (DS) pour permettre la propagation de la confiance dans une zone parent à une zone enfant. Un opérateur de zone hache l'enregistrement DNSKEY contenant la KSK publique et le donne à la zone parent pour qu'elle le publie en tant qu'enregistrement DS.

Schéma - Enregistrements Delegation Signer

Chaque fois qu'un résolveur est dirigé vers une zone enfant, la zone parent fournit également un enregistrement DS. C'est grâce à cet enregistrement DS que les résolveurs savent que la zone enfant est compatible DNSSEC. Pour vérifier la validité de la KSK publique de la zone enfant, le résolveur la hache et la compare à l'enregistrement DS du parent. En cas de correspondance, le résolveur peut supposer que la KSK publique n'a pas été falsifiée ce qui signifie qu'il peut faire confiance à tous les enregistrements de la zone enfant. C'est ainsi qu'une chaîne de confiance est établie dans DNSSEC.

Notez que toute modification de la KSK nécessite de modifier l'enregistrement DS de la zone parent. La modification de l'enregistrement DS est un processus à plusieurs étapes qui peut finir par casser la zone si elle n'est pas effectuée correctement. Le parent doit commencer par ajouter le nouvel enregistrement DS, puis attendre que le TTL de l'enregistrement DS d'origine expire avant de le supprimer. C'est pourquoi il est beaucoup plus facile d'échanger des clés de signature de zone que des clés de signature de clé.

Déni d'existence explicite

Si vous demandez au DNS l'adresse IP d'un domaine qui n'existe pas, il renvoie une réponse vide : il n'existe aucun moyen de dire explicitement « Désolé, la zone que vous avez demandée n'existe pas ». Cette situation est problématique si vous voulez authentifier la réponse, puisqu'il n'y a pas de message à signer. DNSSEC résout ce problème en ajoutant les types d'enregistrements NSEC et NSEC3. Ils permettent tous deux un déni d'existence authentifié.

NSEC renvoie l'enregistrement « sécurisé suivant ». Prenons par exemple un serveur de noms qui définit des enregistrements AAAA pour api, blog, and www. Si vous demandez un enregistrement pour « store », il renvoie un enregistrement NSEC contenant www, ce qui signifie qu'il n'y a pas d'enregistrement AAAA entre « store » et www lorsque les enregistrements sont triés par ordre alphabétique. Vous savez ainsi que « store » n'existe pas. Et, puisque l'enregistrement NSEC est signé, vous pouvez valider son RRSIG correspondant comme n'importe quel RRset.

Malheureusement, cette solution permet à n'importe qui de traverser la zone et de rassembler tous les enregistrements sans savoir quels sont ceux qu'ils recherchent. Ce problème peut représenter une menace potentielle pour la sécurité si l'administrateur de la zone comptait sur la nature privée du contenu de la zone. Approfondissez ce problème en consultant l'article DNSSEC : Complexités et considérations, et lisez plus d'informations sur la solution unique de Cloudflare dans Application correcte de DNSSEC.

La chaîne de confiance

Très bien, nous avons donc un moyen d'établir la confiance au sein d'une zone et de la propager à sa zone parent, mais comment faisons nous confiance à l'enregistrement DS ? L'enregistrement DS est signé comme tout autre RRset, ce qui signifie qu'il a un RRSIG correspondant dans le parent. Tout le processus de validation se répète jusqu'à la KSK publique du parent. Pour procéder à la vérification, nous devons aller à l'enregistrement DS de ce parent, et remonter toute la chaîne de confiance.

Schéma - La chaîne de confiance

Cependant, lorsque nous arrivons enfin à la zone DNS racine, un problème se pose : il n'existe aucun enregistrement DS parent pour le valider. C'est là que nous découvrons un aspect très humain de l'Internet mondial.

Lors de la Root Signing Ceremony, plusieurs personnes sélectionnées dans le monde entier se réunissent pour signer le RRset DNSKEY racine de manière très publique et hautement contrôlée. La cérémonie produit un enregistrement RRSIG qui peut être utilisé pour vérifier la KSK publique et la ZSK publique du serveur de nom racine. Au lieu de faire confiance à la KSK publique en raison de l'enregistrement DS du parent, nous supposons qu'il est valide parce que nous faisons confiance aux procédures de sécurité entourant l'accès à la KSK privée.

La capacité à établir la confiance entre les zones parent et enfant fait partie intégrante de DNSSEC. Si une partie de la chaîne est rompue, nous ne pouvons pas faire confiance aux enregistrements que nous demandons, car un homme du milieu pourrait modifier les enregistrements et nous diriger vers l'adresse IP de son choix.

Résumé

Comme HTTPS, DNSSEC ajoute une couche de sécurité en activant des réponses authentifiées en haut d'un protocole par ailleurs non sécurisé. Alors que HTTPS chiffre le trafic pour que personne en ligne ne puisse espionner vos activités sur Internet, DNSSEC se contente de signer les réponses pour que les falsifications soient détectables. DNSSEC apporte une solution à un problème réel sans qu'il soit nécessaire d'incorporer un chiffrement.

Cloudflare se donne pour objectif de faciliter autant que possible l'activation de DNSSEC. À l'heure actuelle, les clients ayant souscrit un abonnement Cloudflare peuvent ajouter DNSSEC à leurs propriétés web en basculant un interrupteur pour activer DNSSEC et en chargeant un enregistrement DS (que nous générerons automatiquement) à leur registrar. En savoir d'avantage sur l'obtention de DNSSEC.

Nous avons également publié un projet Internet expliquant comment les registres et les registrars peuvent charger automatiquement les enregistrements DS pour le compte de nos clients. Ainsi, Cloudflare pourra activer automatiquement DNSSEC pour l'ensemble de notre communauté. Veillez à consulter les mises à jour.

La solution Cloudflare est facile à configurer



Configurez un domaine en moins de 5 minutes. Conservez votre fournisseur d'hébergement. Aucune modification du code n'est requise.

Tarification Cloudflare

Chaque application Internet peut bénéficier de l'utilisation de Cloudflare. Sélectionnez une offre correspondant à vos besoins.


Gratuite

Pour les sites web personnels, les blogs et toutes les personnes qui souhaitent découvrir Cloudflare.



Learn More


Pro

Pour les sites web, les blogs et les portefeuilles professionnels nécessitant une sécurité et des performances de base.


20 $ / mois

par domaine


Learn More


PME

Pour les sites de commerce électronique et les entreprises de petite taille nécessitant une sécurité et des performances avancées, la conformité à la norme PCI et une assistance prioritaire par e-mail.


200 $ / mois

par domaine


Learn More


Entreprise

Pour les entreprises qui ont besoin d'une sécurité et de performances de niveau professionnel, d'une disponibilité garantie et d'une assistance prioritaire par téléphone, par e-mail ou par chat 24 h/24, 7 j/7, 365 j/an.


Nous contacter


Learn More

Plébiscité par

plus de 25,000,000 de propriétés Internet