Architecture DNS

Le DNS [AFNa] [Oll05] s’appuie sur une architecture client/serveur reposant sur 3 dispositifs : – Un espace de noms hiérarchique permettant de garantir l’unicité des noms de domaine, – Un système de serveurs distribués permettant la diffusion de ces noms de domaine, – Et un système client permettant de résoudre les noms de domaine.

4.1.1.1.1 Espace de noms hiérarchique : La structure hiérarchique des noms de domaine est conçue comme une arborescence, ayant pour origine une racine représentée par un ".", afin que chaque nom d’hôte (c.-à-d. machine) soit unique. L’espace de nommage, c.-à-d. le chemin dans l’arbre inversé pour 1. 4 blocs d’octets séparés par des "." pour les adresses IPv4, et 8 blocs de 2 octets séparés par des " :" pour les adresses IPv6. Notons que l’ensemble de notre étude se focalise exclusivement sur les adresses IPv4.

2. cf. section 4.1.1.1. 3. Liste non exhaustive.

4.1. Le pharming

Figure 4.1 – Hiérarchie DNS simplifiée

un nom d’hôte donné, comporte typiquement 4 niveaux : racine, TLD, domaine et hôte (cf. figure 4.1). Chaque nom d’hôte (sur 63 caractères maximum) doit être unique dans le domaine concerné. Un domaine peut être éventuellement re-découpé en sous-domaines intermédiaires, tant que le nom d’hôte complet (appelé FQDN et constitué des différents niveaux d’arborescence séparés par des ".") n’excède par 255 caractères et 127 niveaux d’arborescence. Chaque responsable de domaine dispose d’une totale liberté de nommage de ses sous-domaines. Pour un minimum de structure, les TLD - également appelés domaines de premier niveau - suivent une codification spécifique établie par l’ICANN (pour Internet

Corporation for Assigned Names and Numbers). Ils sont par ailleurs gérés soit directement par l’ICANN,

soit par des organismes délégués appelés registres. Enfin, les noms de domaine sont achetés auprès d’un bureau d’enregistrement des domaines, appelé registrar. A noter qu’il est possible de consulter les données contenues par les registres via l’utilisation du protocole WHOIS (RFC 3912, port TCP 43).

Les TLDs se décomposent en plusieurs groupes. Les plus connus sont les g-TLD pour generic TLD (p.ex. .COM, .ORG, .GOV, etc.), et les cc-TLD pour country-code TLD représentatifs d’un pays ou d’une zone géographique (p.ex. .FR pour la France, .EU pour l’Europe, etc.).

4.1.1.1.2 Système de serveurs distribués : Chaque domaine dispose d’un serveur DNS (au minimum), afin d’annoncer sur Internet les combinaisons FQDN/adresses IPs qu’il détient. Ainsi, il existe des centaines de milliers de serveurs DNS à travers le monde, chacun d’entre eux ne contenant que peu d’informations. A chaque requête DNS effectuée, ce sont en fait de nombreux serveurs DNS qui sont sollicités. On dit de l’architecture DNS qu’elle est un système décentralisé, reposant sur la délégation de domaine. En effet pour que l’ensemble de l’arborescence DNS soit gérable, à chaque niveau (non-terminal) on associe une zone par entité (cf. figure 4.1). Chaque zone est responsable, par délégation de la zone supérieure, de répondre aux requêtes DNS concernant les entités qu’elle détient (c.-à-d. de niveau inférieur).

Traditionnellement, chaque zone contient (jusqu’à) 3 serveurs DNS (cf. figure 4.2) : un serveur pri-maire contenant les informations de zone (on parle alors de serveur "autoritaire" pour la zone), un serveur de noms secondaire généralement utilisé pour la continuité de services, et un serveur cache qui mémorise les réponses aux précédentes requêtes DNS avec une durée de vie limitée. Les transferts d’informations depuis le serveur DNS primaire vers le serveur DNS secondaire sont appelés transferts de zone.

Figure 4.2 – Vue simplifiée des zones DNS

Tableau 4.1 – Exemples d’enregistrements DNS Resource Record (RR)

RR FQDN Type Classe TTL Adresse IP

1 www.google.fr A IN 86400 209.85.148.103

2 www.google.fr A IN 86400 209.85.148.99

3 www.google.fr A IN 86400 209.85.148.105

4 www.it-sudparis.eu A IN 43200 157.159.11.8

dans sa base, qu’elles concernent ou non sa zone. Les informations de sa propre zone sont concentrées dans un fichier (nommé fichier de zone) qui contient plusieurs enregistrements appelés Resource Record (RR), comme le présente la figure 4.2.

Chaque enregistrement RR contient 5 informations (cf. tableau 4.1) : le FQDN, le Type d’enregistre-ment, la Classe, le TTL (pour Time To Live), ainsi que l’adresse IP associée.

Les types d’enregistrements servent à donner une indication sur la teneur de l’hôte. Les plus connus sont : MX (pour Mail eXchange) utilisé pour décrire un serveur mail, NS (pour Name Server ) utilisé pour décrire le serveur "autoritaire" de la zone, ou A (pour Address) utilisé pour décrire une machine/un hôte IPv4 (p.ex. un serveur web, un serveur ftp, etc.). Le TTL permet, quant à lui, d’associer une durée de vie (exprimée en secondes) à chaque enregistrement. Enfin, la Classe permet de décrire le système associé à l’enregistrement. On utilise ici IN pour indiquer Internet.

4.1.1.1.3 Système client : Le système client DNS, permettant de réaliser l’opération de résolution de domaine, est appelé résolveur (ou resolver en anglais). Installé côté client, il est appelé par les applications du système en vue d’effectuer les requêtes DNS. Ainsi, par l’intermédiaire du résolveur, une application souhaitant contacter un hôte par son nom de domaine envoie une requête au serveur DNS dont il détient l’adresse (typiquement celui du FAI, automatiquement configuré via DHCP, dans le cas d’un réseau personnel).

4.1. Le pharming

Trois modes de fonctionnement se présentent alors :

1. Le serveur DNS interrogé possède les informations dans son serveur cache, il répond directement à la requête.

2. Le serveur DNS interrogé n’a pas les informations en cache, mais il connaît un des serveurs de zone du domaine demandé. Il interroge alors directement ce serveur pour obtenir l’adresse IP demandée et ainsi répondre à la requête.

3. Le serveur n’a ni les informations en cache, ni connaissance de la zone demandée. Il génère alors une requête DNS vers un serveur racine pour obtenir une réponse.

A noter qu’un client peut également effectuer une requête DNS à partir d’une adresse IP, en vue de connaître le FQDN associé. On parle alors de requête inverse ou reverse DNS.