Sécurisation des noms de domaines

Glossaire DNSSEC

DNSSEC

Définition de DNSSEC : DNSSEC (Domain Name System Security Extensions) est un protocole standardisé œuvrant à sécuriser les données DNS. Par défaut, celles-ci ne sont pas chiffrées ce qui permet à un attaquant d’intercepter voire de modifier une transaction, notamment pour diriger un utilisateur vers un serveur pirate, à son insu. DNSSEC ne chiffre pas la connexion, mais signe la réponse grâce à la cryptographie asymétrique, ce qui permet au client d’en confirmer la validité.

Pour arriver à ce résultat, DNSSEC utilise des champs dédiés :
- DNSKEY : Contient la clé publique du domaine qui permettra au client de valider les données chiffrées. Elle correspond à la clé privée utilisée pour générer les RRSIG.
- RRSIG : Contient la signature des données du DNS. Les champs sont regroupés par association nom+type (par exemple : exemple.fr TXT ou exemple.fr MX), on parle alors de RRset, une empreinte est générée pour chacun des RRsets puis ils sont chiffrés par la clé privée associée à la DNSKEY. Il doit donc y avoir autant de RRSIG que d’association nom+type.
- NSEC, NSEC3 et NSEC3PARAM : Contiennent les preuves de la non-existence d’un domaine ou d’un enregistrement. Hélas ce système permet de cartographier un domaine, NSEC3 et NSEC3PARAM, apparus ultérieurement remplissent le même rôle mais sans permettre ce listage complet.
- DS, CDS et CDNSKEY : Contient une empreinte de la clé publique DNSKEY associée au nom du domaine. DS a la particularité d’être hébergé par la zone parente du domaine interrogé. Ainsi, l’enregistrement DS de « exemple.fr » est géré et hébergé par les serveurs gestionnaires de la zone « fr ». Ce champ a pour but de créer une chaîne de confiance entre zone affiliée, la zone parente validant la clé proposée par sa zone fille. On peut ainsi confirmer la validité des réponses DNS jusqu’à la racine. CDS et CDNSKEY permettent d’automatiser ce processus en donnant la possibilité au parent de prendre en compte tout changement dans la DNSKEY de la zone fille.

Exemples :
Le poste client va demander à son résolveur DNS l’adresse des serveurs de messagerie gérant le domaine « exemple.fr ». Le résolveur, qui est paramétré pour vérifier si DNSSEC est disponible, interroge la chaîne DNS afin de déterminer le serveur autoritaire du domaine : ns1.exemple.fr (détails du fonctionnement des DNS).

La requête MX est alors adressée au serveur DNS « ns.exemple.fr » qui répond :
- Les champs MX (comme il le ferait sans DNSSEC),
- Le champs RRSIG correspondant,
- Le champ DNSKEY qui va permettre de déchiffrer le champ RRSIG.

De plus, il interroge aussi le serveur DNS de la zone parente, ici « fr », qui répond avec :
- Le champ DS qui va permettre de valider que la DNSKEY n’est pas contrefaite.

A l’aide de ces informations, le résolveur va maintenant pouvoir :
1 – Valider la DNSKEY grâce à l’empreinte DS,
2 – Déchiffrer la RRSIG grâce à l’empreinte DNSKEY,
3 – Comparer le RRSIG déchiffré et le champ MX fourni.

Si tout est valide, la réponse est acceptée. S’il y avait eu une modification de la réponse par une attaque de type « homme du milieu », le RRSIG ne correspondrait pas à la DNSKEY. Si le serveur DNS est compromis ou piraté, la DNSKEY ne correspondrait pas l’empreinte DS.

Applications :
Le domaine « altospam.com » ainsi que tous ses sous-domaines sont protégés par DNSSEC. Ainsi lorsqu’un message est délivré à un de nos clients, la résolution de nom de nos serveurs est sécurisée contre toute forme de modification ou d’usurpation.

Informations complémentaires :
- Introduction à DNSSEC
- Explications de la RFC4033

Articles en rapport avec dnssec :
- DANE pour sécuriser les échanges SMTP
- NStools.fr : Analysez la configuration et la sécurité de votre domaine
- Comment optimiser la sécurité de sa messagerie électronique ?
- Une menace croissante, la fraude de nom de domaine
- Attaques informatiques par emails : une menace constante pour la sécurité
- La sécurité, notre priorité absolue
- Remise en question de la sécurité de la messagerie