Administration Linux Avancée

M. Jean DIOKH

Séquence 3 : Service de résolution de nom

Service de résolution de nom : DNS

M. DIOKH 1
1 Concepts du DNS

Le système DNS (Domain Name System) est le support de nombreuses fonctionnalités sur Internet
allant de la navigation à l’envoi de courriers électroniques.

La résolution de noms consiste à faire correspondre un nom facile à mémoriser à une adresse IP, seule
information réellement exploitable pour contacter une machine distante.

Avant, toutes les résolutions se faisaient au moyen d’un fichier appelé hosts qu’on téléchargeait à
intervalle régulier pour se tenir au courant des nouveautés. L'inconvénient de ce système est qu'il était
difficile de faire la mise à jour à cause de l’augmentation de la taille de fichier ; plus il y’a de serveurs
sur Internet, plus la taille du fichier augmente.

Le DNS a été conçu pour pallier les limites du fichier hosts téléchargé, et devait répondre à certains
impératifs de conception.

Le DNS est hiérarchisé en zone et chaque arborescence est un domaine.

La racine de la hiérarchie est appelée "." (point). Elle contient les tous les domaines de premier niveau
(tld – top level domain). Les tld sont les extensions telles que sn, bj, ci, fr, com, net,…

L’intérêt de cette organisation est de dédier un serveur à la gestion d’une zone.

Si un serveur DNS héberge les données d’une zone, il est consulté pour toute résolution de noms se
terminant par le nom du domaine, mais il n’héberge pas nécessairement les données des sous-
domaines, et peut se contenter de rediriger la requête vers le serveur de la zone enfant. On parle alors
de délégation dans le sens où on délègue la gestion d’une zone enfant à un autre serveur.

Pour des raisons de tolérance de panne, les données de chaque zone DNS doivent être répliquées au
moins une fois.

Les zones hébergées sur un serveur DNS primaire sont de type master, et ceux qui hébergent une
réplique de la zone (serveur secondaire) sont configurés en tant que slave.

M. DIOKH 2
2 Mécanisme de la résolution de noms

Quand une application d’une machine doit faire une résolution de noms, elle s’adresse au composant
resolver de son système d’exploitation. Le resolver (le fichier /etc/resolv.conf sous Linux) va alors
envoyer une requête de résolution de noms au serveur DNS référencé sur cette machine.

Les requêtes de client à serveur se font sur le port 53 et sont transportées par le protocole UDP.

Si le serveur interrogé dispose localement de l’information, il répond directement. On dit qu’il fait une
réponse authoritative (autoritaire).

Si le serveur interrogé ne dispose pas de l’information, il va consulter la seule zone qu’il connaît, la
zone ".", qui lui donnera l’adresse d’un des 13 serveurs racines de l’Internet. Le serveur interrogera
alors ce serveur racine pour connaître l’adresse d’un serveur de la zone du tld : top level domain
(domaine de premier niveau). Lequel serveur sera interrogé à son tour pour connaître l’adresse d’un
serveur de noms gérant la zone directement sous le tld. Enfin, ce serveur sera interrogé pour savoir s’il
dispose de l’enregistrement voulu dans ce domaine.

3 Les types d’enregistrements

Il existe plusieurs types d’entrées (ou enregistrements) DNS.

 A – Adresse :

Nom → Adresse IP

Exemple :
server IN A 192.168.1.20

 NS - Name Server

Spécifier le serveur faisant autorité sur le domaine

Exemple :
@ IN NS ns.test.sn.
ns IN A 192.168.1.18

M. DIOKH 3
 SOA – Start Of Autoriry

Informations générales sur la zone : -

Serveur maître
- Adresse mail de l'admin
- Paramètres

Exemple :
@ IN SOA ns.test.sn. admin.test.sn. (
20181030302 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL

Paramètre Description

Serial Numéro de série.

Permet au serveur secondaire de savoir s’il doit se mettre à jour.
Incrémenté à chaque modification du fichier.
Par convention : yyyymmdd + numéro de la modification.

Refresh Fréquence de consultation du serveur primaire par les serveurs

secondaires.

Retry Temps d'attente avant nouvel essai en cas d'echec de refresh.

Expire Durée d'indisponibilité du serveur primaire après laquelle celui-ci sera

considéré comme retiré du service.

Minimum TTL TTL minimum du cache

 Alias - CNAME

Le nom canonique (ou nom de domaine complet) d’un alias ; utilisé lorsque plusieurs services
comportent une adresse réseau unique mais que chaque service comporte sa propre entrée
dans DNS.

Nom → Nom (A)

Exemple :
www IN CNAME server.test.sn.
server IN A 192.168.1.20

M. DIOKH 4
 MX – Mail Exchange (Serveur Mail du domaine)

Enregistrement d’échange de courriel ; associe un nom de domaine à une liste de serveurs d’échange
de courriel pour ce domaine.

Exemple :

test.sn. IN MX 10 mail1.test.sn.

 PTR

L'enregistrement PTR permet de faire la résolution inverse : IP – nom.

Dans le cas de la messagerie, l'enregistrement PTR permet de contrôler l'authenticité des serveurs de
mails.

18.1.168.192.in-addr.arpa. IN PTR mail1.test.sn.

M. DIOKH 5
4 Serveur Cache

Un serveur DNS de cache assure une résolution de noms, mais n’héberge aucune donnée de résolution
locale et s’appuie sur une infrastructure déjà existante. Les requêtes DNS sont relayées vers d’autres
serveurs.
Aucune configuration n’est requise après l’installation de bind9.

Test de fonctionnement avec la commande dig :

- Première requête vers www.uvs.sn

- Deuxième requête vers www.uvs.sn

Pour plus de rapidité de traitement, nous pouvons indexer un serveur DNS spécifique, par exemple
celui du FAI, au lieu des serveurs de la racine. C’est la redirection.

Exemple dans le fichier named.conf.options:

M. DIOKH 6
5 Serveur DNS primaire

Domaine : test.sn

Adresse IP Serveur DNS Primaire : 192.168.1.18

5.1 Résolution directe

Les informations nécessaires à la résolution devront se trouver dans un fichier de déclaration de zone.
L’emplacement de ce fichier est libre, puisqu’il est défini dans une section zone de named.conf.default-
zones. Toutefois, un usage établi veut que ce fichier soit placé dans le répertoire /etc/bind/ pour les
distributions de type Debian.
Ce fichier a un format très strict. Dans la plupart des cas, un refus de démarrer est dû à un fichier de
zone mal formé.
Il est composé des déclarations de durée de vie en cache des informations, du serveur ayant autorité
sur la zone, des serveurs de noms desservant cette zone, et de l’ensemble des enregistrements de
ressources de cette zone.

 Déclaration de la zone directe

Selon les implémentations, un certain nombre de zones sont présentes par défaut à l’installation du
serveur pour assurer un fonctionnement standard et permettre les résolutions courantes. Par
exemple, la zone localhost qui permet de résoudre le nom localhost en 127.0.0.1, y compris au sein du
service DNS et pas seulement dans le fichier hosts.

Déclaration de la zone test.sn :

zone Conteneur pour le nom d’une zone DNS gérée par le serveur.

type Dans une directive zone. Indique le type de zone stockée. Les principales valeurs sont hint
(serveurs racine), master (serveur maître d’une zone), et slave (réplique depuis un master).

file Dans une directive zone. Indique le fichier contenant les informations de zone.

 Création du fichier de zone directe :

M. DIOKH 7
 - Se déplacer vers le dossier /etc/bind et faire une copie du fichier db.local vers le fichier de
zone.

- Modifier le fichier zone avec les informations de la zone et ajouter les enregistrements.

Exemple : contenu fichier db.test.sn

 Configuration côté client

Après configuration du serveur DNS, il faut mettre à jour le client DNS (le fichier /etc/resolv.conf) en
y mettant l’adresse de votre serveur DNS.

nameserver 192.168.1.18

M. DIOKH 8
 Tests de bon fonctionnement

- nslookup

- host

- dig :

M. DIOKH 9
5.2 Résolution Inverse

Le fichier de zone inverse a la même structure qu’un fichier de zone directe.

Le nom normalisé de la zone est formé par les octets de la partie réseau de l’adresse IP ordonnés en
sens inverse, suivi de la chaîne de caractères « .in-addr.arpa ».

Par exemple, la zone inverse pour le réseau 192.168.1.0 sera : 1.168.192.in-addr.arpa, et c’est ce nom
qui devra être employé dans le fichier de zone et dans le fichier named.conf.default-zones.

 Déclaration de la zone inverse

 Création du fichier de zone inverse

- Se déplacer vers le dossier /etc/bind et faire une copie du fichier db.local vers le fichier de
zone.

- Modifier le fichier zone avec les informations de la zone et ajouter les enregistrements.

Exemple : contenu fichier db.192.168.1 :

NB: on peut remplacer 1.168.192.in-addr.arpa par @

M. DIOKH 10
 Tests de bon fonctionnement

- nslookup

- host

- dig

M. DIOKH 11
6 Serveur DNS secondaire

Domaine : test.sn

Adresse IP Serveur DNS Primaire : 192.168.1.18

Adresse IP Serveur DNS Secondaire : 192.168.1.19

 Déclaration de la zone directe et de la zone inverse

 Vérification

Après redémarrage du service DNS, le serveur Secondaire télécharge les fichiers de zone
depuis le serveur Primaire.

- Sur le serveur primaire:

tail -f /var/log/messages

(.....)

M. DIOKH 12
 - Sur le serveur slave:

tail -f /var/log/messages

(....)

NB : Les fichiers doivent être automatiquement créés.

M. DIOKH 13
7 Sécurisation du DNS

7.1 Dissimulation de la version de Bind

L'option "version" permet de dissimuler la version de Bind. En effet une personne malveillante
peut vouloir récupérer la version de votre Bind afin de mener une petite attaque contre ce
dernier s’il n'est pas à jour.
La configuration se fait dans le fichier named.conf.options.

- Avant la configuration :

- Après modification :

7.2 Les ACL

Les ACL (access control lists) permettent de définir des ensembles de machines et/ou de
réseaux.
Une ACL se définit de la façon suivante :

acl name {
address_match_list
};

Exemple :
acl mon_lan {
192.168.1.0/24;
};

M. DIOKH 14
7.3 Limitation des clients

La directive allow-query et allow-recursion dans le fichier de configuration permet de définir

les hôtes ou réseaux auxquels un serveur acceptera de répondre.
allow-query { RESEAUX-AUTORISES; };
allow-recursion { RESEAUX-AUTORISES; };

NB : RESEAUX-AUTORISES représente la ou les adresses de réseaux ou d’hôte qui pourront

s’adresser au serveur.
Cette solution évite que les clients externes se servent de notre DNS en relais.

7.4 Echange sécurisé entre serveurs : Cas Serveur Primaire et Serveur

Secondaire

La sécurisation reposera surtout sur l’authentification et l’intégrité des données. C’est-à-dire qu’on
veut être certain que c’est bien le bon serveur qui nous répond, et que les données ne subissent pas
de modification pendant le trajet.

Nous allons utiliser ici le mécanisme TSIG (Transaction SIGnature, signature des transactions). Ce
mécanisme repose sur la présence d’un secret partagé par les serveurs qui échangent des données.

- Génération de la clé

- Déclaration de clé

Ajouter le contenu du fichier rndc.key à la fin du fichier named.conf.default-zones :

Editer le fichier named.conf.default-zones et renommer la clé :

NB : La même clé doit être utilisée au niveau du slave.

M. DIOKH 15
 - Utilisation de la clé :
Mettre à jour de la déclaration de zone sur le serveur slave :

- Vérification sur le serveur Primaire :

tail -f /var/log/messages

(.....)

M. DIOKH 16