M2102 - Architecture des réseaux

8 - Service de Nom de Domaine (DNS)

Cyril Pain-Barre

IUT Aix-Marseille - Dept INFO Aix

version du 10/3/2014

Cyril Pain-Barre 8 - DNS 1 / 16

Le DNS (Domain Name Service)
(RFC 1034 et 1035)

Cyril Pain-Barre 8 - DNS 2 / 16

Introduction

Se rappeler d’une adresse IP est assez difficile, ex :

212.27.48.10
Mais alors de plusieurs (209.85.137.99, 139.124.181.131, . . . ),
c’est franchement pénible !
En revanche, retenir des noms comme www.free.fr,
www.google.com, allegro.aix.univ-amu.fr, c’est bien
plus facile
C’est pourquoi le DNS existe : il permet de nommer des
ordinateurs et de ”résoudre” des noms en adresses IP :
www.free.fr en 212.27.48.10
www.google.com en 209.85.137.99
allegro.aix.univ-amu.fr en 139.124.181.131
et inversement : résolution inverse

Cyril Pain-Barre 8 - DNS 3 / 16

Origine du DNS

Au début d’internet, l’espace de noms était ”plat” et admettait

des noms de type :
serveur
capucine
gandalf
...
et centralisé : géré par le NIC (Network Information Center)
puis plus tard par l’INTERNIC (Internet Information Center)
mais la multiplicité des ordinateurs connectés et nommés a
rendu la gestion trop lourde
et un nom pris ne pouvait plus être utilisé
ce qui s’est traduit par l’utilisation de noms de plus en plus
obscurs : serveurbis, gandalfsecond, etc.

Cyril Pain-Barre 8 - DNS 4 / 16

DNS : espace de noms hiérarchisé et décentralisé
Avec le DNS, l’espace de noms est organisé en une hiérarchie au
sommet de laquelle figure la racine et immédiatement en dessous les
TLD (Top-Level Domain) ou domaines de niveau supérieurs :
racine

com edu org ... fr uk top−level domains

L’ICANN (Internet Corporation for Assigned Names and Numbers) a en

charge la création des TLD et a créé notamment les TLD suivants :
com : entreprises commerciales
edu : établissements d’enseignement
org : organisations diverses
un TLD par code pays sur 2 lettres (norme ISO 3166) :
fr : France
uk : Royaume-Uni
de : Allemagne
tv : ı̂le Tuvalu (qui en profite bien. . . )
Cyril Pain-Barre 8 - DNS 5 / 16
DNS : délégation de gestion de (sous-)domaine
L’ICANN a ensuite délégué la gestion des sous-domaines des TLD à
des entreprises ou organisations gouvernementales :
com et net à la société VeriSign
edu, org et autres à l’INTERNIC
fr et re (ı̂le de la réunion) à l’AFNIC (Association Française pour le
Nommage Internet en Coopération)
etc.
Ces gestionnaires vendent (parfois via des registrars) les sous-domaines
de leurs TLD et en délèguent la gestion à leurs acheteurs :
google.com
free.fr
gouv.fr
univ-amu.fr
Le propriétaire d’un sous-domaine peut ensuite le décliner à sa guise afin
de nommer des ordinateurs et/ou de créer des sous-sous-domaines :
www.free.fr (ordinateur)
smtp.free.fr (ordinateur)
hd.free.fr (sous-sous-domaine)
aix.univ-amu.fr (sous-sous-domaine)
Cyril Pain-Barre 8 - DNS 6 / 16
Achat/Dépôt d’un sous-domaine

Se fait généralement pour une durée limitée (1 à 10 ans) auprès d’un

registrar
Doit être associé à l’identité et l’adresse postale d’une personne qui
doit fournir 3 types d’informations :
Administrative Contact : responsable du sous-domaine
Billing Contact : payeur du sous-domaine
Technical Contact : responsable technique du sous-domaine
le tout pouvant être la même personne
Ces informations sont publiques et consultables par tout le monde :
sous Unix, en utilisant la commande whois
sur le Web, grâce à des serveurs WHOIS (ex : http://www.whois.net)

Cyril Pain-Barre 8 - DNS 7 / 16

DNS : terminologie
Le terme domaine désigne à la fois un domaine, un sous-domaine, etc :
fr, univ-amu.fr et aix.univ-amu.fr sont des domaines
Le nom d’un domaine ne doit pas dépasser 63 caractères
Au début, caractères ASCII (lettres a-z, chiffres 0-9, tiret -), puis
extension Punycode (RFC 3490)
Le DNS est insensible à la casse :
aix.univ-amu.fr ≡ Aix.Univ-AMU.fr
Les points séparent des labels : aix.univ-amu.fr est composé des 3
labels aix, univ-amu et fr
On ne peut distinguer un domaine d’un nom d’ordinateur :
allegro.aix.univ-amu.fr est un domaine (correspondant à un
ordinateur)
Un nom complètement qualifié ou FQDN (Fully Qualified Domain
Name) est un domaine contenant sa position dans la hiérarchie et
devrait se terminer par un point : univ-amu.fr. (' réf absolue)
allegro n’est pas un FQDN mais allegro.aix.univ-amu.fr. oui
Cyril Pain-Barre 8 - DNS 8 / 16
DNS : base de données répartie, efficace et fiable
Un dépositaire de domaine doit mettre à disposition au moins 2
serveurs de noms (sur des réseaux en principe différents) chargés de
répondre aux requêtes concernant les noms locaux
Les serveurs de noms d’un domaine doivent connaı̂tre les serveurs de
noms racines, du domaine parent et des domaines fils (délégation de
zone)
Les relations (non physiques) entre les différents serveurs peuvent être
illustrées ainsi (en ne prenant qu’un serveur par domaine) :
serveur
racine

serveur pour serveur pour serveur pour

com org ... fr

serveur pour serveur pour serveur pour serveur pour

google.com lsis.org free.fr univ−aix.fr

serveur pour serveur pour

hd.free.fr iut.univ−aix.fr

Cyril Pain-Barre 8 - DNS 9 / 16

DNS : base de données répartie, efficace et fiable

Un serveur de noms peut gérer un domaine ainsi que plusieurs

sous-domaines
Par exemple, un registrar peut gérer lui-même les domaines qu’il vend
Les schéma en est réduit d’autant et moins de serveurs seront sollicités
pour résoudre un nom :
serveur
racine

serveur pour serveur pour serveur pour

com org ... fr

serveur pour serveur pour serveur pour serveur pour

google.com lsis.org free.fr et univ−aix.fr et
hd.free.fr iut.univ−aix.fr

Cyril Pain-Barre 8 - DNS 10 / 16

DNS : la résolution de noms

Tout hôte doit connaı̂tre au moins un serveur de noms (en principe de

son domaine mais ce n’est pas une obligation)
Sur un hôte, le client DNS effectuant la résolution de noms est appelé
solveur de noms
Pour résoudre un nom (ou autre requête), le solveur s’adresse à son
serveur de noms. Deux possibilités :
résolution récursive : s’il ne connaı̂t pas la réponse, le serveur est chargé
de la trouver. Il contactera un autre serveur, etc., et la réponse reviendra
résolution itérative : s’il ne connaı̂t pas la réponse, le serveur peut
indiquer quel serveur est susceptible de la connaı̂tre. Le solveur doit
ensuite effectuer la recherche seul en contactant ce serveur, etc., jusqu’à
contacter un serveur en mesure de lui répondre

Dans le cas normal, les solveurs demandent toujours une résolution ré-
cursive. Pour des raisons de sécurité, elle est souvent interdite aux hôtes
externes au réseau local du serveur.

Cyril Pain-Barre 8 - DNS 11 / 16

Situation du DNS dans TCP/IP

Le DNS est un protocole d’application

DNS peut utiliser indépendamment UDP ou
DNS
TCP
Pour la quasi-totalité des requêtes DNS, c’est
UDP qui est utilisé car il est rapide
UDP TCP
Mais certaines requêtes engendrent des réponses
longues (supérieures à 512 octets) : dans ce cas,
TCP est utilisé (notamment pour les transferts
IP
de zone entre serveurs)
Les serveurs DNS ont un port réservé en
UDP et TCP : le 53

Cyril Pain-Barre 8 - DNS 12 / 16

Utilisation de caches DNS

Lorsqu’un serveur DNS a réalisé une résolution récursive, il

enregistre la réponse obtenue dans un cache
Si un autre client lui pose la même question, il utilisera son
cache pour répondre mais indiquera dans la réponse qu’il
n’avait pas autorité pour répondre (Non-authoritative answer)
et précisera auprès de quel serveur le client peut espérer une
réponse ferme
Une entrée dans le cache à une durée de vie (TTL) qui a été
indiquée dans la réponse reçue par le serveur
Elle sera enlevée du cache lorsque sa durée de vie expirera

Cyril Pain-Barre 8 - DNS 13 / 16

Le différentes informations d’une base DNS
Le DNS ne se limite pas à la simple résolution de noms
Différents types d’informations (enregistrements DNS) sont gérés par
un serveur et ont un code. En particulier :
A : Adresse IPv4 d’ordinateur
AAAA : Adresse IPv6 d’ordinateur
MX : (Mail eXchanger) adresse du serveur SMTP du domaine. Il peut y
en avoir plusieurs, chacun avec une priorité (le plus petit est prioritaire)
CNAME : nom canonique pour un alias (autre nom pour le domaine)
NS : (Name Server) nom d’un serveur de noms du domaine
PTR : lien vers un autre nom de domaine. Utilisé surtout pour la
résolution inverse
SOA : (Start Of Authority) plusieurs paramètres concernant le domaine :
nom du serveur primaire de la zone
adresse mail du responsable, où @ est remplacé par . (point)
durée de vie (TTL) des enregistrements fournis
et autres choses

Une requête à un serveur de noms précise le type d’information voulue en

réponse (ou ANY).
Cyril Pain-Barre 8 - DNS 14 / 16
Exemple d’enregistrements (source Wikipedia)

délégation de zone dans le domaine .org : type NS

wikipedia NS ns1.wikimedia.org.
wikipedia NS ns2.wikimedia.org.
wikipedia NS ns0.wikimedia.org.
enregistrements IPv4 : type A
ns0.wikimedia.org. IN A 208.80.152.130
ns1.wikimedia.org. IN A 208.80.152.142
ns2.wikimedia.org. IN A 91.198.174.4
serveur de courrier (SMTP) : type MX
wikimedia.org. IN MX 10 mchenry.wikimedia.org.
wikimedia.org. IN MX 50 lists.wikimedia.org.
alias : type CNAME
fr.wikipedia.org. IN CNAME text.wikimedia.org.
text.wikimedia.org. IN CNAME text.esams.wikimedia.org.
text.esams.wikimedia.org. IN A 91.198.174.232

Cyril Pain-Barre 8 - DNS 15 / 16

La résolution inverse

La résolution inverse consiste à obtenir le FQDN d’un hôte à partir de

son adresse IP
Exemple : traduire 139.124.181.131 en allegro.aix.univ-amu.fr
Pour cela, il faut déclarer un champ PTR pour l’ordinateur :
131.181.124.139.in-addr.arpa. IN PTR
allegro.aix.univ-amu.fr.
le serveur de noms doit aussi gérer le sous-domaine de in-addr.arpa
correspondant
soit w.x.y.z l’adresse d’un ordinateur, alors le serveur doit gérer :
w.in-addr.arpa. si le réseau est de classe A
x.w.in-addr.arpa. si le réseau est de classe B
y.x.w.in-addr.arpa. si le réseau est de classe C

Cyril Pain-Barre 8 - DNS 16 / 16