Comment fonctionne le DNSSEC ?

Le système de noms de domaine (DNS, Domain Name System) est l'annuaire téléphonique d'Internet : 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.

Objectifs d’apprentissage

Cet article s'articule autour des points suivants :

  • Définir le protocole DNSSEC
  • Comprendre le fonctionnement du protocole DNSSEC
  • Comprendre les concepts clés associés aux DNSSEC
  • Découvrir comment les zones sont sécurisées avec DNSSEC
  • Comprendre comment la chaîne de confiance est établie

Copier le lien de l'article

Les serveurs de messagerie utilisent le DNS pour acheminer 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 informatiques 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.

La solution est un protocole nommé DNSSEC, qui ajoute une couche de confiance au DNS en assurant l’authentification Lorsqu'un résolveur DNS recherche blog.cloudflare.com, les serveurs de noms .com l'aident à vérifier les enregistrements renvoyés pour Cloudflare et Cloudflare contribue à vérifier les enregistrements renvoyés pour le blog. Les serveurs de noms DNS racines aident à vérifier .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 la signature qui lui est 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. Publié

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 ».

Cependant, ces enregistrements RRSIG ne sont utiles que si 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.

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.

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 illustrée 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.

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. Le changement de ZSK est en revanche beaucoup plus facile. Nous pouvons ainsi utiliser une ZSK plus petite sans compromettre la sécurité du serveur, réduisant ainsi 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 aucune confiance supplémentaire. 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.

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 en 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 et 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 réunir tous les enregistrements sans savoir quels sont ceux qu'ils recherchent. Cela peut représenter une menace potentielle pour la sécurité si l'administrateur s'attendait à ce que le contenu de la zone soit privé. Approfondissez vos connaissance sur la question avec 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.

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 partons du principe 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.

DNSSEC et serveurs d'inscription

La confiance au sein des DNSSEC s'accordant de manière descendante (la zone racine vérifie les .com et la zone .com vérifie la zone cloudflare.com, et ainsi de suite), l'activation de DNSSEC implique que le propriétaire d'un site Web doive mettre à jour l'enregistrement DS auprès de vous, le serveur d'inscription.

Cette partie est problématique ; copier et coller l'enregistrement DS ouvre la voie à la possibilité d'erreur humaine et ajoute un niveau de complexité pour les utilisateurs moins expérimentés. Nous voulons rendre le DNSSEC aussi facile à déployer que possible.

Si Cloudflare pouvait communiquer directement avec le serveur d'inscription ou le registre, nous pourrions activer automatiquement DNSSEC pour chaque site Web sur Cloudflare et gérer leurs clés sans intervention humaine.

Dans le cadre du déploiement de notre DNSSEC, nous avons publié une version préliminaire pour internet parallèlement à l'ACEI (Autorité canadienne pour les enregistrements Internet), le registre .ca, qui propose un protocole permettant aux opérateurs DNS tels que Cloudflare de faire exactement cela : c'est-à-dire communiquer avec les serveurs d'inscription et les registres pour automatiser la gestion des DNSSEC.

Rejoignez-nous et facilitez l'accès au DNSSEC pour tous.

Plusieurs registres prévoient déjà d'ajouter cette prise en charge, notamment NIC Chile (.cl) et eNIC (.ee). Si vous travaillez pour un serveur d'inscription ou un registre et que vous souhaitez en savoir plus, participer au développement du protocole ou ajouter une intégration à Cloudflare, contactez-nous par e-mail sur dnssec-integration@cloudflare.com.

Résumé

Comme HTTPS, DNSSEC ajoute une couche de sécurité avec l'activation de réponses authentifiées au-dessus 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 du protocole DNSSEC. Tous les clients Cloudflare peuvent ajouter les DNSSEC à leurs propriétés web en cliquant sur un bouton pour activer le protocole et en important un enregistrement DS (que nous générerons automatiquement) sur leur serveur d'inscription. En savoir plus sur la procédure à suivre pour activer DNSSEC.

Nous avons également publié un avant-projet Internet décrivant la manière dont les registres et les bureaux d'enregistrement peuvent importer automatiquement les enregistrements DS pour le compte de nos clients. Ainsi, Cloudflare pourra activer automatiquement les DNSSEC pour l'ensemble de notre communauté. Restez à l'écoute pour plus d'informations sur les mises à jour.