Les différents types de serveurs DNS
Serveur primaire
Un serveur primaire est un serveur qui fait autorité sur sa sa zone. Il s'agit d'un serveur contenant la correspondance entre adresses IP et noms de domaine pour une zone donnée. Il ne renverra donc sur aucun autre serveur s'il reçoit une requête.
Cependant, s'il reçoit une requête ne concernant pas sa zone, il ne saura pas y répondre.
Pour chaque domaine, il ne peut exister qu'un unique serveur primaire.
Quelques tests pour comprendre
On va faire quelques tests avec la commande nslookup et le serveur DNS de wikipedia qui fait évidemment autorité sur la zone "wikipedia.org".
Pour faire appel au DNS de wikipedia, on utilisera l'adresse suivante : ns0.wikimedia.org
Premièrement, faisons une requête au DNS de la FDN (80.67.169.12) pour le nom de domaine wikipedia.org :
[Essayez chez vous !]
nslookup wikipedia.org 80.67.169.12#Reponse:Server: 80.67.169.12Address: 80.67.169.12#53
Non-authoritative answer:
Name: wikipedia.org
Address: 91.198.174.192Name: wikipedia.org
Address: 2620:0:862:ed1a::1Le serveur n'a pas autorité et il l'affiche dans sa réponse. On comprend que ce DNS n'est pas primaire pour la zone wikipedia.org.
Testons maintenant le serveur DNS de wikipedia :
nslookup wikipedia.org ns0.wikimedia.org
#Reponse:Server: ns0.wikimedia.org
Address: 208.80.154.238#53
Name: wikipedia.org
Address: 91.198.174.192Name: wikipedia.org
Address: 2620:0:862:ed1a::1Cette fois-ci le DNS ne répond pas qu'il ne fait pas autorité donc on peut en conclure qu'il est bien primaire pour la zone wikipedia.org.
Essayons un dernier test : demandons au DNS de wikipedia l'adresse correspondant au nom de domaine icann.org :
nslookup icann.org ns0.wikimedia.org
#Réponse:Server: ns0.wikimedia.org
Address: 208.80.154.238#53
** server can't find icann.org: REFUSEDLe serveur étant primaire, il ne peut répondre que pour sa propre zone et ne peut donc répondre positivement aux requêtes concernant d'autres zones.
Serveur secondaire
Pour chaque serveur primaire, il est conseillé d'avoir au moins un serveur secondaire qui prendra le relais en cas de panne du serveur primaire. Il contient donc les mêmes informations que le serveur primaire.
Serveur récursif
Ce type de serveur est celui auquel on adresse le plus souvent nos requêtes en premier lieu. Il ne contient pas de réponse mais sait comment en trouver une à coup sûr si le nom de domaine que vous lui entrez a bien une IP correspondante.
Son fonctionnement est assez simple :
il va faire remonter votre requête à la racine
la racine lui transmettra l'IP du serveur gérant le domaine de premier niveau du nom de domaine de la requête
Le serveur récursif va transmettre la requête à ce serveur.
Ce serveur vous répondra soit l'IP que vous cherchez, soit l'IP du serveur gérant le domaine de second niveau
Et ainsi de suite jusqu'à trouver le serveur primaire contenant la réponse à votre requête.
Voici un petit schéma modélisant le trajet d'une requête :
Un système d'arbre offrant une efficacité dans la récursivité
On voit ici que toute la hiérarchisation en domaines et sous-domaines prend tout son sens dans la recherche récursive. Celle-ci permet d'assurer un résultat certain et en un temps minimum grâce à l'arborescence du système.
Serveur cache
Ce type de serveur est assez simple et se combine en général avec le serveur récursif. Il va simplement conserver pendant un certain temps les réponses données par le serveur auquel il est lié. Ensuite, à chaque réponse qui sera reçue, on consultera d'abord les réponses qu'il a en mémoire avant de demander au serveur récursif.
Cette solution est notamment utilisé sur des DNS recevant un grand nombre de requêtes comme ceux des fournisseurs d'accès internet (F.A.I.).
Mise en place d'un DNS avec bind9
Introduction
BIND (Berkeley Internet Name Daemon) est utilisé par 80% des DNS actuellement. Il a été développé par 4 étudiants de l'Université de Berkeley dans les années 80.
BIND9 est la dernière version qui avait été réécrite totalement pour supprimer les importantes failles de sécurité des versions précédentes.
On va installer BIND9 pour déployer un serveur DNS sur notre propre machine.
Pour installer le paquet, il suffit d'entrer sudo apt-get install bind9 (on conseillera de faire un sudo apt-get update )
Mise en place d'un serveur DNS local minimaliste avec BIND9
Dans cette partie, on va configurer un serveur local et minimal pour faire de simples manipulations et mieux comprendre le fichier de zone.
Première étape : installation du paquet
sudo apt-get install bind9Deuxième étape : modification du fichier
On va éditer le fichier /etc/bind/named.conf.local et y entrer les lignes suivantes :
zone "exemple.com" { type master; file "/etc/bind/db.exemple.com"; };On définit tout d'abord la zone qui est donc exemple.com.
Puis, on dit de le serveur est primaire ("master"). Le type des serveurs secondaires sera "slave".
Enfin, on donne l'emplacement du fichier de zone.
Troisième étape : édition du fichier de zone
On va éditer /etc/bind/db.exemple.com et y entrer les lignes suivantes :
$TTL 10800@ IN SOA ns1.exemple.com. root.exemple.com. ( 1 ; Serial 10800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ;@ IN NS ns1.exemple.com.ns1 IN A 3.3.3.3toto IN A 4.4.4.4tata IN A 5.5.5.5Pour comprendre un peu mieux ces entrées, je vous invite à lire ce grain si ce n'est pas déjà fait : Les enregistrements
Quatrième étape : redémarrer le serveur
Pour redémarrer notre DNS, on utilisera la commande suivante :
sudo /etc/init.d/bind9 restart
Annexes
Le fichier /etc/hosts
Ce fichier, existant depuis le début des années 80, a pour rôle d'associer une adresse IP à un nom d'hôte (un nom de domaine n'étant qu'une forme structurée de nom d'hôte). Il est donc présent dans le répertoire etc et est consulté par votre système à chaque fois que vous tenter d'accéder à un nom d'hôte spécifique.
Notons qu'il est consulté avant qu'une requête soit envoyée à un DNS. Ce fichier n'a de valeur que sur notre propre machine. Aucune autre machine de notre réseau (même local) ne prendra en compte ce qui y est inscrit.
De /etc/hosts au DNS
A l'origine, on se partageait le fichier après l'avoir mis à jour mais très vite le fichier devint trop volumineux et il fallut trouver une solution : le Domain Name System. Il permet donc de centraliser le système de noms d'hôtes. Cependant, le système nécessite une structure (permettant une hiérarchisation des noms) qui fut trouvée dans les noms de domaines.
L'utilisation actuelle du fichier
Ce fichier existe toujours et son utilisation est restreinte à de petits réseaux locaux ainsi qu'à quelques autres cas particuliers.
Sa structure
La structure du fichier est des plus simples : sur chaque ligne, on a une IP et juste à coté le nom d’hôte qui lui correspond. Voici un exemple :
X.X.X.X monsite.frY.Y.Y.Y testComplément : Pour aller un peu plus loin
Lecture du /etc/hosts
Sur Linux, par défaut, une adresse est liée au nom d'hôte "localhost", quelle est-elle ?
Sur Linux, par défaut, une adresse est liée au nom d'hôte "localhost", quelle est-elle ?
On exécute un simple sudo cat /etc/hosts et la réponse nous saute aux yeux.
Cette IP est particulière car elle est, par convention, réservée pour renvoyer sur la machine sur laquelle vous êtes. On parle souvent de localhost ou de loopback address.