Serveur DNS

Domain Name System

Pour les articles homonymes, voir DNS.

Pile de protocoles

7 • Application 6 • Présentation 5 • Session 4 • Transport 3 • Réseau 2 • Liaison 1 • Physique

Modèle Internet Modèle OSI

Le Domain Name System (ou DNS, système de noms de domaine) est un service permettant d'établir une correspondance entre une adresse IP et un nom de domaine et, plus généralement, de trouver une information à partir d'un nom de domaine. À la demande de Jon Postel, Paul Mockapetris inventa le « Domain Name system » en 1983 et écrivit la première implémentation.

Associer une adresse IP et un nom de domaine

Les ordinateurs connectés à un réseau IP, par exemple Internet, possèdent tous une adresse IP. Ces adresses sont numériques afin d'être plus facilement traitées par une machine. Selon IPv4, elles prennent la forme xxx.yyy.zzz.aaa, où xxx, yyy, zzz et aaa sont quatre nombres variant entre 0 et 255 (en système décimal). Selon IPv6, les IP sont de la forme aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh, où a, b, c, d, e, f, g et h représentent des caractères au format hexadécimal. Il n'est pas évident pour un humain de retenir ce numéro lorsque l'on désire accéder à un ordinateur d'Internet. C'est pourquoi un mécanisme a été mis en place pour permettre d'associer à une adresse IP un nom intelligible, humainement plus simple à retenir, appelé nom de domaine. Résoudre un nom de domaine, comme par exemple fr.wikipedia.org, c'est trouver l'adresse IP qui lui est associée.

Fichier HOSTS

Avant le DNS, la résolution devait se faire grâce à un fichier texte appelé HOSTS, local à chaque ordinateur. Sous UNIX, il se trouve dans le répertoire /etc. Sous Windows, il se trouve par défaut dans %SystemRoot%\system32\drivers\etc.

Dans ce fichier, chaque ligne correspond à une adresse IP à laquelle peuvent être associés un ou plusieurs noms de domaine. Ce système pose un problème de maintenance car le fichier doit être recopié sur tous les ordinateurs du réseau. On ne peut pas non plus organiser hiérarchiquement les domaines. C'est pour résoudre ce problème que Paul Mockapetris a mis au point le DNS en 1983.

Résolution et résolution inverse avec DNS

Avec DNS, la résolution se fait par l'intermédiaire d'un serveur. Quand un utilisateur souhaite accéder à un serveur web, par exemple celui de fr.wikipedia.org, son ordinateur émet une requête spéciale à un serveur DNS, demandant 'Quelle est l'adresse de fr.wikipedia.org ?'. Le serveur répond en retournant l'adresse IP du serveur, qui est dans ce cas-ci, 91.198.174.2.

Il est également possible de poser la question inverse, à savoir 'Quel est le nom de domaine ou quels sont les noms de domaines de telle adresse IP ?'. On parle alors de résolution inverse (inverse query) ou de PTR Lookup en référence à l'enregistrement DNS de type PTR.

Note : Cette déclaration inverse est importante sur les adresses IP publiques Internet puisque la non existence d'une résolution inverse peut entrainer le refus d'accès à un service. Pour exemple, un serveur de messagerie électronique se présentant en envoi avec une adresse IP n'ayant pas de résolution inverse (PTR) a de grandes chances de se voir refuser, par l'hôte distant, la transmission du courrier (message de refus de type : 'IP lookup failed').

Plusieurs noms de domaine peuvent pointer vers une même adresse IP (via les enregistrements A d'IPv4 ou AAAA d'IPv6).

De même, une adresse IP peut être résolue en différents noms de domaine via l'enregistrement de plusieurs entrées PTR dans le sous-domaine arpa. dédié à cette adresse (in-addr.arpa. pour IPv4 et ip6.arpa. pour IPv6). L'utilisation d'enregistrements PTR multiples pour une même adresse IP est notamment présente dans le cadre de l'hébergement virtuel de multiples domaines web derrière la même adresse IP^[1].

Technique du DNS Round-Robin

Lorsqu'un service génère un trafic important, celui-ci peut faire appel à la technique du DNS Round-Robin (en français tourniquet), qui consiste à associer plusieurs adresses IP à un nom de domaine. Les différentes versions de Wikipedia, comme fr.wikipedia.org par exemple, sont associées à plusieurs adresses IP : 207.142.131.235, 207.142.131.236, 207.142.131.245, 207.142.131.246, 207.142.131.247 et 207.142.131.248. Une rotation circulaire entre ces différentes adresses permet ainsi de répartir la charge générée par ce trafic important, entre les différentes machines, ayant ces adresses IP. Il faut cependant nuancer cette répartition car elle n'a lieu qu'à la résolution du nom d'hôte et reste par la suite en cache sur les différents resolvers (client DNS).

Fully Qualified Domain Name

Les noms d'hôtes sont identifiés de manière unique grâce à leur FQDN (Fully Qualified Domain Name, ou Nom de Domaine Pleinement Qualifié). Ils ont le format hôte.domaine.tld. où hôte correspond au nom d'hôte de la machine et domaine.tld. au domaine auquel l'hôte appartient (tld signifie ici Top Level Domain, c'est-à-dire l'ensemble des domaines situés directement sous la racine -root .- comme .fr. .com. ou bien .org.). fr.wikipedia.org., par exemple, est composé du domaine générique org, du domaine déposé wikipedia et du nom d'hôte fr.

Le point final, facultatif dans la plupart des commandes, est indispensable en ce qui concerne le DNS. Ainsi, pour pinguer une machine ayant pour FQDN machine.domaine.tld., utiliser la commande « ping machine.domaine.tld » ne pose pas de problème, même si le FQDN est incomplet ; toutefois utiliser l'adresse avec le point final « ping machine.domaine.tld. » est plus juste, mais produit un résultat identique. Ainsi, taper http://fr.wikipedia.org. à la place du plus classique http://fr.wikipedia.org dans la barre d'adresse des navigateurs web ne fait aucune différence, car avant d'effectuer la requête DNS, l'implémentation de la pile TCP/IP sous-jacente se charge de rajouter le point final nécessaire à la résolution de nom. À l'inverse, omettre le point final peut avoir des conséquences importantes avec certaines versions de BIND : spécifier dans le fichier de la zone domaine.tld. que l'hôte machine.domaine.tld a pour adresse IP 1.2.3.4 (à l'aide d'un enregistrement A, voir ci-dessous) revient en fait à spécifier que la machine a pour FQDN machine.domaine.tld.domaine.tld.

Un système distribué

Il existe des centaines de milliers de serveurs DNS dans le monde entier. Chacun n'a en réalité à sa disposition qu'un ensemble d'informations restreint.

Quand un hôte a besoin de résoudre un nom de domaine, il doit connaître l'adresse IP d'un ou plusieurs serveurs de noms récursifs, c'est-à-dire qui vont éventuellement faire suivre la requête à un ou plusieurs autres serveurs de noms pour fournir une réponse. Les adresses IP de ces serveurs récursifs sont souvent obtenues via DHCP ou encore configurés en dur sur la machine hôte. Les fournisseurs d'accès à Internet mettent normalement à disposition de leurs clients ces serveurs récursifs.

Quand un serveur DNS (par exemple, celui d'un fournisseur d'accès à Internet) doit trouver l'adresse IP de fr.wikipedia.org, une certaine communication s'instaure alors avec d'autres serveurs DNS. Tout d'abord, notre serveur demande à des serveurs DNS peu nombreux appelés serveurs racine quels serveurs peuvent lui répondre pour la zone org. Parmi ceux-ci, notre serveur va en choisir un pour savoir quel serveur est capable de lui répondre pour la zone wikipedia.org. C'est ce dernier qui pourra lui donner l'adresse IP de fr.wikipedia.org.

Pour optimiser les requêtes ultérieures, la plupart des serveurs DNS (et notamment ceux des fournisseurs d'accès à Internet) font aussi office de DNS cache : ils gardent en mémoire la réponse d'une résolution de nom afin de ne pas effectuer ce processus à nouveau ultérieurement.

Un nom de domaine peut utiliser plusieurs serveurs DNS. Généralement, les noms de domaines en utilisent au moins deux : un primaire et au moins un secondaire. L'ensemble des serveurs primaires et secondaires font autorité pour un domaine, c'est-à-dire que la réponse ne fait pas appel à un autre serveur ou à un cache. Les serveurs des fournisseurs d'accès à Internet fournissent des réponses qui ne sont pas nécessairement à jour, à cause du cache mis en place. On parle alors de réponse ne faisant pas autorité ((en)non-authoritative answer).

Pour trouver le nom de domaine d'une IP, on utilise le même principe. Dans un nom de domaine, la partie la plus générale est à droite : org dans fr.wikipedia.org. Dans une adresse IP, c'est le contraire : 213 est la partie la plus générale de 213.228.0.42. Pour conserver une logique cohérente, on inverse l'ordre des quatre termes de l'adresse et on la concatène au pseudo domaine in-addr.arpa. Ainsi, par exemple, pour trouver le nom de domaine de l'adresse IP 91.198.174.2, on résout 2.174.198.91.in-addr.arpa, qui est un pointeur vers rr.knams.wikimedia.org.

Cette architecture garantit au réseau Internet une certaine continuité dans la résolution des noms. Quand un serveur DNS tombe en panne, le bon fonctionnement de la résolution de nom n'est pas remis en cause dans la mesure où des serveurs secondaires sont disponibles. De plus, le DNS permet de mettre à jour l'adresse IP associée à un nom de domaine dans le monde entier facilement et assez rapidement (un délai de 48 heures est généralement suffisant, en fonction de la configuration du nom de domaine).

Principaux enregistrements DNS

Les principaux enregistrements définis par un DNS sont :

• A record ou address record qui fait correspondre un nom d'hôte à une adresse IPv4 de 32 bits distribués sur quatre octets ex: 123.234.1.2 ;
• AAAA record ou IPv6 address record qui fait correspondre un nom d'hôte à une adresse IPv6 de 128 bits distribués sur seize octets ;
• CNAME record ou canonical name record qui permet de faire d'un domaine un alias vers un autre. Cet alias hérite de tous les sous-domaines de l'original ;
• MX record ou mail exchange record qui définit les serveurs de courriel pour ce domaine ;
• PTR record ou pointer record qui associe une adresse IP à un enregistrement de nom de domaine, aussi dit « reverse » puisque il fait exactement le contraire du A record ;
• NS record ou name server record qui définit les serveurs DNS de ce domaine ;
• SOA record ou Start Of Authority record qui donne les informations générales de la zone : serveur principal, courriel de contact, différentes durées dont celle d'expiration, numéro de série de la zone ;
• SRV record qui généralise la notion de MX record, standardisé dans la RFC 2782 ;
• NAPTR record ou Name Authority Pointer record qui donne accès à des règles de réécriture de l'information, permettant des correspondances assez lâches entre un nom de domaine et une ressource. Il est spécifié dans la RFC 3403 ;
• TXT record permet à un administrateur d'insérer un texte quelconque dans un enregistrement DNS (par exemple, cet enregistrement était utilisé pour implémenter la spécification Sender Policy Framework) ;
• d'autres types d'enregistrements sont utilisés occasionnellement, ils servent simplement à donner des informations (par exemple, un enregistrement de type LOC indique l'emplacement physique d'un hôte, c'est-à-dire sa latitude et sa longitude).

PTR record

À l'inverse d'une entrée de type A, une entrée PTR indique à quel nom d'hôte correspond une adresse IPv4. Si elle est spécifiée, elle doit contenir l'enregistrement inverse d'une entrée DNS A. Par exemple, cet enregistrement PTR :

51.51.51.62.in-addr.arpa IN PTR 3E333333.dslaccess.aol.com

correspond à cette entrée A :

3E333333.dslaccess.aol.com IN A 62.51.51.51

Les enregistrements PTR sont aussi utilisés pour spécifier le nom d'hôte correspondant à une adresse IPv6. Ces entrées de type PTR sont enregistrées dans la zone ip6.arpa., pendant de la zone in-addr.arpa. des adresses IPv4.

La règle permettant de retrouver l'entrée correspondant à une adresse IPv6 est similaire à celle pour les adresses IPv4 (renversement de l'adresse et recherche dans un sous-domaine dédié de la zone arpa.), mais diffère au niveau du nombre de bits de l'adresse utilisés pour rédiger le nom du domaine où rechercher le champ PTR  : là où pour IPv4 le découpage de l'adresse se fait par octet, pour IPv6 c'est un découpage par quartet qui est utilisé.

Par exemple^[2], à l'adresse IPv6 :

4321:0:1:2:3:4:567:89ab

correspond le nom de domaine :

b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.ip6.arpa.

MX record

Une entrée DNS MX indique les serveurs SMTP à contacter pour envoyer un courriel à un utilisateur d'un domaine donné. Sous Unix on peut récupérer les entrées MX correspondant à un domaine à l'aide du programme host(1) (entre autres). Par exemple :

$ host -v -t MX wikimedia.org
[...]
;; QUESTION SECTION:
;wikimedia.org.                 IN      MX

;; ANSWER SECTION:
wikimedia.org.          3600    IN      MX      10 mchenry.wikimedia.org.
wikimedia.org.          3600    IN      MX      50 lists.wikimedia.org.

On voit que les courriels envoyé à une adresse en @wikimedia.org sont en fait envoyés au serveur mchenry.wikimedia.org. ou lists.wikimedia.org.. Le nombre précédant le serveur représente la priorité. Normalement on est censé utiliser le serveur avec la priorité numérique la plus petite. Ici, c'est donc mchenry.wikimedia.org. qui doit être utilisé en priorité avec une valeur de 10.

Les entrées MX sont rendues obsolètes par les entrées SRV qui permettent de faire la même chose mais pour tous les services, pas juste SMTP (le courriel). L'avantage des entrées SRV par rapport aux entrées MX est aussi qu'elles permettent de choisir un port arbitraire pour chaque service ainsi que de faire de la répartition de charge plus efficacement. L'inconvénient c'est qu'il existe encore peu de programmes clients qui gèrent les entrées SRV.

NAPTR record

Peu répandus à l'heure actuelle (ils sont surtout utilisés par ENUM). Ils décrivent une réécriture d'une clé (un nom de domaine) en URI. Par exemple, dans ENUM, des enregistrements NAPTR peuvent être utilisés pour trouver l'adresse de courrier électronique d'une personne, connaissant son numéro de téléphone (qui sert de clé à ENUM).

Ses paramètres sont dans l'ordre :

1. Order : indique dans quel ordre évaluer les enregistrements NAPTR ; tant qu'il reste des enregistrements d'une certaine valeur de order à examiner, les enregistrements des valeurs suivantes de order n'entrent pas en considération ;
2. Preference : donne une indication de priorité relative entre plusieurs enregistrements NAPTR qui ont la même valeur de order ;
3. Flags : indique par exemple si l'enregistrement décrit une réécriture transitoire (dont le résultat est un nom de domaine pointant sur un autre enregistrement NAPTR) ou une réécriture finale ; la sémantique précise du paramètre flags dépend de l'application DDDS ('Dynamic Delegation Discovery System', RFC 3401) employée (ENUM en est une parmi d'autres) ;
4. Services : décrit le service de réécriture ; par exemple dans ENUM, la valeur de services spécifie le type de l'URI résultante ; la sémantique précise de ce paramètre dépend également de l'application DDDS employée ;
5. Regexp : l'opération de réécriture elle-même, formalisée en une expression régulière ; cette expression régulière est à appliquer à la clé ; ne peut être fourni en même temps que replacement ;
6. Replacement : nom de domaine pointant sur un autre enregistrement NAPTR, permettant par exemple une réécriture transitoire par délégation ; ne peut être fourni en même temps que regexp.

L'enregistrement NAPTR est défini par la RFC 3403.

SOA record

Cet enregistrement permet d'indiquer le serveur de nom faisant autorité, un contact technique et des paramètres d'expiration. Ces paramètres sont dans l'ordre :

1. Serial : indique un numéro de version pour la zone ; ce nombre doit être incrémenté à chaque modification du fichier zone ; on utilise par convention une date au format yyyymmddhhmm ;
2. Refresh : le nombre de secondes entre les demandes de mise à jour réalisées depuis le serveur secondaire ou les serveurs esclaves ;
3. Retry : le nombre de secondes que doivent attendre le serveur secondaire ou les serveurs esclaves lorsque leur précédente requête a échouée ;
4. Expire : le nombre de secondes après laquelle la zone est considérée comme gelée si le secondaire ou les esclaves ne peuvent joindre le serveur primaire ;
5. Minimum : utilisé pour déterminer la durée de vie minimum du fichier de zone et, par conséquent, la durée pendant laquelle conserver en cache les réponses qui correspondent à des demandes d'enregistrements inexistants.

Exemple d'une entrée SOA

maboite.com.   IN SOA  serveur.example.com contact.example.com (
                       200612301905  ;serial (version)
                       3600          ;refresh period
                       900           ;retry refresh this often
                       604800        ;expiration period
                       3600          ;minimum TTL
                       )

Les versions récentes de BIND (named) acceptent les suffixes M, H, D ou W pour indiquer un intervalle de temps en minutes, heures, jours ou semaines respectivement.

Sécurité du DNS

Le protocole DNS a été conçu avec un souci minimum de la sécurité. Plusieurs failles de sécurité du protocole DNS ont été identifiées depuis. Les principales failles du DNS ont été décrites dans le RFC 3833 publié en août 2004.^[3]

Interception des paquets

Une des failles mises en avant est la possibilité d'intercepter les paquets transmis. Les serveurs DNS communiquent au moyen de paquets uniques et non signés. Ces deux spécificités rendent l'interception très aisée. L'interception peut se concrétiser de différentes manières, notamment via une attaque de l'homme du milieu, de l'écoute des données transférées et de l'envoie de réponse falsifiée (voir paragraphe ci-dessous).

Fabrication d'une réponse

Les paquets des serveurs DNS étant faiblement sécurisés, authentifier par un numéro de requête, il est possible de fabriquer de faux paquets. Par exemple, un utilisateur qui souhaite accéder au site http://mabanque.com fait une demande au site DNS. Il suffit à ce qu'un pirate informatique réponde à la requête de l'utilisateur avant le serveur DNS pour que l'utilisateur se retrouve sur le site http://mesvirus.com.

Corruption des données

La trahison par un serveur, ou corruption de données, est, techniquement, identique à une interception des paquets. La seule différence venant du fait que l'utilisateur envoie volontairement sa requête au serveur. Cette situation peut arriver lorsque, par exemple, l'opérateur du serveur DNS souhaite mettre en avant un partenaire commercial.

Empoisonnement du cache DNS

Article détaillé : empoisonnement du cache DNS.

^[4]

Le Déni de service

Article détaillé : Déni de service.

Une attaque par déni de service (ou attaque par saturation ; en anglais, Denial of Service attack ou DoS attack) est une attaque sur un serveur informatique qui résulte en l'incapacité pour le serveur de répondre aux requêtes de ses clients.

DNSSEC

Article détaillé : DNSSEC.

Pour contrer ces vulnérabilités, le protocole DNSSEC a été développé.

Exemple d'attaques majeures contre des serveurs DNS

En juillet 2008, quelques jours après la publication du rapport de la "United States Computer Emergency Readiness Team" concernant la faille de sécurité des serveurs DNS permettant d'empoisonner leur cache, plusieurs serveurs DNS majeurs ont subis des attaques.^[5] Une des plus importantes fut celle menée contre les serveurs de AT&T's. L'attaque empoisonnant le cache des serveurs DNS de AT&T's a permis au pirate informatique de rediriger toutes les requêtes vers Google vers un site de phishing.^[6]

Notes et références

1. ↑ Dans le cas d'hébergement massif de domaines virtuels derrière une même adresse IP, il est recommandé de ne pas appliquer sans discernement la règle un enregistrement PTR par enregistrement A (ou AAAA) : le nombre des champs PTR à renvoyer pouvant faire dépasser à la réponse la taille des paquets UDP et entraîner l'utilisation du protocole TCP (plus coûteux en resources) pour envoyer la réponse à la requête DNS ; cf la section "4.4 Usage and deployment considerations" du draft draft-ietf-dnsop-reverse-mapping-considerations
2. ↑ tiré de la section « 2.5 IP6.ARPA Domain » de la RFC 3596
3. ↑ http://www.rfc-archive.org/getrfc.php?rfc=3833
4. ↑ http://www.kb.cert.org/vuls/id/800113
5. ↑ http://blogs.orange-business.com/securite/2008/07/dns-poisoning-premieres-attaques.html
6. ↑ http://www.pcworld.com/businesscenter/article/149126/dns_attack_writer_a_victim_of_his_own_creation.html

Voir aussi

Articles connexes

• Dig
• DNS black holing
• DNS Black Listing
• Empoisonnement du cache DNS
• Hébergement de nom de domaine
• Hosts
• ICANN
• Les réseaux TCP/IP : un wikilivre de la bibliothèque du département informatique
• Nslookup
• Protocole réseau passant difficilement les pare-feu
• Réseau (informatique)
• RFC
• Serveurs DNS Racine

Liens externes

• (fr) Test sur la Vulnérabilité DNS, stats de la zone française
• (fr) DNS sur le site commentcamarche.net
• (fr) Petit cours sur le DNS sur le site « L'Internet Rapide et Permanent »
• (fr) Support Cours de l'UREC/CNRS sur le DNS[pdf]
• (fr) Sécurite et DNS[pdf] : Failles intrinsèques d'un protocole clef
• (fr) Sebsauvage : DNS facile (et comment avoir son nom de domaine)
• (fr) Liste de serveurs DNS publics
• (fr) Auto-formation au DNS par l'AFNIC
• (fr) DNS dans tous ses détails
• (en) RFC relatives au DNS
• (en) Bonne explication des NAPTR par Nominet

Ce document provient de « Domain Name System ».