DNS est l'un des premiers protocoles à avoir vu le jour. Il a été défini et implémenté dans les années 80, c'est une brique fondamentale dans l'internet d'aujourd'hui.

On peut le comparer à une base de donnée distribuée sur des milllions de machines. Il permet de faire la relation entre le nom d'une machine sur le web et son adresse IP.

Il est composé de 13 serveurs racines répartis dans le monde, qui constituent le point d'entrée dans le schéma arborescant (hiérarchique) ci-dessous. Ensuite viennent les « Top-Level Domains » ou domaines de premier niveau (.fr, .com, etc..) puis les noms de domaine classiques comme « fnac.fr ». DNS repose sur un système de communication entre ces différentes strates pour pouvoir identifier la machine étant capable de donner la réponse a la requête d'un internaute.

Arborescance hiérarchique DNS

Lorsqu'un utilisateur souhaite accéder à un site web, il utilise généralement un nom. Ce nom est très pratique car il est beaucoup plus simple à retenir qu'une adresse IP mais il nécessite d'être résolu. Et pour ce faire, DNS utilise un processus particulier. Avant tout l'utilisateur va faire suivre sa requête de résolution à un résolveur distant, qui est souvent par défaut le résolveur du FAI concerné. Par exemple pour www.wikipedia.fr, le résolveur va alors entamer la procédure suivante :

• Demande l'adresse du TLD « .fr » à l'un des serveurs racine
• Demande l'adresse du serveur « wikipedia.fr » au serveur .fr
• Demande l'enregistrement « www » au serveur wikipedia.fr
• Le résolveur envoie finalement la réponse à l'utilisateur qui peut désormais interroger son serveur web

La résolution DNS (www.afnic.fr)

Par défaut DNS utilise UDP et ne chiffre pas ses paquets. Dans la capture suivante nous pouvons voir tous les champs qui composent un paquet. Nous noterons que certains sont plus sensibles que d'autres :

• Identification : Un identifiant de 16 bits généré aléatoirement. Cet identifiant est copié dans la réponse correspondante à la requête initiale. Il est nécessaire qu'un nouveau nombre aléatoire, de 16 bits, soit généré pour chaque demande.
• Total Additional Resource Records : Permet de rajouter des enregistrement supplémantaires dans la réponse à une requête.

Vulnérabilités                                                                                           

DNS n’est pas sur (RFC 3833), les principaux problèmes connus sont :

• Le Cache Poisonning
• Les attaques de type Denial of Service
• Le Name Chaining
• L'interception de paquets
• Le brute force du champ Identification

La RFC 3833 décrit plutôt bien ces problèmes, nous nous intéresserons surtout à l'un d'eux qui est à l'origine de plusieurs attaques, le Cache Poisonning :

On peut citer l'attaque de Bradesco au travers du FAI Brésilien NET Virtua que l'on soupçonne d'avoir été empoisonné. La faille Kaminsky révélée à la Black Hat 2008 dénonce se problème et démontre comment empoisonner un serveur de noms pour qu'il réponde de fausses informations.

Explication :
Dans le cas d'un serveur A, envoyant une requête vers un serveur B. L'objectif du "Pirate" est de faire passer l'une de ses propres réponses pour une réponse du serveur B, et ainsi empoisoner le cache du serveur A. Dans se cas le serveur A, répondra la fausse information transmise par le pirate lorsqu'on lui posera la bonne question.
Dans un premier temps, le pirate déclanche la résolution d'une adresse par le serveur A en lui envoyant des requêtes. Ensuite, sachant que le serveur A va envoyer des requêtes et attendre des résponses, le pirate va pouvoir forger des réponses erronées et les envoyer au serveur A.
Cette attaque est possible principalement du au fait qu'il n'y ai pas d'authentification. La seule authentification se base sur le fait que la réponse doit avoir la même valeur que la requête dans le champ Identification du paquet DNS et que le port soit le bon.

Problématique et enjeux                                                                          

Tout ceci fait émerger la problématique suivante :

Comment assurer l’intégrité des données et authentifier les résolveurs / serveurs faisant autorité tout en conservant la rétrocompatibilité avec DNS ?

Les principaux enjeux sont sont de pouvoir :

• Assurer la sécurité d’accès à la ressource demandée aux 3 milliards d’utilisateurs
• Trouver une solution assez légère pour ne pas surcharger les serveurs de noms.

Domain Name System Security Extensions

Introduction                                                                                         

Qu'est-ce que DNSSEC ?

• Sécurisation des données (pas du canal) à travers un mécanisme de clés asymétriques
• Signe les enregistrements DNS de sa propre zone
• Chaque zone DNS parente, garantie l’authenticité des clés de ses zones filles en les signant
• Permet d’établir une « chaine de confiance » jusqu’à la racine DNS

Qu'est-ce que n'est pas DNSSEC ?

• Pas de chiffrement des enregistrements DNS
• Pas de confidentialité des échanges
• Ne garantit pas la sécurité d’un transaction (au sens certificat SSL)

Fonctionnement                                                                                  

DNSSEC repose avant tout sur un système de confiance des enregistrements DNS par signature.

Chaque information DNS est signée avec une clé privée et transmise avec l'information en elle même, de sorte à ce que les serveurs de résolution (ayant la clé publique) soient en mesure de déterminer la véracité de l'information.

Signature et authentification de clés DNSSEC (www.afnic.fr)

Au fur et a mesure que le système de signature d'enregistrements s'étend à l'arborescance DNS, une chaine de confiance s'installe. En effet, DNSSEC ne se base pas seulement sur la signature des enregistrements DNS. Il permet également de signer les clés publiques de manière hiérarchique. Ainsi, la zone mère signe toujours les clés publiques de ses zones filles, il en va ainsi jusqu'au domaine recherché.

De ce fait, lorsque le résolveur de notre FAI doit résoudre un nom, il n'a besoin que de la clé privée de la racine, ce qui lui permet de faire confiance à toutes les clés ascendantes.

La chaine de confiance DNSSEC (www.afnic.fr)

Le déploiement                                                                                       

DNSSEC a été adopté et est aujourd'hui en déploiement depuis presque 5 ans, les RR de la zone racine ont étés signés en Juillet 2010, ceux du .fr en Septembre 2010.

En France l'Afnic (Association française pour le nommage Internet en coopération) s'engage dans la promotion de DNSSEC :

• Elle propose notamment à ses bureaux d’enregistrement accrédités une remise de 20% sur le tarif des créations et la maintenances de noms de domaine en .fr signés par DNSSEC

De ce fait, plusieurs « registrars » proposent le déploiement DNSSEC à leurs clients (nous !) :

• Gandi
• OVH

Avoir son propre résolveur DNSSEC ?                                                

Une question subsiste cependant, pourquoi pas avoir son propre résolveur DNSSEC ? Après tout même si le résolveur de notre FAI de la résolution DNS, cela ne garanti pas la protection entre ce dernier et notre machine.

Pourquoi avoir son résolveur :

• Assurer son adhérence à la « chaine de confiance »
• Contourner la censure réalisée par certains résolveurs (DNS RPZ)
• On ne fait plus confiance aux DNS potentiellement fournis par DHCP (hotspots..)

A quel niveau, local ? distant ?

• Au niveau local, la « chaine de confiance » est complète car la validation DNSSEC est locale mais on perd la notion de cache partagé => accroit la charge sur la racine
• Au niveau distant, on a la possibilité de mutualiser le service et aussi de faire du partage de cache

Au final je pense que oui, il peut être intéressant d'avoir son propore résolveur. Mais que cela dépend vraiment des usages et du niveau de paranoïa de l'intéressé.

Installer son propre résolveur local

Exemple avec Unbound qui est un serveur DNS permettant de faire du DNSSEC (BIND le fait aussi)

• Dans /var/unbound/etc/unbound.conf :
  server:
  
  interface: 127.0.0.1
  auto-trust-anchor-file: "/var/lib/unbound/root.key"
• Récupération de la clé de la racine :
  
  unbound-anchor -a "/var/lib/unbound/root.key"
• Dans /etc/resolvconf/resolv.conf.d/head :
  
  nameserver 127.0.0.1

Les alternatives                                                                                      

Il existe des alternatives, qui n'utilisent pas le même système de sécurisation :

DNSCurve : Sécurisation du canal (contrairement a DNSSEC)

• Inutile si le serveur distant est un serveur pirate

DNSCrypt : Chiffre aussi le trafic DNS (simple)

• Outil open source
• Développé par OpenDNS

Conclusion                                                                                              

Ce qu'il faut retenir de DNSSEC :

• DNSSEC protège contre des failles de type Kaminsky (cache poisoning)
• Il est en bonne voie de déploiement
• Il n’est pas simple à maintenir (rollover de clés asymétriques)
• Repose sur la compétence des différents acteurs de la chaine de confiance.