Comment fonctionne DNSSEC

Le système de noms de domaine (DNS, Domain Name System) est l'annuaire téléphonique du web : il indique aux ordinateurs où envoyer et récupérer des informations. Malheureusement, il accepte également toute adresse qui lui est donnée, sans poser de questions.

Les serveurs de messagerie électronique utilisent le DNS pour router leurs messages, ce qui signifie qu'ils sont vulnérables aux problèmes de sécurité de l'infrastructure DNS. En septembre 2014, des chercheurs de la Carnegy Mellon University ont découvert que des e-mails censés être envoyés par les serveurs de Yahoo!, Hotmail et Gmail passaient par des serveurs de messagerie non autorisés. Les pirates exploitaient une vulnérabilité du système de noms de domaine (DNS) vieille de plusieurs décennies : ce système ne vérifie pas les informations d'identification avant d'accepter une réponse.

Icône DNSSEC

La solution est un protocole nommé DNSSEC. Il ajoute une couche de confiance au DNS en fournissant l'authentification. Lorsqu'un résolveur DNS recherche blog.cloudflare.com, les serveurs de noms .com aident le résolveur à vérifier les enregistrements renvoyés pour Cloudflare, et Cloudflare aide à vérifier les enregistrements renvoyés pour le blog. Les serveurs de noms DNS racines aident à vérifier les .com, et les informations publiées par la racine sont vérifiées par une procédure de sécurité approfondie qui comprend la Root Signing Ceremony (cérémonie de signature de clé de la zone racine).

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

Toute application Internet peut bénéficier de l'utilisation de Cloudflare.
Sélectionnez une offre qui répond à vos besoins.

Gratuite 0 USD /mois, par site web
Agrandir pour afficher plus d'informations Masquer
Pour les sites web personnels, les blogs et toutes les personnes qui souhaitent découvrir Cloudflare.

En savoir plus

L'offre gratuite comprend toutes les fonctionnalités suivantes :
  • Atténuation illimitée des attaques DDoS
  • RDC mondial
  • Certificat SSL partagé
  • Accès aux journaux d'audit du compte
  • 3 Page Rules
Comparer toutes les fonctions
Pro 20 USD /mois par site web
Agrandir pour afficher plus d'informations Masquer
Pour les sites web, les blogs et les portefeuilles professionnels nécessitant une sécurité et des performances de base.

En savoir plus

L'offre Pro comprend toutes les options de l'offre gratuite plus :
  • Pare-feu d'applications web (WAF) avec ensembles de règles Cloudflare
  • Optimisations d'images avec Polish™
  • Optimisations mobiles avec Mirage™
  • Mode I'm Under Attack™ (Je suis victime d'une attaque)
  • Accès aux journaux d'audit du compte
  • 20 Page Rules
Comparer toutes les fonctions
PME 200 USD /mois par site web
Agrandir pour afficher plus d'informations Masquer
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.

En savoir plus

L'offre PME comprend toutes les options de l'offre Pro plus :
  • Pare-feu d'applications web (WAF) avec 25 ensembles de règles personnalisés
  • Téléchargement de certificat SSL personnalisé
  • Conformité à la norme PCI grâce au mode « TLS moderne uniquement » et pare-feu d'applications web (WAF)
  • Bypass Cache on Cookie (contournement du cache par cookie)
  • Livraison accélérée du contenu dynamique avec Railgun™
  • Assistance prioritaire par e-mail
  • Accès aux journaux d'audit du compte
  • 50 Page Rules
Comparer toutes les fonctions
Entreprise Contactez-nous
Agrandir pour afficher plus d'informations Masquer
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.

En savoir plus

L'offre Entreprise comprend toutes les options de l'offre PME plus :
  • Assistance par téléphone, par chat et par e-mail de niveau professionnel, disponible 24 h/24, 7 j/7, 365 j/an
  • SLA avec garantie de temps d'activité de 100 % ou remboursement ×25
  • Protection de niveau professionnel contre les attaques DDoS avec hiérarchisation des priorités du réseau
  • Pare-feu d'applications web (WAF) avancé sans limites d'ensembles de règles personnalisés
  • Accès multi-utilisateurs aux comptes en fonction du rôle
  • Téléchargements de plusieurs certificats SSL personnalisés
  • Accès aux journaux bruts
  • Accès aux journaux d'audit du compte
  • Ingénieurs solutions et clientèle dédiés
  • Accès aux datacenters du RDC chinois (frais supplémentaires)
  • 100 Page Rules
Comparer toutes les fonctions

Offre gratuite

0 USD

/ mois

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

Pro

20 USD

/ mois

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

PME

200 USD

/ mois

par domaine
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.

Entreprise

Nous contacter
 
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.

Plébiscité par

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

trustedby crunchbase black
trustedby ao com black
trustedby zendesk black
logo sofi gray 32px wrapper
trustedby log me in black
trustedby digital ocean black
trustedby okcupid black
trustedby montecito black
trustedby discord black
trustedby library of congress black
trustedby udacity black
trustedby marketo black