Comment fonctionne 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.

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

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.

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