Créer un serveur DNS avec Bind9

Aujourd’hui un article sur quelque chose de vu et revu, le DNS ! Nous allons revoir un peu son fonctionnement de base et ses subtilités, puis nous en ferons l’installation sur une Debian Stretch.

Bien, nous allons donc réaliser un rapide réseau local sous VMware Workstation, via l’utilisation de LAN Segment (que nous avions déjà utilisé lors des articles sur pfSense et l’installation d’un VPN ou d’un Proxy). Voici l’aperçu de notre réseau :

• Notre réseau local physique est en 192.168.1.0/24 ;
• Notre réseau virtuel est en 192.168.2.0/24, avec un pfSense permettant de réaliser du NAT et donc de permettre à nos VMs de se connecter à Internet ;

Nous aurons donc un poste client sous Debian, un serveur DNS sous Debian de même, puis un pfSense faisant office de gateway pour arriver sur mon LAN “réel” qui permettra donc de s’échapper sur Internet.

Avant de nous plonger dans l’installation et la configuration de notre serveur DNS, nous allons déjà faire un rapide rappel sur ce qu’est réellement le protocole DNS et sur son fonctionnement !

1) Le protocole DNS

Pour rappel, DNS signifie Domain Name System, c’est-à-dire Système de nom de domaines. C’est ce qui permet de ne pas devoir retenir des centaines d’adresses IP : en effet lorsque, par exemple, votre navigateur accède à notamax.be, votre ordinateur va faire une requête UDP sur le port 53 auprès de votre serveur DNS pour connaître l’adresse IP du site web, et ainsi pouvoir s’y connecter !

*Ce n’est qu’à partir de 1987 que le système DNS voit réellement le jour, car jusqu’à cette date, l’ordinateur utilisait un fichier “hosts.txt” -encore disponible sous Windows- pour établir les correspondances entre nom d’hôtes et adresses IP

Les informations DNS sont regroupées par zones correspondant chacune à un domaine ou à une plage d’adresses IP. Un serveur primaire fait autorité sur le contenu d’une zone ; un serveur secondaire, normalement hébergé sur une autre machine, se contente de proposer une copie de la zone primaire, qu’il met à jour régulièrement.

DNS repose sur un système de hiérarchie, semblable à ce schéma :

Le sommet est appelé la racine, et est représenté par un point. Ensuite, nous avons les domaines de premier niveau, abrégé en TLD (Top Level Domain). Les noms de domaines ne correspondant pas à une extension de pays sont appelés des domaines génériques (gTLD), par exemple .net ou .com, et si ils correspondent à des codes de pays (fr, be, de…), ce sont des domaines de premier niveau national, abrégés en ccTLD.

On représente donc un nom de domaine en indiquant ses domaines successifs délimités par un point, les noms de domaines supérieurs se trouvant à droite. Par exemple, le domaine notamax.be. est un sous-domaine de .be. Cette délégation est accomplie en indiquant la liste des serveurs DNS associés au sous-domaine dans le domaine de niveau supérieur.

Les noms de domaines sont donc résolus en parcourant la hiérarchie de haut en bas, c’est-à-dire en parcourant le nom de domaine de droite à gauche. A noter que pour qu’il fonctionne normalement, un nom de domaine doit donc être correctement délégué.

Pour rappel, un nom de domaine pleinement qualifié -soit un FQDN, Fully qualified domain name-  est un nom de domaine écrit de façon complète, c’est-à-dire qu’il est ponctué par un point final,
par exemple monitoring.notamax.be.

Alors tout ça est bien beau, mais concrètement, comme se passe la résolution DNS ? Et la résolution inverse ?

Et bien c’est assez simple en réalité ! Imaginons que nous sommes dans notre réseau local, notre ordinateur va contacter son serveur DNS reçu en même temps que son adresse IP et sa gateway, pour par exemple résoudre le domaine notamax.be. Ce serveur DNS n’a (en général) pas la réponse, il va donc agir comme suit :

• Il va d’abord contacter les serveurs racines, mais comme ceux-ci ne ne sont pas responsables de ce domaine, ils vont le rediriger vers un autre serveur qui peut lui donner une information et qui dépend de la racine, le serveur DNS de be.
• Il demande ensuite au serveur DNS de be l’adresse IP de www.notamax.be, mais comme auparavant, le serveur be renvoie l’adresse IP du serveur DNS qui dépend de lui, le serveur DNS de notamax.be.
• Et enfin, il va demander au serveur DNS de notamax.be l’adresse IP de www.notamax.be et enfin on y est ! Le serveur de notamax.be connaît l’adresse IP du site web et peut donc la communiquer à notre ordinateur.

Concernant la résolution inverse, il faut savoir que de base, DNS n’a pas été conçu pour réaliser cela… L’un des problèmes liés à la requête inversée est la différence dans la façon dont l’espace de noms DNS organise et indexe les noms et la façon dont les adresses IP sont affectées.

Grossièrement, pour résoudre ce problème, un domaine spécial a été créé, c’est le fameux domaine in-addr.arpa, qui défini dans les normes DNS et réservé dans l’espace de noms Internet afin de fournir un moyen fiable et pratique d’effectuer des requêtes inversées. Pour arriver à créer l’espace de noms inversé, des sous-domaines dans le domaine in-addr.arpa sont créés à partir des différents blocs d’adresses IP existant, mais écrits de façon inverse.

Ce classement inversé des domaines est nécessaire car contrairement aux noms de domaine, lorsque des adresses IP sont lues de gauche à droite, elles sont lues de manière tout à fait opposée. Lorsqu’une adresse IP est lue de gauche à droite, les informations les plus générales (une adresse IP réseau) contenues dans la première partie de l’adresse sont vues en premier, puis ensuite seulement les informations les plus spécifiques (une adresse d’hôte) contenues dans les derniers octets.

Un rapide schéma pris du site de Marie Pascal Delamare sera peut être plus parlant !

Il est à noter qu’il faudra bien entendu créer un enregistrement supplémentaire dans la zone DNS, de type PTR pour Pointer Record, mais nous n’en parlerons pas beaucoup ici. La résolution inverse est surtout utilisée pour des raisons de sécurité (et, je dois l’avouer, est bien plus facile à mettre en place sur un serveur Windows qu’un serveur GNU/Linux !)

2) Configuration réseau et installation de Bind9

Bien, nous allons (enfin !) pouvoir rentrer dans le vif du sujet et démarrer notre serveur Debian fraîchement installé !

Pour installer bind9, rien de plus simple :

apt-get install bind9

Bien, la prochaine étape est donc de renseigner un FQDN dans notre fichier hostname (en éditant le fichier /etc/hostname, où notamax.local sera le nom du domaine) :

Et ensuite nous allons décrire le nom de domaine utilisé ainsi que l’adresse du serveur DNS dans le fichier /etc/resolv.conf, ici ce sera donc l’adresse IP de notre hôte lui-même :

Puis, nous devons éditer un dernier fichier, celui utilisé pour la résolution de noms locale, sans interroger un serveur DNS. Dans le fichier /etc/hosts, la ligne commençant par 127.0.0.1 doit donc être modifiée en ajoutant le nouveau nom FQDN du serveur suivi du nom du serveur. Il faut ensuite faire de même en ajoutant une ligne associant l’adresse IPv4 “publique” avec le FQDN.

Bien ! A ce stade nous sommes fin prêts pour commencer la configuration de Bind… sauf que, il faut encore faire un rapide rappel sur les différents types de serveur DNS. Et bien oui ! Notre serveur va-t-il faire du caching, de la réplication, ou bien encore autre chose ?

• Serveur maître : C’est le type “classique”. C’est lui qui va gérer les différents enregistrements DNS de notre zone.
• Serveur esclave : Il est utilisé en complément d’un serveur Maître, et va servir à répliquer les informations DNS de ce dernier. Il est toujours conseiller d’avoir un couple maître/esclave sur son réseau quand celui-ci commence à prendre de l’ampleur.
• Serveur de cache : Bind9 va réaliser les requêtes DNS, mais il va surtout se rappeler des réponses pour accélérer le temps de connexion à l’avenir et pour économiser de la bande passante.
• Serveur hybride : C’est un mot compliqué pour simplement dire que votre serveur est à la fois serveur de cache ET serveur esclave ou serveur maître.
• Serveur furtif : Nous n’en parlerons pas ici, mais ce type de serveur est identique aux serveurs maître ou esclave, à la différence qu’en mode furtif, votre serveur ne sera visible qu’à l’intérieur du domaine.
• Serveur récursif : Un serveur peut être récursif, c’est-à-dire qu’il va interroger tour à tour les serveurs DNS nécessaires jusqu’à obtenir la réponse. Mais dans le cas contraire (par défaut), le serveur DNS délègue la résolution du nom de domaine à un autre serveur DNS.

Bien ! Dans notre cas, nous allons nous contenter d’un serveur maître pour ce premier article, qui est déjà assez important avec ce lot de rappel et d’explications en tout genre ! :p

3) Configuration de Bind9 en tant que Maître

Bien, la première étape est de modifier le fichier /etc/bind/named.conf.local de Bind9 :

zone "notamax.local" IN {

type master;

file "/etc/bind/zone/db.notamax.local";

};

Ici nous déclarons que Bind9 est donc maître de la zone notamax.local, et que la zone correspondante à ce domaine se trouve dans le fichier /etc/bind/zone/db.notamax.local.

Ensuite, nous copions donc le fichier de zone “modèle” et nous le renommons pour être raccord avec le fichier de configuration ci-dessus.

mkdir /etc/bind/zone
cp /etc/bind/db.local /etc/bind/zone/db.notamax.local

Une fois fait, nous allons donc pouvoir réellement commencer à configurer notre zone DNS !

;
; BIND data file for local loopback interface
;

@TTL 604800
@	IN	SOA	srv-dns-01.notamax.local. anthony.notamax.be (
			2019081502	; Serial
			    604800	; Refresh
			     86400	; Retry
			   2419200	; Expire
			    604800 )	; Negative Cache TTL
;

@	IN	NS	srv-dns-01.notamax.local.
srv-dns-01	IN	A	192.168.2.100
client-dns	IN	A	192.168.2.10
pfsense-01	IN	A	192.168.2.1

Le champ SOA permet de décrire le serveur DNS ayant autorité sur la zone, ainsi que l’adresse électronique du contact technique (dont le caractère « @ » est remplacé par un point).

• Serial : Numéro de série (en général on y met la date courante suivie d’un numéro d’ordre, comme ceci: AAAAMMJJXX).
• Refresh : Temps de rafraîchissement, la valeur recommandée étant de 24 heures.
• Retry : Temps entre deux essais, la valeur recommandée ici est de 2 heures.
• Expire : Temps d’expiration, la valeur recommandée est de 1000 heures.
• Negative Cache TTL : Valeur TTL (Time to live) minimum, la valeur recommandée est de 2 jours.

Ensuite, nous déclarons donc le NameServer du domaine, puis les différentes entrées (ici ce sera notre client de test, ainsi que notre pfSense).

On peut déjà tester rapidement en tentant un ping depuis/vers notre serveur/client :

Bien, tout a l’air fonctionnel ! Nous verrons dans un second article comment créer une zone de recherche inverse (qui est plus ou moins semblable à une zone classique) ainsi que la création d’un serveur esclave ! 🙂