DNS - DEPARTEMENT INFORMATIQUE IUT Aix

Réseaux - Cours 9
Service de Nom de Domaine (DNS)
Cyril Pain-Barre
IUT Informatique Aix-en-Provence
version du 26/3/2013
Cyril Pain-Barre
DNS
1 / 16
Le DNS (Domain Name Service)
(RFC 1034 et 1035)
Cyril Pain-Barre
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.187.4, . . . ),
c’est franchement pénible !
En revanche, retenir des noms comme www.free.fr,
www.google.com, allegro.iut.univ-aix.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.iut.univ-aix.fr en 139.124.187.4
et inversement : résolution inverse
Cyril Pain-Barre
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
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
uk
de
tv
:
:
:
:
France
Royaume-Uni
Allemagne
ı̂le Tuvalu (qui en profite bien. . . )
Cyril Pain-Barre
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-aix.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)
Cyril Pain-Barre
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
DNS
7 / 16
DNS : terminologie
Le terme domaine désigne à la fois un domaine, un sous-domaine, etc :
fr, univ-aix.fr et iut.univ-aix.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 :
iut.univ-aix.fr ≡ IUT.Univ-Aix.fr
Les points séparent des labels : iut.univ-aix.fr est composé des 3
labels iut, univ-aix et fr
On ne peut distinguer un domaine d’un nom d’ordinateur :
allegro.iut.univ-aix.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-aix.fr. (' réf absolue)
allegro n’est pas un FQDN mais allegro.iut.univ-aix.fr. oui
Cyril Pain-Barre
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
com
serveur pour
google.com
serveur pour
org
serveur pour
lsis.org
Cyril Pain-Barre
...
serveur pour
fr
serveur pour
free.fr
serveur pour
univ−aix.fr
serveur pour
hd.free.fr
serveur pour
iut.univ−aix.fr
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
com
serveur pour
google.com
serveur pour
org
serveur pour
lsis.org
Cyril Pain-Barre
...
serveur pour
free.fr et
hd.free.fr
DNS
serveur pour
fr
serveur pour
univ−aix.fr et
iut.univ−aix.fr
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
DNS
11 / 16
Situation du DNS dans TCP/IP
Le DNS est un protocole d’application
DNS peut utiliser indépendamment UDP ou
TCP
DNS
Pour la quasi-totalité des requêtes DNS, c’est
UDP qui est utilisé car il est rapide
UDP
Mais certaines requêtes engendrent des réponses
longues (supérieures à 512 octets) : dans ce cas,
TCP est utilisé (notamment pour les transferts
de zone entre serveurs)
TCP
IP
Les serveurs DNS ont un port réservé en
UDP et TCP : le 53
Cyril Pain-Barre
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
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
DNS
14 / 16
Exemple d’enregistrements (source Wikipedia)
délégation de zone dans le domaine .org : type NS
wikipedia
wikipedia
wikipedia
NS
NS
NS
ns1.wikimedia.org.
ns2.wikimedia.org.
ns0.wikimedia.org.
enregistrements IPv4 : type A
ns0.wikimedia.org.
ns1.wikimedia.org.
ns2.wikimedia.org.
IN
IN
IN
A
A
A
208.80.152.130
208.80.152.142
91.198.174.4
serveur de courrier (SMTP) : type MX
wikimedia.org.
wikimedia.org.
IN
IN
MX
MX
10 mchenry.wikimedia.org.
50 lists.wikimedia.org.
alias : type CNAME
fr.wikipedia.org.
text.wikimedia.org.
text.esams.wikimedia.org.
IN
IN
IN
Cyril Pain-Barre
CNAME
CNAME
A
DNS
text.wikimedia.org.
text.esams.wikimedia.org.
91.198.174.232
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.187.4 en allegro.iut.univ-aix.fr
Pour cela, il faut déclarer un champ PTR pour l’ordinateur :
4.187.124.139.in-addr.arpa.
IN
PTR
allegro.iut.univ-aix.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
DNS
16 / 16