DNS : installer un serveur Bind sous Linux

Module Progression
0% Terminé

I. Présentation

Pour mettre en place une architecture DNS, il faut d’abord imaginer l’architecture que l’on souhaite créer. Imaginons une architecture avec un serveur DNS maître et un serveur DNS esclave (pour secourir le premier et faire éventuellement de l’équilibrage de charge). On pourrait représenter notre plateforme (pour la zone mydmn.org), de la sorte :

Pour l’exercice, je vous propose de configurer la plateforme avec une distribution CentOS 7 sur l’ensemble des serveurs et des clients.

On notera que dans l’exemple ci-dessus on n’a choisi que des clients de façon indifférente. Mais, il pourrait s’agir de serveurs applicatifs, d’imprimantes réseau, de postes de travail… Autant d’équipements pouvant s’interconnecter au réseau d’entreprise.

REMARQUE : afin de rester au plus simple, on effectuera la configuration sur le serveur DNS maître, et ensuite sur celui de l’esclave. On pratiquera alors des vérifications pour s’assurer que le paramétrage est correct et opérationnel.

II. Mettre en place le serveur DNS master

A. Installer les paquets Bind

La première étape consiste à réaliser l'installation de BIND sur le DNS maître : 192.168.0.172. Il faut donc installer l’ensemble des packages bind* sur le serveur maître :

# yum install –y bind*

Les packages à installer sur une Debian sont bind9 (serveur BIND), bind9-host (client BIND) et bind9utils (outils DNS). De plus, le fichier de configuration named.conf se trouve dans le répertoire /etc/bind (au lieu de /var/named pour les distributions CentOS), où l’on peut également déclarer les fichiers de zones.

On dispose désormais d’un ensemble de fichiers de configuration que l’on va modifier au fur et à mesure :

  • /etc/named.conf
  • Répertoire /var/named
  • Fichier de zones /etc/named.rfc1912.zones
  • Fichier de clé /etc/named.root.key

 

B. Configuration de Bind

Les paquets étant installés, nous pouvons configurer les options de BIND sur le DNS maître (192.168.0.172).

Le fichier /etc/named.conf contient principalement les options de notre serveur DNS maître. Il faut préciser quelle(s) adresse(s) va (ou vont) être autorisé et suivie(s). On doit alors ajouter l’adresse de notre serveur DNS primaire :

options {
        listen-on port 53 { 192.168.1.172; localhost; };

On peut laisser les mentions du répertoire et des fichiers de cache et de statistiques (sauf si l’on souhaite changer leur emplacement) :

        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";

On peut ensuite préciser que l’on souhaite utiliser le mode récursif lorsque des requêtes sont émises et autoriser les réseaux ou zones sur lesquelles on peut envoyer ces requêtes en cas de réponse vide :

        recursion yes;
        allow-query     { 192.168.1.0/24; 127.0.0.1/8; localhost; };

Ensuite, si l’on envisage (c’est notre cas), de transférer les requêtes circulant vers un serveur secondaire, on peut le déclarer de la manière suivante :

        allow-transfer { 192.168.1.173; localhost; };

En dernier lieu, si l’on connaît d’autres autorités DNS, on peut également leur transférer les requêtes provenant des clients en déclarant la ligne suivante :

        forwarders { 12.27.2.102; 13.27.2.102; };

Le reste peut être conservé à l’identique du fichier d’origine. Bien évidemment, la dernière ligne n’est absolument pas nécessaire si l’on souhaite rester en circuit fermé. Mais, dans le cas où l’on souhaite aussi interroger les serveurs DNS 12.27.2.102 et 13.27.2.102, alors il faut ajouter cette option.

C. Création des fichiers de zones

On va maintenant créer les deux fichiers de zones : l’un pour la résolution standard et l’autre pour la résolution inverse, le tout pour notre domaine "mydmn.org". Dans le répertoire /var/named on va devoir créer les deux fichiers suivants :

  • /var/named/named.mydmn.org
  • /var/named/named .1.168.192.in-addr.arpa

On pourrait les nommer autrement. Mais, l’avantage de donner le nom du domaine et la zone inverse d’adresse, c’est de permettre, lorsque l’on a plusieurs dizaines ou plusieurs centaines de domaines à gérer, de s’y retrouver.

ASTUCE : si l’on ne veut pas partir d’un fichier vierge et devoir improviser, on peut copier le fichier named.localhost en named.mydmn.org. Cela évite au moins la déclaration des paramètres SOA. Mais, il faudra tout de même changer le nom de domaine et le champ serial. Ce dernier servira pour la copie de la base locale vers le serveur esclave.

On devra donc déclarer les lignes suivantes, dans le fichier named.mydmn.org :

$TTL 3600

@ IN SOA masterdns.mydmn.org. root.mydmn.org. (
        20170423         ; serial
        10800              ; refresh
        3600                ; retry
        604800             ; expire
        86400              ; minimum
)

@  IN          NS     masterdns.mydmn.org.
@  IN          NS     slavedns.mydmn.org.
@  IN          A           192.168.1.150
@  IN          A           192.168.1.151
@  IN          A           192.168.1.152
@  IN          A           192.168.1.153

Si l’on veut aller jusqu’au bout de la déclaration, on peut également ajouter les lignes déclaratives littérales (sans utiliser le caractère de substitution @, qui substitue le nom complet du domaine) :

masterdns                   IN          A      192.168.1.172
slavedns                    IN          A     192.168.1.173
client1                     IN          A     192.168.1.150
client2                     IN          A     192.168.1.151
client3                     IN          A     192.168.1.152
client4                     IN          A     192.168.1.153

Pour le fichier de zone reverse, on peut également prendre celui appelé named.loopback et le copier en named.1.168.192.in-addr-arpa. On peut ensuite y déclarer les lignes suivantes :

$TTL 86400

@       IN SOA  masterdns.mydmn.org. root.mydmn.org. (
                                20170423 ; serial
                                    3600 ; refresh
                                    1800 ; retry
                                  604800 ; expire
                                   86400 ; minimum
)
@               IN      NS      masterdns.mydmn.org.
@               IN      NS      slavedns.mydmn.org.
@               IN      PTR     mydmn.org.
masterdns       IN      A       192.168.1.172
slavedns        IN      A       192.168.1.173
client1         IN      A       192.168.1.150
client2         IN      A       192.168.1.151
client3         IN      A       192.168.1.152
client4         IN      A       192.168.1.153
172             IN      PTR     masterdns.mydmn.org.
173             IN      PTR     slavedns.mydmn.org.
150             IN      PTR     client1.mydmn.org.
151             IN      PTR     client2.mydmn.org.
152             IN      PTR     client3.mydmn.org.
153             IN      PTR     client4.mydmn.org.

ATTENTION : normalement un utilisateur named et un groupe sont créés pour la gestion des zones et des enregistrements DNS. Mais, si les fichiers que l’on vient de créer utilisent le compte ou le groupe root, il faut changer cela. Dans l’idéal, les fichiers devraient avoir les propriétés suivantes :

-rw-r--r--   1 named named 2035 Mar 27 13:39 named.1.168.192.in-addr.arpa
-rw-r-----   1 named named 1892 Feb 18  2008 named.ca
-rw-r--r--   1 named named 4167 Mar 27 13:38 named.mydmn.org
-rw-r-----   1 named named  152 Dec 15  2009 named.empty
-rw-r-----   1 named named  152 Jun 21  2007 named.localhost
-rw-r-----   1 named named  168 Dec 15  2009 named.loopback

D. Déclaration des zones

Pour finir, on peut déclarer les zones à utiliser directement dans le fichier /etc/named.rfc1912.zones en l’éditant et lui ajoutant les lignes suivantes :

…
zone "mydmn.org" {
        type master;
        file "named.mydmn.org";
        notify yes;
        allow-transfer { 192.168.1.173; };
        allow-update { key rndc.key; };
};

zone "1.168.192.in-addr.arpa" {
        type master;
        file "named.1.168.192.in-addr.arpa";
        notify yes;
        allow-transfer { 192.168.1.173; };
        allow-update { key rndc.key; };
};

E. Vérification de la configuration

Avant de lancer le service et de commencer à utiliser notre serveur DNS, il convient de s’assurer que l’on n’a rien oublié et que le paramétrage ne contient aucune erreur :

# named-checkconf /etc/named.conf

Si tout se passe bien, on ne devrait pas avoir de message d’erreur. Sinon, il faut scruter les journaux de logs et voir ce qui ne va pas.

Ensuite, on peut passer à la vérification de la configuration, zone par zone, en exécutant les commandes suivantes :

# named-checkzone mydmn.org /var/named/named.mydmn.org
zone mydmn.org/IN: loaded serial 20170423
OK

# named-checkzone 1.168.192.in-addr.arpa /var/named/1.168.192.in-addr.arpa
Zone 0.168.192.in-addr.arpa/IN: loaded serial 20170423
OK

Lorsqu’il y a une erreur, généralement le texte en est suffisamment explicite pour corriger et relancer les commandes de vérifications, jusqu’à ce qu’il n’y ait plus aucun problème. On peut alors démarrer le service DNS et le rendre automatique lors des redémarrages du système :

# service named start
# chkconfig named on

ATTENTION : si l’on a activé le service de pare-feu local, via les tables netfilter, il faut alors autoriser le flux TCP/53 et UDP/53 et redémarrer le service iptables:

iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT
iptables -A INPUT -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT

Il existe les règles équivalentes pour SystemD. La seule différence c’est qu’il faut bien sûr intégrer ce genre de règles dans la zone public du pare-feu. En effet, SystemD fonctionne via des zones :

  • drop
  • block
  • public
  • external
  • internal
  • dmz
  • work
  • home
  • trusted

Le plus simple étant d’intégrer ces règles de façon permanente via l’option --permanent :

# firewall-cmd --zone=public --permanent --add-service=dns
# firewall-cmd --reload

III. Configuration du serveur DNS esclave

On peut ensuite configurer le serveur DNS esclave. En règle générale, on peut reprendre le même paramétrage que pour le serveur maître à quelques exceptions près. En commençant par le fichier /etc/named.conf :

options {
        listen-on port 53 { 127.0.0.1; 192.168.1.173; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        recursion yes;
        allow-query     { 192.168.1.0/24;  localhost; };
        forwarders { 12.27.2.102; 13.27.2.102; };

Pour le reste, on peut recopier les fichiers de configuration se trouvant dans le répertoire /var/named et démarrer le service DNS :

# service named start
# chkconfig named on

REMARQUE : en réalité, on n’a même pas besoin de créer les fichiers de zones, ceux-ci sont résolus par le service DNS du serveur maître. Mais, pour que ce mécanisme de synchronisation fonctionne, il est essentiel que le n° de série (serial) des fichiers de zones soient les mêmes et que dans le fichier /etc/named.rfc1912.zones on ait bien déclaré la ligne du cache  ci-dessous, pour chacune des zones à gérer :

        allow-update { key rndc.key; };

IV. Déployer les serveurs DNS sur les postes clients

Lorsque les deux serveurs sont opérationnels, il faut alors mettre à jour le fichier /etc/resolv.conf des clients, en renseignant les lignes suivantes:

search mydmn.org
nameserver 192.168.1.172
nameserver 192.168.1.173

Il faut également modifier le fichier /etc/sysconfig/network afin de renseigner le champ HOSTNAME du client avec son nom FQDN. Toutefois, si le fichier contient la ligne suivante :

HOSTNAME=localhost.localdomain

Les différents champs seront interprétés et remplacés par leur valeur contextuelle. Par exemple, sur la machine client1, la valeur interprétée avec la commande d’interrogation hostname, sera : client1.mydmn.org :

#hostname
client1.mydmn.org

Les principaux outils d’interrogation d’un serveur DNS sont nslookup (il s’agit d’un des plus anciens clients d’interrogation) et dig (outil beaucoup plus récent). On les détaillera dans le troisième module.

Exemple : interrogation avec nslookup :

# nslookup client1
Server:         192.168.1.172
Address:        192.168.1.172#53
Name:   client1.mydmn.org
Address: 192.168.1.150

Félicitations le service DNS est en place ! Dans le chapitre suivant, nous verrons comment sécuriser nos serveurs DNS, en plusieurs étapes.

Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Partager sur Google+ Envoyer par mail

Philippe PIERRE

A exercé de nombreuses années en tant qu'administrateur de base de données et comme administrateur Système Unix/Linux. Il a enseigné les réseaux au CNAM (Paris). Aujourd'hui, employé en tant qu'ingénieur infrastructure, au sein d'un laboratoire pharmaceutique et administrant un cluster de calculs HPC, il connaît parfaitement les environnements GNU/Linux dans le cadre d'une entreprise et des systèmes de haute disponibilité. Il aime partager son expérience.

philippe-pierre a publié 69 articlesVoir toutes les publications de cet auteur