Domain Name System: Erwan - Mas@nic - FR Mohsen - Souissi@

Domain Name System
Erwan.Mas@nic.fr
Mohsen.Souissi@nic.fr
© AFNIC (06/10/03) DNS - 1 Formation 2003

Introduction

INTERNET
• Un espace de communication, sans frontière, où

des millions d 'ordinateurs sont connectés.
• Les services les plus courants :

- Le service Web
- La messagerie électronique

INTERNET
• L'ordinateur qui est connecté à Internet est

identifié par numéro l' adresse IP .
exemple : 192.56.23.87
• Pour communiquer un programme doit connaître

l'adresse IP de son interlocuteur .

INTERNET et le nommage
• Les adresses IP ce n'est pas facile a mémoriser .
• On a préféré nommer les machines .
• On a construit une base de donnée, pour associer un nom et

une adresse IP .
 Système DNS

Le système DNS
(Domain Name System)

DNS
• Sommaire
• introduction
• arborescence
• architecture
• base de données
• une implémentation du DNS : BIND

Introduction (1)
• Besoin
• nommer une machine sur le réseau en effectuant
une correspondance entre le nom choisi et le
numéro IP (résolution de nom)
• trouver le nom d 'une machine à partir de son
numéro IP (résolution inverse)
• identifier un groupe de machines ayant des
ressources réseau communes (relais de messagerie,
... )

Introduction (2)
• Quelques exemples simples :
• nom de domaine : afnic.asso.fr
• nom de machine : ftp.afnic.asso.fr → adresse ip 192.134.4.13
• nom de machine : relay1.afnic.asso.fr → adresse ip 192.134.4.17
• nom de machine : www.afnic.asso.fr → adresse ip 192.134.4.11
• nom de machine : www.nic.fr → adresse ip 192.134.4.11
• adresse IP : 192.134.4.11 → www.afnic.asso.fr
→ www.nic.fr
• Une information dans le DNS indique vers quelle machine diriger le courrier électronique :
• Jean.Dupont@afnic.asso.fr → relay1.afnic.asso.fr → adresse ip 192.134.4.17

Introduction (3)
DNS ≠ URL
●
Soit un nom de domaine : abcd.fr
●
Url de site web :
- http://www.abcd.fr
- http://dom.abcd.fr/doc
- http://www.tot3.abcd.fr/doc
- http://abcd.fr/info/pub/prod.htm
●
Adresse de messagerie électronique :
- info@abcd.fr
- isabel@www.abcd.fr
- isabel@sousdom.abcd.fr

Introduction (4)
• Jusqu'en 1984 : fichier hosts.txt  /etc/hosts

• inadapté à grande échelle
• temps de diffusion des infos (par ftp !)
• système centralisé
• quelques centaines de machines dans les années 70
• plusieurs millions aujourd'hui
• correspondance statique
• ne contient que des infos réduites
• noms enregistrés sous le domaine arpa
 collision rapide de noms

Introduction (5)
• Après 1984 : Domain Name System
Paul Mockapetris - RFC 882 883 puis 1034 1035
• système hiérarchisé et distribué
• modèle en arborescence ( similaire à l'arborescence d'un système
de fichiers avec ses répertoires )
• gestion décentralisée des bases de données
 chaque site est maître de ses données
• informations complémentaires : relais de messagerie, ...
• correspondance dynamique
• limite les risques de collisions de noms

Introduction (6)
• RFC's
• 1032, 1033, 1034, 1035, 1101, 1122, 1123, 1183, 1713,
1794, 1912, 1995, 1996, 2010, 2136, 2137, 2181, 2308,
2317, 2535-2541, 2606
• Documentation
• http://www.dns.net/dnsrd/ (RFC, drafts, FAQ, ... )
• http://www.nic.fr/guides/
• http://www.nic.fr/formation/
• Livres
• DNS and BIND (Paul Albitz & Cricket Liu)

Arborescence (1)
• Organisation générale
• le système est organisé sous la forme d'une arborescence,
composée par
• la racine (root), sommet de l'arbre, qui est notée par un point
«.»
• des noeuds, identifiés par un label (fr , com , ... ), dont les
informations sont stockées dans une base de données propre à
chacun des noeuds
• base de données du système
• une base de données par noeud
• l'ensemble de ces bases de données constitue le système
d'information hiérarchique et distribué du DNS

Arborescence (2)
adresse IP  nom nom  adresse IP
arpa com net fr
in-addr apnic ripe Nic
193 192 whois whois www
0 1 ... 255
www.nic.fr. → 192.134.4.11
2 whois.ripe.net. → 193.1.2.133
133 193.1.2.133 → 133.2.1.193.in-addr.arpa. → whois.ripe.net

Arborescence (3)
• Parcours de l'arbre et nom de domaine

• la descente dans l'arbre est représentée de la droite vers la gauche
• chaque niveau de l'arborescence est séparé par un point
nic . fr .
racine
séparateur
2éme niveau 1er niveau

Arborescence (4)
arpa com tn net fr
in-addr ffti apnic ripe nic
193
whois = whois.ripe.net
0 1 ... 255
133 = 133.2.1.193.in-addr.arpa

Arborescence (5)
• Délégation d'un noeud père vers un noeud fils

• un noeud peut être père de plusieurs noeuds fils
• le lien est effectué en précisant au niveau du noeud père
où trouver la base de donnée des noeuds fils
• but
• distribuer la gestion de chaque noeud à des entités différentes
 une base de données pour chaque noeud, l'ensemble de ces
bases étant géré de façon décentralisé
• pour définir des domaines de responsabilités différentes

Arborescence (6)
• Dénomination des domaines

• caractères autorisés 'A...Z' 'a...z' '0...9' '-'
pas de différences entre majuscule et minuscule
• nom total limité à 255 caractères
• label est unique au niveau d'un noeud
• label au niveau d 'un noeud limité à 63 caractères

Arborescence (7)
• IDN - International Domain Name
• Prendre en compte les alphabets mondiaux
• Compatible avec le protocole DNS existant
• 4 RFC
• RFC 3454/RFC 3491/RFC 3490/RFC 3492
• Exemple:
http://france2.télévision-française.fr/

http://france2.xn-tlvision-franaise-msbzb.fr/

Arborescence (8)
• Notion de domaine et de zone

• le domaine est l'ensemble d'une sous arborescence
exemple : le domaine fr. rassemble toute la sous
arborescence à partir du noeud fr
• la zone est la partie descriptive pour un niveau donné :
elle est restreinte à un noeud
 une zone est constituée de la base de données décrivant
un noeud

Arborescence (9)

Arborescence (10)
• Résolution nom  numéro IP

• le nom de machine est formé en ajoutant le label
choisi suffixé avec « . » avec le domaine auquel
cette machine appartient
ns1 . nic . fr .
label racine
séparateur
2éme niveau 1er niveau

Arborescence (11)
• Analogie
un noeud contient à la fois des noms de machines et des

sous-domaines, comme, pour un système de fichiers, un
répertoire contient des fichiers et des sous-répertoires

Arborescence (12)
• Résolution inverse
• retrouver à partir d'un numéro IP le nom d'une
machine associée
• l'arborescence se trouve sous le domaine
in-addr.arpa (sous ip6.int pour ipv6)
• l'arborescence est subdivisée à partir de la notation
classique sur 4 octets des numéros IPv4

Arborescence (13)
• Parcours de l'arbre et résolution inverse

• le nom de domaine est inversé par apport au numéro IP
domaine : 133.2.1.193.in-addr.arpa.
pour le numéro IP : 193.1.2.133
• la descente dans l'arbre est représentée de la droite vers la gauche

• chaque niveau de l'arborescence est séparé par un point

Arborescence (14)
.
arpa com tn net fr
in-addr ffti ripe nic
193
whois = whois.ripe.net
0 1 ... 255
133 = 133.2.1.193.in-addr.arpa

Arborescence (15)
• Le même mécanisme s'applique pour la sous
arborescence in-addr.arpa comme pour les domaines
« classiques » (nic.fr) : par exemple le domaine
11.193.in-addr.arpa est un sous domaine du 193.in-
addr.arpa, le noeud 11.193.in-addr.arpa étant défini par
sa base de données
• Tout numéro officiellement attribué à une machine doit
être déclaré dans cette arborescence

Arborescence (16)
• Racine : 13 bases de données (serveurs de nom) répartis

dans le monde connaissant tous les serveurs des
domaines de 1er niveau (.fr .arpa .com ... )
• serveur origine géré par l 'IANA / ICANN
A.ROOT-SERVERS.NET
• serveurs miroirs
de
B.ROOT-SERVERS.NET
à
M.ROOT-SERVERS.NET

Arborescence (17)
• Top-level domain (TLD) : Domaine de 1er niveau -
RFC 1591
• à 2 lettres : code ISO-3166 de chaque pays
• à 3 lettres : .com, .net, .org, .edu, .gov, .mil,.int
• à 4 lettres : .arpa
• Nouveaux TLD ( juin 2001 ) :
• .biz, .info, .name, .aero, .coop, .info, .
museum

Architecture (1)
• Système client/serveur
• client
• resolver : interface cliente permettant d'interroger un serveur
• les machines clientes pointent généralement vers un serveur
par défaut (/etc/resolv.conf sur Unix)
• serveur
• chaque serveur gère sa propre base de données
• optimisation par des systèmes de cache et de réplication

Architecture (2)
• Au-dessus d 'IP
• service s'exécutant sur le port 53
 droits de super utilisateur ( unix )
• UDP et TCP
(TCP n'est pas réservé qu'au transfert de zone
et est utilisé si la taille de la réponse est supérieure à la limite
d 'un paquet UDP de 512 octets)
• RFC 1035

Architecture (3)
• Fonctionnement du client : le resolver
• permet de communiquer avec les serveurs DNS
• 2 modes d'interrogation
• récursif : le client envoie une requête à un serveur, ce
dernier devant interroger tous les autres serveurs
nécessaires pour renvoyer la réponse complète au client
(mode utilisé par les machines clientes en général)
• itératif : le client envoie une requête à un serveur, ce
dernier renvoyant la réponse si il la connaît, ou le nom
d'un autre serveur qu’ il suppose plus renseigné pour
résoudre cette question (mode utilisé par le resolver des
serveurs en général)

Architecture (4)
serveur
www.inria.fr ? . .
serveur
r fr → ns1.nic.fr, ns2.nic.fr, ...
e
s
o www.inria.fr ? fr
fr de
l serveur
inria.fr → dns.inria.fr, ...
v
e
r www.inria.fr ? inria.fr
serveur nic.fr inria.fr
www.inria.fr → 128.93.3.29
128.93.3.29
resolver
Int. Récursive
www.inria.fr ? Machine A Int. itérative

Architecture (5)
• Serveurs
• types de serveurs
• serveur cache
• serveur
• « faisant suivre » (forwarder)
• « esclave » (slave - forwarder-only)
• serveur ayant autorité sur une (plusieurs)
zone(s)
• primaire (source des données)
• secondaire (miroir des données)

Architecture (6)
• Serveur cache
• éviter la surcharge inutile du réseau
• supprimer les délais du réseau
• amoindrir la charge des autres serveurs
 tout serveur possède en général au
minimum un cache

Architecture (7)
• Serveur cache
• configuration minimale
• base de données nécessaire
• adresses des serveurs de la racine
• reverse du loopback 1.0.0.127.in-addr.arpa
• les données du cache possèdent une durée de vie limitée
Time To Live - ttl) afin de permettre son
rafraîchissement et la prise en compte des modifications
• il s'enrichit au fur et à mesure par les données récoltées
pour résoudre les requêtes des clients
 une requête déjà demandée est résolue à partir du
cache du serveur

Architecture (8)
serveur
.
serveur
c r
a e
c s
h o fr
e l serveur
v
www.inria.fr
128.93.3.29
e
→
r inria.fr
serveur
128.93.3.29
resolver
Int. Récursive
www.inria.fr ? Machine A Int. Itérative

Architecture (9)
serveur
r
c e
a s
c fr
o
h serveur
l
e
v
e
r chronos.inria.fr ? inria.fr
serveur
chronos.inria.fr → 128.93.45.201
128.93.45.201
resolver int. récursive
chronos.inria.fr ? int. itérative
Machine A

Architecture (10)
• Serveur « faisant suivre » / esclave
• ces types de serveurs possèdent une liste de serveurs à
interroger (le serveur fait suivre la requête reçue vers
d'autres serveurs par une requête elle-même récursive)
• « faisant suivre »
• vérifie si la réponse n'est pas dans son cache
• sinon fait suivre à un des serveurs la requête
• en cas d'échec tente de résoudre lui même la demande
 enrichissement rapide d'un cache partagé (au sein d 'un
organisme pour ne pas surcharger la liaison vers l 'extérieur)

Architecture (11)
• Serveur « faisant suivre » / esclave

• esclave
• vérifie si la réponse n 'est pas dans son cache
• sinon fait suivre à un des serveurs la requête
• en cas d 'échec avec tous les serveurs, il renvoie un code
d'erreur
 enrichissement rapide d'un cache partagé pour un
serveur n'ayant pas d'accès direct à tout l'Internet

Architecture (12)
• Serveur ayant autorité sur une (plusieurs) zone(s)
• serveur primaire
• le serveur primaire d'une zone est la source des informations
relatives à cette zone (il possède la base de données maître)
• il contient les informations à partir d'un fichier de données où
l'on effectue les mises à jour.
• il a l'origine de l'autorité (Start Of Authority - SOA) sur cette
zone

Architecture (13)
• Serveur ayant autorité sur une (plusieurs) zone

(s)
• serveur secondaire
• c 'est un miroir sauvegardé sur disque de la base de
données maître
• fonction de sauvegarde
• de répartition de charge et d'accessibilité
• le serveur secondaire d'une zone obtient les informations
relatives à celle-ci automatiquement depuis un serveur
primaire ou un autre secondaire
• il a également autorité sur cette zone

Architecture (14)
serveur
www.inria.fr ? . .
auth serveur
r  fr : ns1.nic.fr
disque c e
a s
www.inria.fr ? fr
o fr
c serveur
de
l
 inria.fr : dns.inria.fr
h v
e
e
r www.inria.fr ? nic.fr
serveur nic.fr inria.fr
128.93.3.29
128.93.3.29
resolver int. récursive
www.inria.fr ? int. itérative
host A

Architecture (15)
• Rafraîchissement des données entres serveurs

autoritaires
• système classique
• un serveur secondaire d'une zone interroge à intervalles
réguliers le serveur primaire de cette zone pour voir si une
modification a eu lieu. La fréquence est indiquée par la valeur
refresh défini dans le SOA
• ce type de mise à jour peut se faire entre un primaire et un
secondaire ou entre secondaires

Architecture (16)
• Rafraîchissement des données entre serveurs
autoritaires
• la version d 'une zone est identifiée par son numéro de série
(serial) ; à chaque modification celui-ci doit être
augmenté
• le transfert de zone
• le serveur secondaire transfère d'abord le SOA de la zone et vérifie
si le numéro de série a augmenté
• si c'est le cas toute la zone est transférée (transfert total - AXFR) ou
seules les nouvelles modifications entre les 2 versions sont
transférées (transfert incrémental - IXFR - RFC 1995)

Architecture (17)
• Rafraîchissement des données entre serveurs

autoritaires
• reprise en cas d 'échec
• en cas d 'échec de cette interrogation, le secondaire
recommence toutes les retry secondes jusqu'à atteindre
le temps d'expiration (expire), ces valeurs étant fixés
également dans le SOA

Architecture (18)
• Rafraîchissement des données entres serveurs ayant
autorités sur une zone
• DNS Change Notification (RFC 1996)
• après la prise en compte de modifications de la part du serveur
primaire, ce dernier notifie les serveurs secondaires qu'une
nouvelle version de la zone a été générée
• ce système de mise à jour ne peut se faire qu'entre un primaire et
un secondaire
• accélère le rafraîchissement des données par rapport au système
classique

Architecture (19)
• Remarques
• un serveur peut être à la fois serveur cache et
autoritaire pour des zones : le cache possède alors des
informations locales et non locales
• un serveur peut être à la fois primaire pour des zones
et secondaire pour d'autres zones

Architecture (20)
• Remarques
• mode de fonctionnement d'un serveur
• récursif
• le serveur résout les requêtes récursives des clients et
garde les informations obtenues dans son cache
•  le cache stocke des informations pour lesquelles le
serveur n 'a pas autorité
• serveurs cache de campus par exemple

Architecture (21)
• Remarques
• mode de fonctionnement d'un serveur
• itératif
• il répond toujours en fonction des données qu'il possède localement
•  ne construit pas de cache pour des données non locales .
•  une machine cliente (d'utilisateur final) ne doit jamais pointer
sur un serveur de ce type comme serveur par défaut .
• mode permettant de limiter la charge d'un serveur (il ne résout pas toute la
requête)
 serveurs de la racine, serveurs ayant autorité pour un grand nombre de
zones

Architecture (22)
• A
• NSI USA
• B • H
• ISI USC USA • Army Resarch Lab USA
• C • I
• PSI USA • NORDU SUEDE
• D • J
• UNIV. MARYLAND • NSI USA
• E • K
• NASA USA • RIPE NCC LINX UK
• F • L
• ISC USA • ISI USA
• G • M
• DOD NIC USA • Wide Project JAPON
http://www.root-servers.org/

A C D G H J
I
M
K
E
F

S
ep
-
0
500
1000
1500
2000
2500
94
N
ov
-9
4
Ja
n-
9
M 5
© AFNIC (06/10/03)
ar
-9
M 5
ay
-9
5
Ju
l-9
S 5
ep
-9
N 5
ov
-9
5
Ja
n-
9
M 6
ar
-9
M 6
ay
-9
6
Ju
l-9
S 6
ep
-9
N 6
ov
-9
6
a.root-servers.net
Ja
n-
9
M 7
ar
-9
M 7
ay
-9
7
Ju
l-9
S 7
ep
DNS - 54
-9
7
j.root-servers.net
N
ov
-9
7
Ja
n-
9
M 8
ar
-9
M 8
ay
-9
8
Ju
j.gtld-servers.net
l-9
S 8
ep
-9
N 8
ov
-9
8
Ja
n-
9
M 9
ar
-9
M 9
ay
-9
9
Ju
l-9
S 9
ep
Ari Balogh
-9
N 9
ov
-9
9
Formation 2003
abalogh@netsol.com
Base de données (1)
• Fichier de configuration du serveur

• Fichier des serveurs de la racine
• Un fichier par zone décrivant son contenu
• au moins le fichier du reverse loopback 1.0.0.127.in-
addr.arpa

• Fichier de configuration
• localisation des données
fichier serveurs de la racine
fichiers de zone
• déclaration de l'autorité sur des zones
primaire / secondaire
• mode de fonctionnement général
• récursif/itératif
• « faisant suivre », esclave, ....

• Fichier des serveurs de la racine

• permet de démarrer la résolution d 'une requête si le
serveur n'a aucune information
• contient la liste des serveurs de nom et leur adresse IP
• primaire : A.ROOT-SERVERS.NET.
• une quinzaine de serveurs secondaires à travers le
monde
• peut être généré de la façon suivante :
dig @a.root-servers.net . ns > root.cache

• Fichier de zone
• contient les données propres à chaque zone
• consiste en une liste de Resource Records (RR)
• le premier RR doit être le SOA (Start of Authorithy) qui
décrit l'autorité technique de la zone
• directives spéciales

• Directives spéciales
• $ORIGIN
spécifie le nom de domaine à ajouter à des enregistrements
non pleinement qualifiés (non suffixés par un point)
syntaxe : $ORIGIN <domaine> [<commentaire>]

• $ORIGIN - exemple
$ORIGIN exemple.
$ORIGIN mon-domaine
www IN CNAME serveur
 équivalent à :
www. mon-domaine.exemple. IN CNAME serveur. mon-domaine.exemple.
Par défaut $ORIGIN est positionné au nom du domaine

que le fichier de zone décrit

• $INCLUDE
permet d'inclure un fichier dans le fichier de zone
syntaxe : $INCLUDE <fichier> [<origin>] [<comment>]
Si <origin> n'est pas spécifié la valeur courante est utilisée

• $TTL (RFC 2308 - bind 8.2)
spécifie le Time To Live par défaut à appliquer aux
enregistrements qui n'ont pas ce paramètre spécifié
dans leur déclaration
syntaxe : $TTL <valeur> [<commentaire>]
valeur [0 - 2147483647]

• $TTL
en règle générale lors de modification d ’ une

ressource importante il faut abaisser cette valeur (à
quelques minutes) ttl+refresh (spécifié dans le SOA)
AVANT la modification pour que celle-ci se
propage rapidement

t1 t2
temps emis par le
primaire
primaire
ttl
secondaire
refresh ttl
Information dans les serveurs caches
• t1 : date de l'abaissement du ttl de la ressouce

• t2 : date de la modification de la ressource elle-
même
• Structure d 'un RR - RFC 1034

< nom | @ > [<ttl>] [<classe>] <type> <données> [<commentaire>]
<nom> : nom de l 'enregistrement auquel vont s'appliquer les

informations
@ : utilise la valeur courante de $ORIGIN comme nom
<ttl> : durée de vie, en secondes, de l'enregistrement dans les caches
<classe> : groupe d'appartenance - IN pour Internet
<type> : type de l'enregistrement
<données> : données associées au type

• Principaux RR - SOA (Start Of Autority)

caractéristiques techniques de la zone :
zone IN SOA primaire. email. (

serial
refresh
retry
expire
ttl )

• Principaux RR - SOA
email : contact technique de la zone

remplacer le @ par le premier point non protégé (\)
l'email doit être suivi d 'un point
francis\.dupont.inria.fr.
pour
francis.dupont@inria.fr

numéro de série : spécifie la version des données de la zone

incrémenter ce numéro à chaque modification (entier sur 32 bits)
format conseillé : YYYYMMDDxx

1997052702

refresh : intervalle, en secondes, entre 2 vérifications du numéro de
série par les secondaires (24H - 86400s ; à ajuster si la zone est
souvent modifiée)
retry : intervalle en seconde entre 2 vérifications du numéro de série
par les secondaires si la 1ere vérification a échoué (6H - 21400s ; à
ajuster en fonction de sa connectivité)
expire : durée d 'expiration de la zone sur un secondaire (41 jours
-3600000s )
retry<<refresh<<expire

ttl (time to live) - RFC 2308 - Negative caching
spécifie le TTL pour le « negative caching », soit le temps que

doit rester dans les caches une réponse négative suite à une
question sur ce domaine (valeur recommandée de 1 à 3 heure).
Il existe 2 types de réponses négatives :
• NXDOMAIN : aucun enregistrements ayant le nom demandé dans la
classe (IN) n'existe dans cette zone
• NODATA : aucune donnée pour le triplet (nom, type, classe) demandé
n'existe ; il existe d'autre enregistrements possédant ce nom, mais de
type différent

• Principaux RR - NS (Name Server)
indique un serveur de nom pour le nom spécifié (ce nom
devient une zone dont la délégation est donnée au serveur en
partie droite)
zone IN NS serveur-nom1.domaine.
IN NS serveur-nom2.domaine.
Il faut spécifier les serveurs de noms de la zone que l'on décrit

(associée au SOA)

$ORIGIN nic.fr.
$TTL 86400
@ IN SOA ns1.nic.fr.
hostmaster.nic.fr. (
1997052704 ;serial
86400 ;refresh
21600 ;retry
3600000 ;expire
3600 ; negative caching ttl )
IN NS ns1.nic.fr.
IN NS ns2.nic.fr.
www IN CNAME ns2.nic.fr.
ftp 21600 IN A 192.34.4.45

• Principaux RR - A (Adresse IPv4)
indique l 'adresse IP associée à un nom
machine.domaine. IN A 193.10.20.30
AAAA : Adresse IPv6

• Principaux RR - PTR (Pointeur)
indique le nom associé à un numéro IP dans l 'arborescence

in-addr.arpa (ip6.arpa)
10.20.30.192.in-addr.arpa. IN PTR machine.domaine.

• Principaux RR - CNAME (Canonical Name)
indique que le nom est un alias vers un autre nom (le nom canonique)
alias IN CNAME nom.canonique.
Nota
• un nom en partie droite d'un enregistrement (<données>) ne doit pas
pointer vers un alias
• quand un nom a déjà un CNAME il est interdit de faire figurer d'autres
enregistrements pour ce nom

• Principaux RR - CNAME (Canonical Name) - faux

zone. IN MX 10 alias.zone.
alias.zone. IN CNAME relais.zone.
zone. IN NS alias.zone.
alias.zone. IN CNAME serveur.zone.
zone. IN SOA xxxx. yyy. ( zzzz ... )

zone. IN CNAME www.zone.

• Principaux RR - CNAME (Canonical Name) - correct

zone. IN MX 10 relais.zone.
relais.zone. IN A 193.1.2.3
alias2.zone. IN CNAME alias1.zone.

alias1.zone. IN CNAME canonical.zone.
zone. IN SOA xxxx. yyy. ( zzzz ... )

zone. IN A 193.2.3.4
Et l'enregistrement PTR correspondant dans les reverses

Fichier de zone pour nic.fr
$ORIGIN nic.fr.
$TTL 86400
@ IN SOA ns1.nic.fr. hostmaster.nic.fr.
(
1997052704 ;serial
86400 ;refresh
21600 ;retry
3600000 ;expire
3600 ;negative ttl
)
IN NS ns1.nic.fr.
IN NS ns2.nic.fr.
; Suite
ns1 IN A 193.10.20.30
ns2 IN A 192.5.6.7
machine IN A 193.10.20.31
www IN CNAME machine
localhost IN A 127.0.0.1

• Fichier du reverse 0.0.127.in-addr.arpa

• personne n'a la responsabilité de ce reverse pour le
numéro 127.0.0.1dans la hiérarchie in-addr.arpa.
• le système l'utilise pour la résolution de requête vers lui-
même
 si on ne le configure pas sur le serveur cette requête
peut échouer :
• root serveur contacté mal configuré  code erreur
• renvoie autre chose que localhost

Fichier de zone pour 0.0.127.in-addr.arpa.
0.0.127.in-addr.arpa IN SOA ns1.nic.fr.
hostmaster.nic.fr.
(
1997052704 ;serial
86400 ;refresh
21600 ;retry
3600000 ;expire
3600 ;negative ttl
)
IN NS ns1.nic.fr.
1.0.0.127.in-addr.arpa. IN PTR localhost.nic.fr.

DNS et SMTP (1)
• Principaux RR - MX (Mail eXchanger)
email à quelqu-un@nom
On cherche dans le DNS un MX indiquant la machine sur laquelle il faut
envoyer le courrier pour nom.
Un paramètre précise le poids relatif de l 'enregistrement MX : si
plusieurs MX existent, le courrier est envoyé en 1er à la machine ayant le
poids le plus bas, puis dans l 'ordre croissant des poids en cas d'échec
nom IN MX 10 nom.relais1.
IN MX 20 nom.relais2.
IN MX 30 nom.relais3.

DNS et SMTP (2)

Envoi d 'un message à nom - RFC 974
- (1) tri les MX par ordre croissant et contacte les machines dans
cet ordre ; si une connexion est établie  transfert ; sinon mail
mis en file d'attente
- (2) transfert sur nom.relais1 : le mail est traité localement
- (3) transfert sur l'une des autres machines: on trie de nouveau
les MX en supprimant les entrées de préférence supérieure on
égale à celle associée à cette machine ; si la liste est vide 
erreur de configuration ; sinon on tente de contacter les
machines de la même manière qu'en (1)

DNS et SMTP (3)
• wilcard MX
nic.fr. IN MX 10 relais.nic.fr.
*.nic.fr. IN MX 10 relais.nic.fr.
 associe le MX à tout nom inconnu dans le domaine, il n'est
utilisé qu'en l'absence de tout autre RR associé à un nom.
Exemple :
nom.nic.fr. IN A IP
 pas de MX hérité des wilcards pour nom

 associer systématiquement un MX à chaque fois que l 'on définit
un A RR et éviter les wilcards

DNS et SMTP (4)

Si il n 'y a pas de MX associé à nom :
• SMTP utilise l 'adresse IP associé à ce nom (A RR)
nom IN A IP
• si il n 'y a pas de RR, SMTP utilise les enregistrement
wildcard MX
• si il n 'y a pas de wildcard MX => erreur

Délégation et sous domaine (1)
• faire figurer la délégation dans la zone parente => il
s'agit d'enregistrement NS
• zone parente
$TTL 86400
nic.fr. IN SOA ns1.nic.fr. hostmaster.nic.fr.
(
1997052704 ;serial
86400 ;refresh
21600 ;retry
3600000 ;expire
3600 ;negative ttl
)
IN NS ns1.nic.fr.
IN NS ns2.nic.fr.
ns1.nic.fr. IN A 193.10.20.30
ns2.nic.fr. IN A 192.5.6.7
fille.nic.fr. IN NS ns1.inria.fr.
IN NS ns.urec.fr.
• zone déléguée
$ORIGIN fille.nic.fr.
$TTL 86400
@ IN SOA ns1.inria.fr.
hostmaster.inria.fr.
(
1997052704 ;serial
86400 ;refresh
21600 ;retry
3600000 ;expire
3600 ;negative ttl
)
IN NS ns1.inria.fr.
IN NS ns.urec.fr.
• Utilisation de la glue
• permet d'établir des liens nom  IP avec les sous zones
pour la cohérence de l'arbre DNS
• elle n'est nécessaire que dans le cas où les serveurs de la
zone fille sont dans la même arborescence que le domaine
fille.domaine.
• en cas de changement d 'adresse IP il faut modifier la zone
fille et la zone parente

• dans le fichier de zone nic.fr
fille.nic.fr. IN NS ns1.fille.nic.fr.
IN NS ns.urec.fr.
ns1.fille.nic.fr. IN A 192.5.6.7
• dans le fichier de zone fille.nic.fr

fille.nic.fr. IN SOA ns1.inria.fr. hostmaster.inria.fr.
(
1997052704 ;serial
86400 ;refresh
21600 ;retry
3600000 ;expire
3600 ;negative ttl
)
IN NS ns1.fille.nic.fr.
IN NS ns.urec.fr.
ns1.fille.nic.fr. IN A 192.5.6.7

BIND (1)
• Historique
• JEEVES : première implémentation du DNS par Paul
Mockapetris (1984)
• BIND (The Berkeley Internet Name Domain)
implémentation suivante sur système 4.3BSD UNIX par
Kevin Dunlap
• Aujourd'hui
• BIND maintenu par Paul Vixie avec l 'Internet Software
Consortium

BIND (2)
• Deux parties
• la partie serveur de noms : implémentée par la
commande named (ou in.named) et named-xfer (ou
in.named-xfer) pour les transferts de zone
• la partie client : bibliothèque C (libresolv.a ou
libresolv.so.x) avec laquelle sont liées toutes les
applications utilisant le DNS. Cette bibliothèque
contient notamment une version de getaddrinfo
(3) et getnameinfo(3) qui utilisent le DNS.

BIND (3)
• Développé par l'Internet Software Consortium
• http://www.isc.org/
• http://www.isc.org/bind.html
• Sources disponibles
• ftp://ftp.isc.org/isc/src/cur (version courante)
• ftp://ftp.isc.org/isc/src/testing (version en développement)
• ftp://ftp.nic.fr/pub/programmes/DNS/
• News
• comp.protocols.dns.bind
• comp.protocols.dns.ops
• comp.protocols.dns.std

BIND (4)
• Versions
• 4.9.8 ( ne doit etre utilise que si on ne peut pas utiliser la v8 ou v9 )
• dernière version de la série 4.x
• fichier de configuration named.boot
• 8.2.4
• implémentation des derniers RFCs
• Dynamic Updates - RFC 2136
• Change Notification par défaut - RFC 1996
• IXFR - RFC 1995 (expérimental)
• Secure DNS - RFC 2535 + dnskeygen
• $TTL - RFC 2308
• nouveau format du fichier de configuration named.conf
• transfert de zone plus performant (format many-answers)
• pas de libresolv partagée ; la librairie statique s'appelle libbind.a

BIND (5)
• 9.1.3
• Support de DNSSEC,TSIG
• Support de IP v6
• Enregistrements Spécifiques
• Requêtes
• Extension du protocole DNS IXFR,...
• Système de vue pour les zones
• Support des systèmes multiprocesseur

BIND - serveur cache (6)
• fichier de config named.conf
// répertoire des données
options {
directory "/usr/local/bind/data";
};
// cache des serveurs de la racine

zone "." in {
type hint;
file "root.cache";
};
// zone primaire du reverse loopback

zone "0.0.127.in-addr.arpa" {
type master;
file "db.localrev";
};

BIND - serveur cache esclave(7)
options {
// on fait tout suivre
forwarders {192.1.2.3 ; 193.1.2.3 };
options forward-only ;
};
zone "." {
type hint ;
file "root.cache";
};
type master;
file "db.localrev" ;
};

BIND - serveur autoritaire et cache (8)
options {
};
zone "." {
type hint;
file "root.cache";
};
// zone primaire
type master;
file "db.localrev";
};

BIND - serveur autoritaire et cache (9)
• fichier de config named.conf - suite
zone "nic.fr" { // zone primaire
type master;
file "db.nic.fr";
};
zone "30.20.192.in-addr.arpa" { // zone primaire
type master;
file "db.nic-rev";
};
zone "inria.fr" { // zone secondaire
type slave;
file "db.inria.fr";
masters {192.1.1.1 ; };
};

BIND - serveur autoritaire (10)
options {
recursion no; // non récursif
};
zone "." {
type hint;
file "root.cache";
};
type master;
file "db.localrev";
};

BIND - serveur autoritaire (11)
• fichier de config named.conf - suite

zone "nic.fr" {
type master;
file "db.nic.fr";
};
type master;
file "db.nic-rev";
};

BIND (12) - Migration V4 →V8
• générer named.conf à partir de

named.boot
• outil de conversion
bin/named/named-bootconf.pl
• exemple de fichier named.conf
bin/named/named.conf

BIND (13)
• Relancer le serveur
• kill -HUP pid
• Debugger
• Dump du contenu du cache  kill -INT pid
• le résultat est dans un fichier named_dump.db
• Passage en mode debug avec trace dans le fichier
named.run  kill -USR1 pid
• chaque nouvelle utilisation de cette commande augmente
le niveau de début
• arrêt de ce mode  kill -USR2 pid

Outils
• Dans le package BIND
• nslookup
• dig (domain information groper)
• host
• h2n (convertit un fichier /etc/hosts en fichiers de zone)
• checksoa
• Ripe
• ftp://ftp.ripe.net/tools/dns/host.tar.Z
• A. Romão : Tools for DNS debugging
• ftp://ftp.ripe.net/rfc/rfc1713.txt
• NIC France
• http://www.nic.fr/zonecheck/

Pièges à éviter (1)
• La durée refresh est d'au moins une heure,

• La durée retry est d'au moins une heure,
• la durée expire est d'au moins une semaine et est très
supérieure à la durée refresh,
• la durée TTL est d'au moins une heure pour les
enregistrements SOA et NS pour une zone stable
• la durée du negative TTL doit être inférieure à 7
jours
• Le numéro de série de la zone est cohérent sur
chacun des Name Server .

Pièges à éviter (2)
• Problème avec les Name Server

• NS not reachable, NS not set up
• Domaine pas complètement nommé
(oubli du point final)
$ORIGIN 0.0.193.in-addr.arpa.
1 PTR ns1.nic.fr
est résolue comme :
1 PTR ns1.nic.fr.0.0.193.in-addr.arpa
• La zone n'est pas installée sur les Name Server annoncés dans
la zone parente.

ZoneCheck
Outil de validation
pour une zone DNS

Zone Check (1)
• Outil développé par l'AFNIC

• L'AFNIC l'utilise pour valider toute modification dans ces
zones .
• Utilisable via l'URL suivante :
• http://www.nic.fr/zonecheck
• Les sources sont disponibles à l'URL suivante :

• ftp://ftp.nic.fr/pub/programmes/DNS/ZoneCheck/

Zone Check (2)
• Pour vérifie la validité de l'installation d’ un nom de

domaine.
• renseigner le nom de la zone ou directement le n° du ticket attribué au nom

de domaine.
• renseigner la méthode pour obtenir les infos concernant ce nom de

domaine.
• Formulaire libre : remplir à la main les différents noms des serveurs de noms et
les adresses IP si nécessaire.
• DNS pour zone existante (dns) : récupère automatiquement les noms des
serveurs de noms pour la zone.

Zone Check (3)
• Le lancement de la vérification, plusieurs choix :
• Inclure les messages d'aide,
• Affichage des messages supplémentaires lors d'erreurs.
• Vérifier la base RIPE,
• Test de l'existence des enregistrements inetnum et route dans la base
RIPE.
• Vérifier l'envoi de courrier électronique au zone-contact,
• Vérifie l'existence des adresses électroniques des responsables de la
zone.
• Vérifier le contenu de la zone,
• Vérifie la validité de la zone sur les Name Server .
• avec des icônes,
• le nom du serveur whois.
• Permet de changer le nom du serveur whois, par défaut est whois-
whois.nic.fr

Zone Check (4)
• Vérification de la connexion TCP :

• ping sur le port 53 du serveur de nom.
• Vérification de la zone sur le serveur :
• Vérification de la liste de NS présente sur ce serveur
• Vérification de la liste des serveurs de noms de la racine
connus de ce serveur :
• Vérification de l'enregistrement SOA de in-addr.arpa :
• Vérification de l'enregistrement SOA de fr

Zone Check (5)
• Vérification des mappings inverses du n° IP de chaque Name

Server :
• Vérification des mappings inverses de 127.0.0.1 de chaque
Name Server :

Zone Check (6)
• Vérification de l'enregistrement inetnum dans la base RIPE

• Vérification de l'enregistrement route dans la base RIPE
• Vérification de l'adresse IP des autres serveurs de la zone

Zone Check (7)
• Vérification de l'enregistrement SOA.

• vérification des RR :
• SERIAL
• PRIMARY
• CONTACT
• REFRESH
• RETRY
• EXPIRE
• TTL

Zone Check (8)
• Vérification des MX Record pour le nom de

domaine.
• Vérification des adresses de courrier
électronique
• Si le relais de messagerie SMTP implémente la
commande VRFY conformément aux RFC's
( 1123, .. ) alors ZonecCheck utilise la commande
• Sinon fait un debut de delivrance de message .

Copyright (c) 2003 Mas, Souissi (AFNIC)
Permission est accordée de copier, distribuer et/ou modifier ce
document selon les termes de la Licence de Documentation Libre GNU
(GNU Free Documentation License), version 1.1 ou toute version
ulterieure publiée par la Free Software Foundation. Une copie de
la présente Licence est incluse dans la section intitulée
Licence de Documentation Libre GNU.
http://www.gnu.org/licenses/licenses.html#FDL

Domain Name System: Erwan - Mas@nic - FR Mohsen - Souissi@

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Domain Name System: Erwan - Mas@nic - FR Mohsen - Souissi@

Enviado por

Direitos autorais:

Formatos disponíveis

Domain Name System

© AFNIC (06/10/03) DNS - 1 Formation 2003

© AFNIC (06/10/03) DNS - 2 Formation 2003

• Un espace de communication, sans frontière, où

• Les services les plus courants :

© AFNIC (06/10/03) DNS - 3 Formation 2003

• L'ordinateur qui est connecté à Internet est

• Pour communiquer un programme doit connaître

© AFNIC (06/10/03) DNS - 4 Formation 2003

• Les adresses IP ce n'est pas facile a mémoriser .

• On a préféré nommer les machines .

• On a construit une base de donnée, pour associer un nom et

© AFNIC (06/10/03) DNS - 5 Formation 2003

© AFNIC (06/10/03) DNS - 6 Formation 2003

© AFNIC (06/10/03) DNS - 7 Formation 2003

© AFNIC (06/10/03) DNS - 8 Formation 2003

© AFNIC (06/10/03) DNS - 9 Formation 2003

© AFNIC (06/10/03) DNS - 10 Formation 2003

• Jusqu'en 1984 : fichier hosts.txt  /etc/hosts

© AFNIC (06/10/03) DNS - 11 Formation 2003

© AFNIC (06/10/03) DNS - 12 Formation 2003

© AFNIC (06/10/03) DNS - 13 Formation 2003

© AFNIC (06/10/03) DNS - 14 Formation 2003

arpa com net fr

in-addr apnic ripe Nic

193 192 whois whois www

133 193.1.2.133 → 133.2.1.193.in-addr.arpa. → whois.ripe.net

© AFNIC (06/10/03) DNS - 15 Formation 2003

• Parcours de l'arbre et nom de domaine

2éme niveau 1er niveau

© AFNIC (06/10/03) DNS - 16 Formation 2003

arpa com tn net fr

in-addr ffti apnic ripe nic

© AFNIC (06/10/03) DNS - 17 Formation 2003

• Délégation d'un noeud père vers un noeud fils

© AFNIC (06/10/03) DNS - 18 Formation 2003

• Dénomination des domaines

© AFNIC (06/10/03) DNS - 19 Formation 2003

© AFNIC (06/10/03) DNS - 20 Formation 2003

• Notion de domaine et de zone

© AFNIC (06/10/03) DNS - 21 Formation 2003

© AFNIC (06/10/03) DNS - 22 Formation 2003

• Résolution nom  numéro IP

2éme niveau 1er niveau

© AFNIC (06/10/03) DNS - 23 Formation 2003

un noeud contient à la fois des noms de machines et des

© AFNIC (06/10/03) DNS - 24 Formation 2003

© AFNIC (06/10/03) DNS - 25 Formation 2003

• Parcours de l'arbre et résolution inverse

pour le numéro IP : 193.1.2.133

• la descente dans l'arbre est représentée de la droite vers la gauche

© AFNIC (06/10/03) DNS - 26 Formation 2003

arpa com tn net fr

in-addr ffti ripe nic

© AFNIC (06/10/03) DNS - 27 Formation 2003

© AFNIC (06/10/03) DNS - 28 Formation 2003

• Racine : 13 bases de données (serveurs de nom) répartis

© AFNIC (06/10/03) DNS - 29 Formation 2003

© AFNIC (06/10/03) DNS - 30 Formation 2003

© AFNIC (06/10/03) DNS - 31 Formation 2003

© AFNIC (06/10/03) DNS - 32 Formation 2003

© AFNIC (06/10/03) DNS - 33 Formation 2003

© AFNIC (06/10/03) DNS - 34 Formation 2003