UNIVERSITÉ SIDI MED BEN ABDELLAH

FACULTÉ DES SCIENCES ET TECHNIQUES FES ADMINISTRATION DES RESEAUX

DÉPARTEMENT D’INFORMATIQUE

DNS
Domain Name System

1
Pr: Khalid ZENKOUAR
 INTRODUCTION

• Problématique
– Sur un réseau comme Internet une machine (ou service) peur être
identifiée par:
• Un nom d’hôte,
• Une adresse logique (IP).
– En générale, les utilisateurs ne connaissent que le nom des
machines ou des services avec lesquels ils veulent communiquer.
• Exemple pour serveur web: www.fstfes.ma
– Les machines n’établissent leur communication qu’a l’aide de
leurs adresses IP,
– Comment résoudre les noms de machines
en adresses IP ?
2
Pr: Khalid ZENKOUAR
 INTRODUCTION
gestion des noms sur arpanet
 L’ARPANET (Advanced Research Program Agency
Network) des années 80 est constitué d’une centaines
d'ordinateurs reliés en réseaux.

 Un unique fichier hosts.txt rassemble les

correspondances entre nom d'hôte et adresse IP.

 Le fichier est stocké sur le SRI-NIC (Stanford

Research Institutes Network Information Center) .

 Après chaque modification, des copies sont transférées

par ftp vers les ordinateurs du réseau.

3
Pr: Khalid ZENKOUAR
 INTRODUCTION
hosts.txt
/etc/hosts
127.0.0.1 localhost
194.214.66.29 routeur-fst-fes
192.168.169.2 www.fstfes.ma

Windows UNIX

4
Pr: Khalid ZENKOUAR
 INTRODUCTION
Les inconvénients
 La taille du fichier hosts.txt augmente avec le nombre
d’hôtes,
 Temps de diffusion des infos (par ftp ),
 Système centralisé (chaque poste a sa propre base
données),
 La fréquence des mises-à-jours des tables devient
proportionnelle au nombre de machines,
 La consommation de la bande passante,
 Correspondance statique,
 Ne contient que des infos réduites,
 Noms enregistrés sous le domaine arpa
 collision rapide de noms
5
Pr: Khalid ZENKOUAR
 INTRODUCTION
J. Postel P. Mockapetris

1983-84 Paul Mockapetris et Jon Postel

proposent et développent une solution à base
de BD distribuée Domain Name System
6
Pr: Khalid ZENKOUAR
 Domain Name system
• Le système DNS est fondé sur un système de base de
données répartie,

• Chaque serveur est donc responsable des adresses IP

appartenant à un domaine d’adressage délimité,

• Lorsqu’un serveur n’est pas en mesure de résoudre une

adresse, il existe des procédures définissant la manière
d’accéder à un serveur capable de traiter la requête,

• Le système DNS a donc été construit sur un concept

d’espaces de dénomination,

• Ces espaces de dénomination s’appuient sur la structure

hiérarchique.
7
Pr: Khalid ZENKOUAR
 Domain Name System
• Basé sur le modèle client / serveur

• Les requêtes et les réponses sont envoyées dans

des paquets
– UDP, port 53
– ou sur TCP, port 53 pour les requêtes très grandes ,
exemple : transfert zone à partir du maître vers
l’esclave

• Les messages (requête ou réponse) du protocole

DNS sont définis dans le RFC1035.

8
Pr: Khalid ZENKOUAR
 L’espace Nom de domaine
• Chaque unité de donnée dans la base DNS est indexée (etiquettés) par
un nom,
• Les noms constituent un chemin dans un arbre inversé appelé : l’espace
Nom de domaine,
• Organisation similaire à un système de gestion de fichiers.

• Chaque noeud est identifié par un nom

• Racine appelée root, identifiée par «.» 9
Pr: Khalid ZENKOUAR
 L’espace Nom de domaine

• Organisation arborescente

10
Pr: Khalid ZENKOUAR
 L’espace Nom de domaine
• La racine: est le nœud unique situé au sommet de l’arbre DNS
représenté par un point appelée root domain..
• Physiquement la racine correspond à 13 serveurs racine du DNS
d'Internet géré sous l'autorité de l'ICANN(Internet Corporation for
Assigned Names and Numbers).
• http://www.root-servers.org/

11
Pr: Khalid ZENKOUAR
 L’espace Nom de domaine
• Organisation arborescente:
• Top Level Domains – TLD: Sous la racine, on trouve les domaines
de 1er niveau (organisation et pays) étiquetés com, edu, gov, int,
mil, org, net et des codes d'états ou de pays normalisés sur 2
lettres (ma pour maroc, fr pour la France).
– TLDs spéciaux
• ARPA. : gTLD "préhistorique" réutilisé pour des mécanismes spécifiques tels que le
reverse DNS ou ENUM.
• EXAMPLE., TEST., INVALID. : TLDs conventionnels pour expérimentation et
documentation (RFC 2606).
• LOCALHOST. : TLD conventionnel (mais non officiel) pour "localhost=127.0.0.1" (RFC
1912).
• 2eme niveau: on trouve des domaines gérés par des
entreprises, institutions, organismes…
• NB:
– L’organisation qui a autorité sur un domaine peut créer un ou plusieurs
sous-domaines.
– DNS supporte jusqu’à 127 niveaux de domaines.
12
Pr: Khalid ZENKOUAR
 Les noms de domaine
Un nom de domaine est la séquence de labels (étiquettes) depuis le
noeud de l’arbre correspondant jusqu’à la racine (.).
.
ma

ac

fstfes

M1 Le nom FQDN de la machine: M1.fstfes.ac.ma.

www

Deux noeuds fils ne peuvent avoir le même nom ==> unicité d’un
nom de domaine au niveau mondial
13
Pr: Khalid ZENKOUAR
 Les noms de domaine
• Lecture des noms de domaine
– A l’inverse de l’adressage IP la partie la plus significative si situe à
gauche de la syntaxe :

m1.fstfes.ac.ma 212.217.61.5
vers le plus significatif vers le plus significatif

m1. fstfes. ca.ma

domaine maroc ma

domaine de l’organisation ac

sous-domaine fstfes

machine m1 du domaine fstfes.ac.ma

14
Pr: Khalid ZENKOUAR
 Les noms de domaine

• Règles de nommage:
• Le système DNS impose peu de règles de nommage :
• 63 caractères au maximum par label
• Majuscules et minuscules non significatives
• Doit commencer par une lettre
• La longueur totale pour un nom de domaine étant est limitée à 255
caractères.

• Nom Relatif: L'absence de point final dans un nom s'interprète

comme un nom relatif à un domaine courant : exp: fstfes.ac.ma

• Nom Absolu(FQDN): Un nom complet avec "." final s'appelle un

FQDN (Fully Qualified Domain Name). Exp: serveur1.fstfes.ac.ma.

15
Pr: Khalid ZENKOUAR
 Les noms de domaine

FQDN(Fully qualified Domain Name)

Exemples : « . » Racine
FQDN
ma
serveur1.ca.ma.
ca
Nom Suffixe DNS
d'hôte
fstfes
FQDN

serveur1.fstfes.ca.ma. serveur1 = 192.168.0.66

Nom Suffixe DNS serveur1 = 192.168.0.67

d'hôte

16
Pr: Khalid ZENKOUAR
 Le domaine
Un domaine est un sous-arbre de l’espace nom de domaine

Domaine complet
ma
Domaine ma

fstfes Domaine fstfes

fstsettat

m1 noeud m1.fstfes.ma

Des noeuds peuvent avoir les

mêmes noms dans des domaines
différents :
M1.fstfes.ma et m1.fstsettat.ma
17
 zone
• Notion de zone
– Le domaine est un ensemble d'une sous arborescence
exemple : le domaine ma. rassemble toute la sous arborescence à partir
du noeud ma
– 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 nœud,

Nœud de type :machine

18
Pr: Khalid ZENKOUAR
 Les serveurs de noms
• Les logiciels qui gèrent les données de l’espace nom de domaine sont
appelés des serveurs de nom (name servers),
• Les serveurs de nom enregistrent les données propres à une partie de
l’espace nom de domaine dans une zone,
• Le serveur de nom à autorité administrative sur une zone,
• Un serveur de nom peut avoir autorité sur plusieurs zone,
• Une zone contient les informations d’un domaine sauf celles qui sont
déléguées.

ca ma

bc ab on qb domaine

zone
19
Pr: Khalid ZENKOUAR
 Terminologie: Domaine, zone, machine
• Domaine
• Un domaine est la partie de l’arborescence à partir du nœud portant son nom
• Exemple: domaine ma, : arborescence à partir du nœud ma
• On parle de sous domaine pour un domaine inclut dans un autre
– Exemple: fstfes.ma est un sous domaine du domaine ma

• noeud
• Un noeud contient à la fois des noms de machines et des sous-domaines,

• Zone
– C’est la base de donnée associée à un nœud
– Les bases de données associées aux zones contiennent:
• Noms/Adresses des serveurs de la zone
– Exemples:
– Racine: liste des serveurs des domaines de premiers niveaux
– ma: listes des adresses des serveurs des sous-domaines de ma
• Noms/Adresses des machines de ce domaine 20
Pr: Khalid ZENKOUAR
 Terminologie: Domaine, zone, machine
• La zone représente un nœud de l’arborescence alors que le domaine
représente une sous arborescence à partir d’un nœud.

• tout nœud non-terminal (c’est à dire tout nom ne désignant pas une
machine) est appelé zone (ma est une zone),

• Le domaine fstfes.ma comprend la zone fstfes.ma.

• La distinction machine/zone est importante puisque ces 2 objets n’ont pas

du tout les mêmes propriétés :
– Une zone est caractérisée par des serveurs de noms….,
– Une machine est caractérisée par son adresse IP et son nom.

• Une base de données par nœud de type zone,

• L'ensemble de ces bases de données constitue le système d'information

hiérarchique et distribué du DNS,

21
Pr: Khalid ZENKOUAR
 Délégation
• Délégation d'un nœud père vers un nœud fils,
• Un nœud peut être père de plusieurs nœuds fils,
• Le lien est effectué en précisant au niveau du nœud père
où trouver la base de donnée des nœuds fils
• But :
– Distribuer la gestion de chaque nœud à des entités différentes,
– Une base de données pour chaque nœud,
– L'ensemble de ces bases étant géré de façon décentralisé,
– Pour définir des domaines de responsabilités différentes.

22
Pr: Khalid ZENKOUAR
 Délégation
• Délégation
• Le système DNS est entièrement distribué au niveau
planétaire,
• A tout domaine est associé une responsabilité administrative,
• Une organisation responsable d’un domaine peut :
– Découper le domaine en sous-domaines ,
– Déléguer les sous-domaines à d’autres organisations :
• Qui deviennent à leur tour responsables du (des) sous-domaine(s)
qui leurs sont délégué(s),
• Peuvent, à leur tour, déléguer des sous-domaines des sous-
domaines qu’elles gèrent.

23
Pr: Khalid ZENKOUAR
Délégation

24
Pr: Khalid ZENKOUAR
 Administration
• Administration
– NIC (Network Information Center) L’organisme
qui gère les domaines du niveau TDL.
– Des organismes régionaux
• Groupements de pays
– APNIC : Asie - Pacifique
– ARIN : Amérique du nord
– LACNIC: Amérique latine et îles des caraîbes
– RIPE NCC: Europe - Moyen Orient
– AFRINIC : Afrique

25
Pr: Khalid ZENKOUAR
 Administration
• Administration

26
Pr: Khalid ZENKOUAR
Fonctionnement
du DNS
27
Pr: Khalid ZENKOUAR
 Fonctionnement du DNS
• Le service DNS est formé de trois composants :

1. Le résolveur,
2. Le serveur DNS,
3. L’espace de dénomination du domaine.

28
Pr: Khalid ZENKOUAR
 Fonctionnement du DNS
• 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 de noms
– chaque serveur gère sa propre base de données
– optimisation par des systèmes de cache et de réplication

29
Pr: Khalid ZENKOUAR
 Fonctionnement du DNS

 Couche de transport
 service s'exécutant sur le port 53

 Utilise les deux modes 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
30
Pr: Khalid ZENKOUAR
 Fonctionnement du DNS

• Fonctionnement du client : le resolver

– Toute machine utilisant TCP/IP comporte un client permettant la
traduction de noms en adresses IP : le resolver, il permet de
communiquer avec les serveurs DNS

31
Pr: Khalid ZENKOUAR
 Fonctionnement du 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)

32
Pr: Khalid ZENKOUAR
 Fonctionnement du dns

• Fonctionnement du serveur de noms

33
Pr: Khalid ZENKOUAR
 Fonctionnement du dns

• Serveur de noms
• Les serveurs de nom de domaine: permettent d'établir la
correspondance entre le nom de domaine et l'adresse IP des machines
d'un réseau.

• Chaque serveur de nom est déclaré dans à un serveur de nom de

domaine de niveau immédiatement supérieur,

• Ce qui permet implicitement une délégation d'autorité sur les domaines.

• Le système de nom est une architecture distribuée, où chaque entité est
responsable de la gestion de son nom de domaine.

• Il n'existe donc pas d'organisme ayant à charge la gestion de l'ensemble

des noms de domaines.
34
Pr: Khalid ZENKOUAR
 Types de serveurs de noms

• Quatre types de serveurs:

1. Serveur maitre primaire,
2. Serveur maitre secondaire,
3. Serveur cache,
4. Serveur Redirecteur (forwarding)

35
Pr: Khalid ZENKOUAR
 Types de serveurs de noms
• Serveur primaire:
– Un serveur est dit primaire pour une Zone DNS, s’il dispose localement
(hors cache) de l'ensemble des informations de la Zone
– Autorité pour un ou plusieurs domaines
– Ce serveur contient les informations relatives au domaine (dans un
fichier de zone)
 Son père: le serveur du domaine supérieurs (root server ),
 Ses fils : les serveurs de chacun de ses sous-domaine,
 Les noms qu’il gère directement.
– Source officielle des informations concernant son ou ses domaines
– Répond aux requêtes concernant sa zone d’autorité
 Retransmet des requêtes (hors son domaine)
 ou réoriente les clients vers les serveurs concernés (root)
– Transfert de la totalité de la zone aux serveurs secondaires (mise a
jour AXFR, IXFR).
36
Pr: Khalid ZENKOUAR
 Types de serveurs de noms
• Serveur secondaire:
– Il transfère un ensemble complet d’informations sur le domaine à partir
du serveur primaire,

– Ce transfert est appelé un transfert de fichier de zone,

– Il conserve une copie complète de toutes les informations du domaine,

– Répond aux requêtes émanant des clients comme s’il était le serveur
primaire,

– La seule différence entre un serveur primaire et un serveur secondaire

est l’inexistence de fichiers de description des zones au niveau du
serveur secondaire,

– NB: Les domaines sont généralement gérés par un serveur primaire et

un ou plusieurs serveurs secondaires. Ce qui contribue à la
robustesse du système.
37
Pr: Khalid ZENKOUAR
Types de serveurs de noms

38
Pr: Khalid ZENKOUAR
 Types de serveurs de noms
• Serveur cache
• N’a autorité sur aucune zone
– Source non officielle des informations
• 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
– le cache possède alors des informations locales et non locales
• Répond à ses clients en utilisant ces informations locales
– éviter la surcharge inutile du réseau
– supprimer les délais du réseau
– amoindrir la charge des autres serveurs
• 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
• Tout serveur possède en général au minimum un cache.
39
Pr: Khalid ZENKOUAR
 Types de serveurs de noms
• Serveur redirecteur (forwarding)
• Il n’a autorité sur aucune zone,

• Il fait suivre la requête reçue vers d'autres serveurs par une requête elle-
même récursive

• Ces types de serveurs possèdent une liste de serveurs à interroger

– vérifie si la réponse n'est pas dans son cache
– sinon fait suivre la requête à un des serveurs
– 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).

40
Pr: Khalid ZENKOUAR
 Redirecteurs
Un redirecteur est un serveur DNS que d'autres serveurs DNS internes
désignent comme responsable du transfert des requêtes pour la résolution
de noms de domaines DNS externes ou hors site

Requête itérative
Redirecteur Indication de racine (.)
Interroger .com

.com

nwtraders.com
Serveur DNS Computer1
local

41
Pr: Khalid ZENKOUAR
Base données DNS

42
Pr: Khalid ZENKOUAR
 Base données DNS

• Comme pour toute base de données, le serveur de

nom a un format pour ses champs, ou “ Resource
Record ”, (RFC 1035),

• L'ensemble des informations de la base de données

DNS est structuré autour des Resource Records.

43
Pr: Khalid ZENKOUAR
 Base données DNS
• Resource Record (RR)
– Les nœuds de l’espace sont décrits par des RR
maintenus à jour sur des serveurs autorisés : opération
manuelle,

– Le rôle des serveurs de noms est de propager ces

informations en répondant aux questions des résolveurs,

– Les données associées a chaque nom de domaine sont

enregistrées sous forme de Resource Record (RR)

44
Pr: Khalid ZENKOUAR
 Resource Record RR
• Un enregistrement de ressource est composé de cinq champs :

Nom-domaine TTL CLASS TYPE RDATA

Poste.informatique.fst. 172800 (2j) IN A 192.168.1.10

durée de vie
A
Nom domaine en cache IN, CNAME A
du RR Sur 32-bits CH MX CNAME
NS MX
PTR PTR
SOA. SOA
45
Pr: Khalid ZENKOUAR
 Resource Record RR
Nom-Domaine est un nom absolu de l'espace de nommage DNS (FQDN Fully
Qualified Domain Name)

TTL Time To Live définit la durée de vie de l'objet dans les caches.
Elle s'exprime en secondes par un entier 32bits, soit 140 ans
max.

CLASSE vaut IN pour internet, CH pour chaos, HS pour Hesiod...

TYPE le type de données du RR

RDATA la valeur de l'objet. Elle dépend directement du TYPE de RR

46
Pr: Khalid ZENKOUAR
 Type de base RR
Type RR Description

A Résout un nom d'hôte en adresse IP

AAAA adresse IPv6

PTR Résout une adresse IP en nom d'hôte

Premier enregistrement dans tout fichier de zone,

SOA description de la base de données d'une zone

SRV Résout les noms des serveurs qui fournissent des services

NS Identifie le serveur DNS associé à chaque zone

MX Serveur de messagerie

CNAME Rèsout un nom d'hôte en nom d'hôte (Alias)

47
Pr: Khalid ZENKOUAR
FORMAT DES MESSAGES DNS

48
Pr: Khalid ZENKOUAR
 FORMAT DES MESSAGES DNS

• Entête du message DNS

• DNS utilise une structure de message normalisé
précédée d’un en-tête. Cette structure est définie par la
RFC 883.

49
Pr: Khalid ZENKOUAR
 FORMAT DES MESSAGES DNS
• Entête du message DNS:
• ID (16 bits) : N° d’identificateur généré par la station qui émet la
demande. Il est recopié dans chaque réponse et permet de faire
correspondre chaque requête à son résultat.
• QR (1 Bit) : Indique si le message est une question (Query=0) ou une
réponse (R=1)
• Opcode (4 Bits) : Ce champ précise le type de requête. Il est défini lors
de l’envoi de la demande et recopié dans toutes les réponses. Les
valeurs suivantes sont possibles :

50
Pr: Khalid ZENKOUAR
 FORMAT DES MESSAGES DNS
• Entête du message DNS:
• Indicateur AA ( Authorative Answer, 1 Bit) : Indique que le serveur de
noms qui à répondu représente une autorité pour le domaine interrogé,

• Indicateur TC (TrunCation, 1 Bit) : Indique si le message dépasse 512

octets et fait donc parti d’un message plus important,

• Indicateur RD (Recursion Desired, 1 Bit) : Signale au serveur que la

demande doit être traitée de manière récursive. Ne fonctionne que si
cette option est active sur le serveur DNS,

• Indicateur RA (Recursion Available, 1 Bit) : Indique que le serveur prend

en charge les demandes récursives,

• La zone réservée de 3 bits qui suit reste vide et sert à compléter la ligne
pour atteindre 16 Bits.
51
Pr: Khalid ZENKOUAR
 FORMAT DES MESSAGES DNS

• Entête du message DNS:

• Rcode (Response Code, 4 Bits) : cette valeur et
positionnée dans la réponse par le serveur et indique les
erreurs éventuelles :

52
Pr: Khalid ZENKOUAR
 FORMAT DES MESSAGES DNS

• Entête du message DNS:

• Les compteurs suivant permettent de savoir comment sont découpées les
données qui suivent l’en-tête dns et qui contiennent les demandes et les
réponses.

– Compteur QD (16 Bits) : Nombre d’entrées dans la zone de demande

– Compteur AN (16 Bits) : Nombre de messages de réponse

– Compteur NS (16 Bits) : Nombre de serveurs de noms contenues

dans la zone des données d’autorité

– Compteur AR (16 Bits) : Nombre d’enregistrements pour des entrées

supplémentaires dans la zone. 53
Pr: Khalid ZENKOUAR
 FORMAT DES MESSAGES DNS

• Données dns

54
Pr: Khalid ZENKOUAR
 FORMAT DES MESSAGES DNS

• Données DNS
– Question : contient le nom de la requête et ses autres
paramètres.

– Réponse :contient les RR qui répondent directement à la requête.

– Autorité :contient les RR décrivant d'autres serveurs "autorisés".

Peut aussi contenir un RR SOA contenant les données
d'autorisation dans la section réponse.

– Additionnel: contient les RR qui peuvent aider à exploiter les RR

contenus dans les autres sections.

55
Pr: Khalid ZENKOUAR
 FORMAT DES MESSAGES DNS
• Question (Requête DNS)
• Une requête DNS est un triplet de la forme
{Nom-Domaine CLASSE QTYPE}

• QName: Nom du domaine où se trouve le RR.

• QClasse: Une valeur encodée sur 16 bits identifiant une
famille de protocoles ou une instance d'un protocole.
• QType: Query type codé sur 16 bits, spécifie quel type
de donnée sont utilisés dans le RR: A, PTR……
56
Pr: Khalid ZENKOUAR
 FORMAT DES MESSAGES DNS
• Réponse DNS

• TTL: C'est la durée de vie des RRs (32 bits, en secondes), utilisée
par les solveurs de noms lorsqu'ils ont un cache des RRs pour
connaître la durée de validité des informations du cache (durée
limite pendant laquelle un RR peut être conservé dans un cache
local).
• Longueur: Sur 16 bits, ce champ indique la longueur des
données suivantes.
57
Pr: Khalid ZENKOUAR
 FORMAT DES MESSAGES DNS

• Réponse DNS
• Données: Données identifiant la ressource, ce que l'on
met dans ce champs dépend évidemment du type de
ressources que l'on décrit.
– A : Pour la classe IN, une adresse IP sur 32 bits,
– CNAME : un nom de domaine,
– MX: une valeur de préférence sur 16 bits (la plus basse
possible) suivie d'un nom d'hôte souhaitant servir d'échangeur
de courrier pour le domaine,
– PTR : Une adresse IP sous forme d'un nom,
– NS : Un nom d'hôte.

58
Pr: Khalid ZENKOUAR
 FORMAT DES MESSAGES DNS
• Réponse DNS
• La réponse ou résolution d'une requête de base
(QTYPE=TYPE) consiste à trouver l'ensemble des RRs du
DNS qui correspondent.

Exemple:
• Requête :
• khalid.informatique.fst IN A
• Réponse:
khalid.informatique.fst . 86400 IN A
192.168.1.10
59
Pr: Khalid ZENKOUAR
FORMAT DES MESSAGES DNS

60
Pr: Khalid ZENKOUAR
FORMAT DES MESSAGES DNS

61
Pr: Khalid ZENKOUAR
FORMAT DES MESSAGES DNS

62
Pr: Khalid ZENKOUAR
DNS sous Linux

63
Pr: Khalid ZENKOUAR
 DNS sous Linux

• BIND Berkeley Internet Name Domain

– Sous UNIX, le DNS est implanté par le programme BIND,
– BIND est un système client/serveur,
– La partie serveur de BIND est le démon named,
– La partie client est appelée le résolveur:
elle génère des requêtes pour obtenir des informations relatives à un
nom.

64
Pr: Khalid ZENKOUAR
 DNS sous Linux
• Configurer le résolveur.
– La configuration du résolveur figure dans le fichier: /etc/resolv.conf
– nameserver: c’est l’option principale, elle indiquent les adresses IP des
serveurs auxquelles le résolveur envoie ses requêtes pour obtenir des
informations (max 3 serveur),
– domain: L’entrée domain définit le nom de domaine par défaut. Le résolveur
ajoute le nom de domaine par défaut à n’importe quel nom de machine qui ne
contient pas de point,
– search: définit une liste de domaines recherchés lorsqu’un nom ne contient
pas de point,
– NB:
• Cela signifie que les entrées domain et search sont redondantes,
• Lorsqu’un nom ne contient pas de point, l’entrée domain est en premier lieu utilisée
pour compléter le nom. Si la recherche échoue, ce sont les entrées search qui sont
exploitées dans l’ordre de leurs apparitions pour tenter de compléter le nom,
• Il n’est pas recommandé d’utiliser à la fois domain et search dans une même
configuration.
65
Pr: Khalid ZENKOUAR
 DNS sous Linux
• Configuration du résolveur:
– exemple de fichier resolv.conf

66
Pr: Khalid ZENKOUAR
 DNS sous Linux
• Configuration du daemon named
– La base données du DNS est constitue de deux fichiers:

• Fichier de zone: relie les noms d’hôtes à leur

adresse,
• Fichier de zone inverse: relie les adresses à leur
nom d’hôte.

– named.ca: Fichier de zone racine, définit

l’emplacement des serveurs racine.

– named.conf: fichier de configuration principal, relié

les fichiers de la base données entre eux.
67
Pr: Khalid ZENKOUAR
 DNS sous Linux

• Configuration du daemon named

68
Pr: Khalid ZENKOUAR
 DNS sous Linux
• Configuration du daemon named
• named.conf : C’est le fichier de configuration lu au
démarrage. il est exploité afin de stipuler à BIND quels fichiers
de base de données il doit utiliser,

• named.ca (.root): L’objectif de ce fichier est de définir

l’emplacement des serveurs de la racine(Généralement, les configurations de
serveurs de noms possèdent déjà ce fichier).

• localhost.rev(0.0.127): Le serveur de noms a besoin d’un autre

fichier de correspondance inverse pour le réseau loopback. Ce réseau est
utilisé par un hôte pour communiquer avec lui-même. Le numéro de ce
réseau est toujours 127.0.0 et l’adresse de l’hôte est toujours 127.0.0.1.

69
Pr: Khalid ZENKOUAR
 DNS sous Linux

• Configuration du daemon named

• Fichiers de zone
– Fichier de zone (Informatique.fst.db):
– Ce fichier contient la base donnée de la zone. Ce fichier
permet de convertir des noms en adresses IP,

– Fichier de zone inverse (1.168.192.db):

– Ce fichier contient la base de données de la zone
“reverse” pour le domaine informatique.fst, il permet de
convertir les adresses IP en noms.

70
Pr: Khalid ZENKOUAR
 Base donnée DNS

• Cinq enregistrements, ou “Resource Record”, sont

absolument fondamentaux pour faire fonctionner un serveur
de noms : SOA, NS, A, MX et PTR.

• RR type SOA
$ORIGIN informatique.fst.
@ IN SOA ns1.informatique.fst. admin.informatique.fst . (
2007100801 ; Serial
10800 ; Refresh (3h)
3600 ; Retry (1H)
3600000 ; Expire (5w6d16h)
86400 ) ; Minimum ttl (1D)
71
Pr: Khalid ZENKOUAR
 Base données DNS
• RR de type SOA
• SOA est l’acronyme de “ Start Of Authority ” et désigne le début obligé et
unique d’une zone,
• Il doit figurer dans chaque fichier de zone( directe et inverse),
• Le nom de cette zone est ici repéré par le caractère @ qui signifié la zone
courante, repérée par la ligne au dessus :
$ORIGIN informatique.fst.
• La ligne aurait également pu s’écrire :
informatique.fst. IN SOA ns1.informatique.fst. admin.informatique.fst.
• Un problème concernant cette zone devra être signalé par e-mail à
admin@informatique.fst (notez le “.” qui s’est transformé en “@”),
• Les paramètres de ce SOA sont décrits sur plusieurs lignes, regroupées
entres parenthèses. Le caractère “;” marque le début d’un commentaire,
qui s’arrête à la fin de ligne,
• Les points en fin de noms sont nécessaires.
72
Pr: Khalid ZENKOUAR
 Base donnée DNS
• RR de type SOA
• Numéro de série (serial) : Identifie la version de la zone ; quand on
modifie le fichier de zone, on incrémente ce numéro.

• Rafraîchissement (refresh) : intervalle en secondes destiné au serveur

secondaire pour rafraîchir son fichier de zone (nombre décimal entier sur
8 chiffres). Cette valeur peut être élevée si on a maintenu l'option "notify
yes" au niveau du serveur maître.

• Tentatives (retry) : intervalle en secondes avant de recontacter le

serveur principal en cas d'échec de la demande de rafraîchissement.

• Expiration (expire) : indique le temps en secondes, au bout du quel un

serveur secondaire doit éliminer toutes les informations de zone s'il n'a
pas pu contacter le serveur (cette valeur doit être élevée).

73
Pr: Khalid ZENKOUAR
 Base donnée DNS
• RR de type SOA
• TTL: Durée de présence d'une réponse négative dans les caches suite à
une question sur le domaine,
• Toutes les "refresh" secondes, le serveur secondaire transfère le SOA
de la zone et vérifie si le numéro de série a augmenté ; si c'est le cas le
transfert de zone a lieu.
• En cas d'échec de cette interrogation, le serveur secondaire recommence
toutes les "retry" secondes jusqu‘à atteindre le temps d'expiration
(expire).

• Remarque:
– Mais si on maintient, sur le serveur primaire, l'option par défaut de notification,
le serveur maître notifiera immédiatement tout changement de son fichier de
zone au serveur secondaire,
– Attention : à chaque modification du fichier de zone, il ne faut pas oublier
d'augmenter le numéro de série et de faire une relecture par le démon du
fichier de configuration. 74
Pr: Khalid ZENKOUAR
 Base donnée DNS
• RR de type NS
• Il faut ajouter une ligne de ce type (“ Name Server ”) pour chaque serveur
de noms pour le domaine. Notez bien que rien dans la syntaxe ne permet
de distinguer le serveur principal de ses secondaires.
• Dans le fichier de zone :

IN NS ns1.informatique.fst.
IN NS ns−slave1.informatique.fst.
IN NS ns−slave2.informatique.fst.

• Dans le fichier qui renseigne la zone “ reverse ”:

1.168.192.in−addr.arpa. IN NS ns1.informatique.fst.
1.168.192.in−addr.arpa. IN NS ns−slave1.informatique.fst.
1.168.192.in−addr.arpa. IN NS ns−slave2.informatique.fst.
75
Pr: Khalid ZENKOUAR
 Base donnée DNS

• RR de type A “Address record”

• Attribue une ou plusieurs adresses à un nom, c’est donc celui
qui est potentiellement le plus fréquemment utilisé,
• Il doit y avoir un RR de type A pour chaque adresse d’une
machine.

ns1 IN A 192.168.1.2
Poste1 IN A 192.168.1.10
Poste2 IN A 192.168.1.20
Poste2.informatique.fst. IN A 192.168.1.20

76
Pr: Khalid ZENKOUAR
 Base donnée DNS
• RR de type PTR“ PoinTeR Record ”
• Permet de spécifier les adresses pour la résolution inverse, donc dans le
domaine spécial: in-addr.arpa
• Notez le “.” en fin de nom qui interdit la complétion (il s’agit bien du nom
FQDN).

2 IN PTR ns1.informatique.fst.
10 IN PTR poste1.informatique.fst.
20 IN PTR poste2.informatique.fst.
(2.1.168.192.in-addr.arpa. IN PTR ns1.informatique.fst. )

77
Pr: Khalid ZENKOUAR
 Base donnée DNS
• Le RR de type MX,“Mail eXchanger”
• Concerne les relations entre le serveur de noms et le courrier
électronique.
priorité

IN MX 10 mail.informatique.fst.
IN MX 20 mail2.informatique.fst.

• RR de type CNAME “ canonical name ”

• permet de distinguer le nom officiel d’une machine de ses surnoms.

www IN CNAME poste1

ftp IN CNAME poste1

78
Pr: Khalid ZENKOUAR
 Base donnée DNS
• Remarque
• Il existe d’autres RR, HINFO ,TXT, WKS et KEY,

79
Pr: Khalid ZENKOUAR
Fichiers de configuration de DNS

• Le fichier named.conf,
• Le fichier named.ca,
• Le fichier de zone directe,
• Le fichier de zone inverse.

80
Pr: Khalid ZENKOUAR
 named.conf
• Le fichier named.conf est une suite de déclarations utilisant des options
imbriquées qui sont placées entre accolades, { }.
• Un fichier named.conf typique est organisé de manière semblable à
l'extrait ci-dessous :
<déclaration-1> ["<déclaration-1-nom>"] [<déclaration-1-classe>]
{
<option-1>;
...
<option-N>;
};

<déclaration-N> ["<déclaration-N-nom>"] [<déclaration-N-classe>]

{
<option-1>;
...
<option-N>;
};
81
Pr: Khalid ZENKOUAR
 named.conf
• Types courants de déclarations:
 Déclaration acl,
 Déclaration include,
 Déclaration options,
 Déclaration zone.

82
Pr: Khalid ZENKOUAR
 named.conf
• Déclaration acl (liste de contrôle d'accès)
• Définit des groupes d'hôtes,
• Le but est de pouvoir désigner ces groupes par leur nom et leur
appliquer des options dans d’autres déclarations,
• La syntaxe:

acl <nom_de_la_liste> {
<élément-correspondant>;
[<élément-correspondant>; ...]
};

83
Pr: Khalid ZENKOUAR
 named.conf

• Déclaration include,
• Le fichier /etc/named.conf est accessible en lecture pour tous les
utilisateurs
• La déclaration include permet à des fichiers d'être inclus dans un fichier
named.conf.
• Finalité, des données de configurations critiques (telles que les clés,
keys) peuvent être placées dans un fichier séparé doté de permissions
restrictives.
• Syntaxe:

include "file_name"

84
Pr: Khalid ZENKOUAR
 named.conf
• Déclaration option
• La déclaration options définit les options globales de configuration serveur
et établit des valeurs par défaut pour les autres déclarations.
• Syntaxe:

options {
<option>;
[<option>; ...]
};

• Option de configuration
• allow-query : Spécifie les hôtes autorisés à interroger ce serveur de noms.
Par défaut, tous les hôtes sont autorisés à interroger le serveur de noms.
Il est possible d'utiliser ici une liste de contrôle d'accès ou un ensemble d'adresses
IP ou de réseaux afin de n'autoriser que des hôtes particuliers à interroger le 85
serveur de noms. Pr: Khalid ZENKOUAR
 named.conf
• Déclaration option
• Option de configuration(suite)
• allow-recursion: cette option s'applique à des demandes récursives. Par défaut,
tous les hôtes sont autorisés à effectuer des demandes récursives sur le serveur de
noms,
• Blackhole: Spécifie les hôtes qui ne sont pas autorisés à interroger le serveur de
noms,
• Directory: Change le répertoire de travail named pour une valeur autre que la
valeur par défaut, /var/named/,
• forward : Contrôle le comportement de retransmission d'une directive forwarders.
– Les options suivantes sont acceptées :
• first : Établit que les serveurs de noms spécifiés dans la directive forwarders soient
interrogés avant que named ne tente de résoudre le nom lui même.
• only : Spécifie que named ne doit pas tenter d'effectuer lui-même une résolution de
nom dans le cas où des demandes vers les serveurs de noms spécifiés dans la
directive forwarders échouent.

86
Pr: Khalid ZENKOUAR
 named.conf
• Déclaration option
• Option de configuration (suite)
• forwarders : Spécifie une liste d'adresses IP valides correspondant aux serveurs
de noms vers lesquels les requêtes devraient être envoyées pour la résolution.
• listen-on: Spécifie l'interface réseau sur laquelle named prend note des
requêtes. Par défaut, toutes les interfaces sont utilisées.
• notify : Établit si named notifie les serveurs esclaves lorsqu'une zone est mise à
jour.
– Les options suivantes sont acceptées :
• yes : Notifie les serveurs esclaves.
• no : Ne notifie pas les serveurs esclaves.
• explicit : Notifie seulement les serveurs esclaves spécifiés dans une liste also-notify à
l'intérieur d'une déclaration de zone.
• statistics-file : Spécifie un autre emplacement des fichiers de statistiques. Par
défaut, les statistiques named sont enregistrées dans le fichier
/var/named/named.stats.
87
Pr: Khalid ZENKOUAR
 named.conf

• Déclaration Les options:

• Exemple
acl " info-fst" { 127.0.0.1; 192.168.1.0/24; };
options {
directory "/var/named";
forwarders {
193.252.19.3; # Les DNS de notre
193.252.19.4; # providers
};
allow-query { "info-fst";};
listen-on { 192.168.1.2; };
};
88
Pr: Khalid ZENKOUAR
 named.conf

• Déclaration zone
• La plupart des changements apportés au fichier /etc/named.conf d'un
serveur de noms maître ou esclave implique l'ajout, la modification ou la
suppression de déclarations de zone.
• Définit les caractéristiques d’une zone,
• Emplacement des fichiers de configuration de la zone,
• Options spécifiques à la zone.

• Syntaxe

zone <zone-nom> <zone-classe> {

<zone-options>;
[<zone-options>; ...]
}; 89
Pr: Khalid ZENKOUAR
 named.conf
• Options de déclaration de zone

90
Pr: Khalid ZENKOUAR
 named.conf
• Déclaration zone
• Ci-dessous se trouve un exemple de déclaration zone pour le serveur de
noms primaire hébergeant informatique.fst (192.168.1.2) :

zone " informatique.fst " IN {

type master;
file "informatique.fst.db";
allow-update { none; };
};

– Dans cette déclaration, la zone est identifiée en tant que informatique.fst,

– Le type est défini comme master,
– Le service named a comme instruction de lire le fichier /var/named/informatique.fst.zone,
– Elle indique à named de refuser la mise à jour à tout autre hôte.

91
Pr: Khalid ZENKOUAR
 named.conf
• Déclaration zone:
zone " informatique.fst " {
type slave;
file " informatique.fst.zone";
masters { 192.168.1.2; };
};

• Cette déclaration zone configure named sur le serveur esclave de

manière à ce qu'il cherche le serveur maître à l'adresse IP 192.168.1.2
pour y trouver les informations concernant la zone appelée
informatique.fst.
• Les informations que le serveur esclave reçoit du serveur maître sont
enregistrées dans le fichier /var/named/informatique.fst.zone.
92
Pr: Khalid ZENKOUAR
 named.conf
• [root@serveurdns /etc]# cat named.conf
zone "0.0.127.in-addr.arpa" IN {
options {
type master;
directory "/var/named";
file "0.0.127";
};
};
zone "." IN {
zone " sir.informatique.fst" IN {
type hint;
type master;
file "named.ca";
file " sir.informatique.fst.db";
};
};
zone "localhost" IN {
zone "1.168.192.in-addr.arpa" IN
type master; {
file "localhost"; type master;
}; file "1.168.192.db";
};
93
Pr: Khalid ZENKOUAR
 named.ca
• zone racine (named.ca)/(named.root)
• L’objectif du fichier named.ca consiste à définir l’emplacement des
serveurs de la racine.
• Généralement, les configurations de serveurs de noms possèdent
déjà un tel fichier.

94
Pr: Khalid ZENKOUAR
 Fichiers de zone
• Fichiers de zone
• Les Fichiers de zone contiennent des informations sur un espace de nom
particulier et sont stockés dans le répertoire de travail named qui est par
défaut /var/named/.
• Chaque fichier de zone est nommé selon les données d'options de file
dans la déclaration zone,généralement d'une manière qui se réfère au
domaine en question (exp: informatique.fst.zone).
• Chaque fichier de zone peut contenir des:
– Directives: donnent au serveur de noms l'instruction d'effectuer une certaine
tâche ou d'appliquer des paramètres spéciaux à la zone.
– Enregistrements de ressources RR: définissent les paramètres de la zone,
assignant des identités aux hôtes individuels.
• NB:
– Toutes les directives et enregistrements de ressources doivent être spécifiées sur
des lignes individuelles.
– Des commentaires peuvent être placés dans les fichiers de zone après les
caractères points virgules ;
95
Pr: Khalid ZENKOUAR
 Fichiers de zone
• Directives des fichiers de zone
• Les directives sont identifiées par le symbole dollar ($) suivit du nom de
la directive,
• Elles apparaissent généralement en haut du fichier de zone,
• Les directives les plus couramment utilisées sont les suivantes :
– $INCLUDE: Configure named de façon à ce qu'il inclue un autre fichier de
zone dans ce fichier de zone à l'endroit où la directive apparaît. Ce faisant, il
est possible de stocker des configurations de zone supplémentaires à l'écart
du fichier de zone principal.

– $ORIGIN : Attache le nom de domaine à des enregistrements non-qualifiés,

comme ceux qui spécifient seulement l'hôte et rien de plus.
Par exemple, un fichier de zone peut contenir la ligne suivante :
$ORIGIN informatique.fst.
Tous les noms utilisés dans les enregistrement de ressources qui ne se
terminent pas par un point (.) se verront ajouter informatique.fst.
96
Pr: Khalid ZENKOUAR
 Fichiers de zone
• Directives des fichiers de zone (suite)
– $TTL : Règle la valeur par défaut Time to Live (TTL) pour la zone. C'est le
nombre, en secondes, donné aux serveurs de noms pour dire combien
de temps les enregistrements de ressources de la zone resteront valides.
– Lorsque vous décidez d'accroître cette valeur, les serveurs de noms
distants mettent en cache ces informations de zone pendant plus
longtemps.
Cela réduit le nombre de requêtes effectuées au sujet de cette zone,
mais rallonge aussi le temps nécessaire pour proliférer les changements
des enregistrements de ressources.
– Chaque enregistrement de ressources peut contenir sa propre valeur TTL,
qui remplace alors cette directive.
• Enregistrements de ressources des fichiers de zone
• Les enregistrements de ressources représentent le premier composant
d'un fichier de zone.
97
Pr: Khalid ZENKOUAR
 Fichier de zone directe
$ORIGIN informatique.fst.
$TTL 86400
@ IN SOA dns1.informatique.fst. admin.informatique.fst. (
2001062501 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ) ; minimum TTL of 1 day
;serveur dns
@ IN NS dns1. informatique.fst.
IN NS 192.168.1.2

; Enregistrements MX
IN MX 10 mail.informatique.fst.
IN MX 20 mail2.informatique.fst.

; nom de machine
dns1 IN A 192.168.1.2
server1 IN A 192.168.1.5
server2 IN A 192.168.1.6

;alias
ftp IN CNAME server1
mail IN CNAME server1
mail2 IN CNAME server2 98
www IN CNAME server2
Pr: Khalid ZENKOUAR
 Fichiers de résolution de noms inverse

• Il ressemble à un fichier de zone standard, sauf que les enregistrements

de ressources PTR servent à lier les adresses IP au nom d'un domaine
pleinement qualifié.
• Ce fichier de zone serait mis en service avec une déclaration zone dans
le fichier named.conf similaire à l'extrait suivant :

zone "1.168.192.in-addr.arpa" IN {
type master;
file "informatique.fst.rr.zone";
allow-update { none; };
};

99
Pr: Khalid ZENKOUAR
 Fichiers de résolution de noms inverse

$ORIGIN 1.168.192.in-addr.arpa.
$TTL 3600
1.168.192.in-addr.arpa. IN SOA dns1.informatique.fst. admin.informatique.fst. (
5 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
3600 ) ; Minimum

@ IN NS dns1.informatique.fst.

2 IN PTR dns1
5 IN PTR serveur1
6 IN PTR serveur2

100
Pr: Khalid ZENKOUAR
 localhost, localhost.rev(0.0.127)
• Le serveur de noms a besoin d’autres fichiers de correspondance directe
et inverse(localhost, localhost.rev) pour le réseau loopback.
• Ce réseau est utilisé par un hôte pour communiquer avec lui-même.
• Le numéro de ce réseau est toujours 127.0.0 et l’adresse de l’hôte est
toujours 127.0.0.1.
0.0.127.in-addr.arpa. IN SOA dns1.informatique.fst. admin.informatique.fst (
1998120701 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
0.0.127.in-addr.arpa. NS localhost.

• NB: L’omission de ces fichiers permettra au serveur de fonctionner mais la

recherche de 127.0.0.1, échouera car le serveur racine ne peut réaliser la
correspondance 127.0.0.1 à l’hôte local.
101
Pr: Khalid ZENKOUAR
 Utilitaires DNS
• Outils pour vérifier l'opération de résolution
de nom d’un serveur :
–nslookup,
–dig,
–host,
–ping.

102
Pr: Khalid ZENKOUAR