ISC Bind9 – Serveur DNS primaire

ISC_DNS

Bind9 est une implémentation Open Source des protocoles DNS (Domain Name System) pour l’Internet, sous licence Mozilla Public License 2.0, née au début des années 80 et destinée principalement aux systèmes UNIX. Bind9 signifie Berkeley Internet Name Domain version 9 car le projet a été initié à l’Université de Californie à Berkeley (UCB). Ce projet est actuellement développé par l’Internet Systems Consortium (ISC) et la version 9 date de 2000.

 

Objectif

 

L’objectif de cet article est l’installation et la configuration d’un serveur DNS primaire, ou master, utilisant l’implémentation Bind9, sur une distribution Linux Debian Jessie 8.4 32bits.

 

Schéma logique

dns_animation2

 
Un client DNS consulte le serveur DNS, en UDP sur le port 53, pour obtenir l’adresse IP relative à un FQDN.
S’il dispose des droits et des outils pour cela, le client peut demander au serveur DNS un transfert de zones, en TCP sur le port 53, au serveur DNS afin d’obtenir l’ensemble des enregistrements des zones spécifiées.

 

Pré-requis

 

1. Pré-requis avant réalisation

  • Un serveur Debian Jessie 8.4 32 bits fonctionnel (installation basique avec utilitaires usuels du système et service SSH) qui hébergera le service DNS (et le service DHCP)
  • Packages de base supplémentaires : sudo, resolvconf, aptitude
  • Domaine utilisé : opensharing.priv

 

2. Configuration réseau initiale

Serveur DNS Master
FQDN dns1-test.opensharing.priv
Adresse IP 192.168.1.11
Réseau 192.168.1.0/24
Passerelle 192.168.1.1
dns-nameservers 8.8.8.8 8.8.4.4 127.0.0.1
dns-search opensharing.priv

 
Contenu initial du fichier /etc/network/interfaces :

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet static
	address 192.168.1.11
	netmask 255.255.255.0
	network 192.168.1.0
	broadcast 192.168.1.255
	gateway 192.168.1.1
	dns-search opensharing.priv
	dns-nameservers 8.8.8.8 8.8.4.4 127.0.0.1

 
Contenu initial du fichier /etc/hosts :

127.0.0.1	localhost.localdomain	localhost
192.168.1.11	dns1-test.opensharing.priv	dns1-test

Rmq : L’adresse 127.0.1.1 doit être retirée sur un serveur à IP fixe et remplacée par cette dernière, tel que l’exemple ci-dessus.
 
Contenu initial du fichier /etc/host.conf :

order hosts, bind
multi on

 
Contenu initial du fichier /etc/resolv.conf :

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 127.0.0.1
search opensharing.priv

Rmq :
Le fichier /etc/resolv.conf ne doit pas être édité dès lors que le paquet resolvconf a été installé.

Pour prendre en compte les modifications des fichiers de configuration relatifs au réseau, redémarrage du service réseau :

# /etc/init.d/networking restart

 

Réalisation

 

0. Mise à jour préalable du système et des paquets installés

# aptitude update
# aptitude upgrade

 

1. Installation des packages

# aptitude install bind9 bind9-doc

 

2. Configuration par défaut de Bind9

L’installation de de Bind9 a généré différents fichiers dans /etc/bind/:

-rw-r--r--   root root  bind.keys
-rw-r--r--   root root  db.0
-rw-r--r--   root root  db.127
-rw-r--r--   root root  db.255
-rw-r--r--   root root  db.empty
-rw-r--r--   root root  db.local
-rw-r--r--   root root  db.root
-rw-r--r--   root bind  named.conf
-rw-r--r--   root bind  named.conf.default-zones
-rw-r--r--   root bind  named.conf.local
-rw-r--r--   root bind  named.conf.options
-rw-r-----   bind bind  rndc.key
-rw-r--r--   root root  zones.rfc1918

La plupart de ces fichiers sont vides, ou presque, par défaut.
Le fichier principal est named.conf qui appelle, par inclusion, les fichiers named.conf.options, named.conf.local et named.conf.default-zones.

Contenu par défaut du fichier named.conf (hors commentaires) :

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

Contenu par défaut du fichier named.conf.options (hors commentaires) :

options {
	directory "/var/cache/bind";
};

Quelques options par défaut ont été retirées (dnssec-validation, auth-nxdomain, listen-on-v6) car elles ne seront pas utiles pour le moment.

Le fichier named.conf.local est vide (hors commentaires).
Les fichiers db.0, db.127, db.255, db.255, db.empty, db.local et db.root définissent les zones par défaut déclarées dans le fichier named.conf.default-zones. Ils ne nous intéresseront pas.

A titre informatif, le fichier db.root définit les serveurs DNS racines :

[...]
.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
A.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:BA3E::2:30

.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     192.228.79.201
[...]

Pour résumer, nous n’agirons que sur les fichiers named.conf.options et named.conf.local
bind9_tree
 

3. Définition des zones personnelles

Il s’agira ici, dans un premier temps, de créer deux zones :

  • La zone directe relative au domaine opensharing.priv : zone nommée opensharing.priv
  • La zone inverse relative à l’étendue d’IP allant de 192.168.1.1 à 192.168.1.254 : zone nommée 1.168.192.in-addr.arpa

Ces zones seront définies chacune dans un fichier individuel localisé dans /var/cache/bind/, respectivement :

  • db.opensharing.priv pour la zone opensharing.priv
  • db.opensharing.priv.inv pour la zone 1.168.192.in-addr.arpa

Puis ces zones seront déclarées dans le fichier named.conf.local centralisant l’ensemble des zones personnelles, soit directement, soit par inclusion.
Donc, tout d’abord, créons deux fichiers dans le répertoire /var/cache/bind/ correspondant à nos deux zones. Ce répertoire est déclaré dans le fichiers de configuration named.conf.options :

options {
	directory "/var/cache/bind";
};

 

3.1. Zone opensharing.priv

# nano /var/cache/bind/db.opensharing.priv

Saisissons une configuration minimale :

$ORIGIN opensharing.priv.
$TTL 86400
@               IN      SOA     dns1-test.opensharing.priv.     adminsys.opensharing.priv. (
                                2016060501      ; serial
                                21600           ; refresh 6h
                                3600            ; retry 1h
                                604800          ; expire 1 week
                                86400 )         ; minimum TTL 1 day

                IN      NS      dns1-test.opensharing.priv.

dns1-test       IN      A       192.168.1.11

dns1            IN      CNAME   dns1-test

La section Pour aller plus loin revient plus en détails sur les champs utilisés.

PAPL01
 

3.2. Zone 1.168.192.in-addr.arpa

# nano /var/cache/bind/db.opensharing.priv.inv

Saisissons une configuration minimale :

$ORIGIN 1.168.192.in-addr.arpa.
$TTL 86400
@		IN	SOA	dns1-test.opensharing.priv.	adminsys.opensharing.priv. (
				2016060501	; serial
				21600		; refresh 6h
				3600		; retry 1h
				604800		; expire 1 week
				86400 )		; minimum TTL 1 day
		IN	NS	dns1-test.opensharing.priv.
11		IN	PTR	dns1-test.opensharing.priv.
11		IN	PTR	dns1.opensharing.priv.

La section Pour aller plus loin revient plus en détails sur les champs utilisés.

PAPL02
 

4. Déclaration des zones personnelles

Comme nous l’avons vu précédemment, une fois les zones définies dans leurs fichiers respectifs, il faut déclarer celles-ci dans le fichier centralisateur named.conf.local, vide par défaut.

# nano /etc/bind/named.conf.local
zone "opensharing.priv" IN {
	type master;
	file "/var/cache/bind/db.opensharing.priv";
	allow-update { localhost; };
};

zone "1.168.192.in-addr.arpa" IN {
	type master;
	file "/var/cache/bind/db.opensharing.priv.inv";
	allow-update { localhost; };
};

Chaque zone, de résolution directe et de résolution inversée, est déclarée en précisant le fichier de définition correspondant.
Le serveur est de type master, ou primaire, pour ces deux zones et les mises à jour dynamiques des zones ne sont pas autorisées par défaut (hormis localhost).
 

4.1. Vérification de la syntaxe des fichiers de zones personnelles

La commande est de la forme suivante :

# named-checkzone zone-name zone-filename

 

# named-checkzone opensharing.priv db.opensharing.priv
zone opensharing.priv/IN: loaded serial 2016060501
OK
# named-checkzone 1.168.192.in-addr.arpa db.opensharing.priv.inv
zone 1.168.192.in-addr.arpa/IN: loaded serial 2016060501
OK

Comme on peut le voir, avec le retour affichant OK, la syntaxe des fichiers de zones est correcte.
 

4.2. Vérification de la résolution de noms

Pour cela, nous allons utiliser plusieurs commandes : ping, host, dig et nslookup

4.2.1. Résolution directe
# ping dns1
PING dns1-test.opensharing.priv (192.168.1.11) 56(84) bytes of data.
64 bytes from dns1-test.opensharing.priv (192.168.1.11): icmp_seq=1 ttl=64 time=0.015 ms
64 bytes from dns1-test.opensharing.priv (192.168.1.11): icmp_seq=2 ttl=64 time=0.047 ms
^C
--- dns1-test.opensharing.priv ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.015/0.031/0.047/0.016 ms
# host dns1
dns1.opensharing.priv is an alias for dns1-test.opensharing.priv.
dns1-test.opensharing.priv has address 192.168.1.11
# dig dns1.opensharing.priv
[...]
dns1.opensharing.priv.	86400	IN	CNAME	dns1-test.opensharing.priv.
dns1-test.opensharing.priv. 86400 IN	A	192.168.1.11
[...]
# nslookup dns1
Server:		127.0.0.1
Address:	127.0.0.1#53

dns1.opensharing.priv	canonical name = dns1-test.opensharing.priv.
Name:	dns1-test.opensharing.priv
Address: 192.168.1.11

4.2.2. Résolution inversée
# host 192.168.1.11
11.1.168.192.in-addr.arpa domain name pointer dns1.opensharing.priv.
11.1.168.192.in-addr.arpa domain name pointer dns1-test.opensharing.priv.
# dig -x 192.168.1.11
[...]
11.1.168.192.in-addr.arpa. 86400 IN	PTR	dns1-test.opensharing.priv.
11.1.168.192.in-addr.arpa. 86400 IN	PTR	dns1.opensharing.priv.
[...]
# nslookup 192.168.1.11
Server:		127.0.0.1
Address:	127.0.0.1#53

11.1.168.192.in-addr.arpa	name = dns1.opensharing.priv.
11.1.168.192.in-addr.arpa	name = dns1-test.opensharing.priv.

La résolution de noms est effective et le serveur DNS opérationnel. Toutefois cette configuration est basique, il est donc nécessaire d’aller plus loin, ce que propose la section suivante.
Nous pouvons retirer les serveurs DNS publics de Google, 8.8.8.8 et 8.8.4.4, de la configuration de l’interface eth0
Contenu final du fichier /etc/network/interfaces :

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet static
	address 192.168.1.11
	netmask 255.255.255.0
	network 192.168.1.0
	broadcast 192.168.1.255
	gateway 192.168.1.1
	dns-search opensharing.priv
	dns-nameservers 127.0.0.1

 

Pour aller plus loin

 

Transaction SIGnature

La TSIG est un protocole utilisé pour sécuriser les requêtes DNS et la communication serveur-à-serveur. Nous l’utiliserons pour authentifier et sécuriser les mises à jour dynamiques des enregistrements DNS par le service DHCP mais également le transfert de zones du serveur DNS primaire vers le serveur DNS secondaire. TSIG repose sur une clef secrète partagée symétrique et une fonction de hachage unidirectionnelle.

Nous allons procéder à la configuration TSIG afin de gagner du temps lors de la mise en place du service DHCP et de l’ajout d’un serveur DNS secondaire (slave).

TSIG
L’installation de Bind9 a généré une clef par défaut, stockée dans le fichier /etc/bind/rndc.key (droits 640 bind:bind) :

# cat /etc/bind/rndc.key
key "rndc-key" {
	algorithm hmac-md5;
	secret "SiJZkPFz6oOCuX3Br1N2fQ==";
};
On retrouve l’algorithme de hachage MD5 et la clef secrète par défaut. Mais nous allons générer une nouvelle clef secrète partagée que nous stockerons dans un nouveau fichier.

# cd /etc/bind/
# dnssec-keygen -a HMAC-MD5 -b 512 -n HOST tsig-key
Ktsig-key.+157+14670
  • Algorithme de hachage : HMAC-MD5 (157)
  • Longueur de la clef : 512 bits (le maximum en MD5)
  • Type de clef : HOST
  • Nom de la clef : tsig-key (peu importe le nom choisi)

Cette dernière commande génère deux fichiers :

-rw-------   root bind   Ktsig-key.+157+14670.private
-rw-------   root bind   Ktsig-key.+157+14670.key

Les deux fichiers générés sont du type :

Kname+algorithm+footprint.[private|key]

Ils contiennent respectivement la clef privée et la clef publique. Toutefois avec la fonction de hachage MD5 utilisée, ces deux clefs sont strictement identiques.

# cat Ktsig-key.+157+14670.private
Private-key-format: v1.3
Algorithm: 157 (HMAC_MD5)
Key: pzDEGpd36rKTJJChe/z9K/BFwZ3SQqPjtbD4mIAhRoIY5uYl9KXiV4wyllv85MbXAWsW6Qkjavld070MPdNq3A==
Bits: AAA=
Created: 20160605004310
Publish: 20160605004310
Activate: 20160605004310
# cat Ktsig-key.+157+14670.key
tsig-key. IN KEY 512 3 157 pzDEGpd36rKTJJChe/z9K/BFwZ3SQqPjtbD4mIAhRoIY5uYl9KXiV4wyllv85MbXAWsW6Qkjavld070MPdNq3A==

On crée enfin un fichier, toujours dans /etc/bind/, qui stockera la clef TSIG utilisée (pour la mise à jour dynamique et pour le transfert de zones) :

# nano tsig.key

Dans le lequel on ajoute notre clef, comme ceci :

key "tsig-key" {
	algorithm hmac-md5;
	secret "pzDEGpd36rKTJJChe/z9K/BFwZ3SQqPjtbD4mIAhRoIY5uYl9KXiV4wyllv85MbXAWsW6Qkjavld070MPdNq3A==";
};

On peut maintenant supprimer les fichiers TSIG précédemment générés :

# rm Ktsig-key.+157+14670.*

Et on attribue les bons droits au fichier tsig.key qui ne doit être lisible que par l’utilisateur bind (en dehors de root) :

# chown bind:bind tsig.key
# chmod 400 tsig.key

Ce fichier sera inclus dans les fichiers de configuration du service DNS par une directive d’inclusion, que ce soit pour le transfert de zones ou pour la mise à jour dynamique. Dans un premier temps, procédons à l’inclusion pour le futur transfert de zones :

# nano /etc/bind/named.conf

Ajoutons la directive d’inclusion en fin de fichier, de telle manière que :

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/tsig.key";

Nous avons créé une signature de transaction, mais elle n’est pour le moment pas intégrée aux zones personnelles. C’est ce que nous allons faire afin de sécuriser et authentifier les transactions DNS telles que la mise à jour dynamique des zones par le service DHCP et le transfert de zones vers le serveur DNS secondaire.

# nano /etc/bind/named.conf.local
zone "opensharing.priv" IN {
	type master;
	file "/var/cache/bind/db.opensharing.priv";
	allow-update { key "tsig-key"; };
	allow-transfer { key "tsig-key"; };
};

zone "1.168.192.in-addr.arpa" IN {
	type master;
	file "/var/cache/bind/db.opensharing.priv.inv";
        allow-update { key "tsig-key"; };
        allow-transfer { key "tsig-key"; };
};

Rechargeons le service Bind :

# /etc/init.d/bind9 reload

Simulons un transfert de zones sans utiliser la TSIG :

# dig @dns1.opensharing.priv opensharing.priv axfr

; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> @dns1.opensharing.priv opensharing.priv axfr
; (1 server found)
;; global options: +cmd
; Transfer failed.

Le transfert échoue car la TSIG est requise.
En effet, lorsque nous précisons le fichier contenant la TSIG :

# dig @dns1.opensharing.priv opensharing.priv axfr -k /etc/bind/tsig.key

; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> @dns1.opensharing.priv opensharing.priv axfr -k /etc/bind/tsig.key
; (1 server found)
;; global options: +cmd
opensharing.priv.	86400	IN	SOA	dns1-test.opensharing.priv. adminsys.opensharing.priv. 2016060501 21600 3600 604800 86400
opensharing.priv.	86400	IN	NS	dns1-test.opensharing.priv.
dns1.opensharing.priv.	86400	IN	CNAME	dns1-test.opensharing.priv.
dns1-test.opensharing.priv. 86400 IN	A	192.168.1.11
opensharing.priv.	86400	IN	SOA	dns1-test.opensharing.priv. adminsys.opensharing.priv. 2016060501 21600 3600 604800 86400
tsig-key.		0	ANY	TSIG	hmac-md5.sig-alg.reg.int. 1465224199 300 16 Q20FEvrOXgt3iLPoaTKN5g== 23706 NOERROR 0 
;; Query time: 0 msec
;; SERVER: 192.168.1.11#53(192.168.1.11)
;; WHEN: Mon Jun 06 16:43:19 CEST 2016
;; XFR size: 5 records (messages 1, bytes 252)

Le transfert de zone aboutit. Nous sommes donc prêt à installer un serveur DNS secondaire et à ajouter un service DHCP à notre serveur DNS maître.
 


 

Transfert de zones vers une IP autorisée

La procédure précédente nous a montré comment autoriser un transfert de zones où la clef TSIG authentifie le demandeur et valide l’autorisation de la requête.
Mais il est possible, comme alternative, d’autoriser le demandeur en fonction de son adresse IP.
Dans l’exemple ci-dessous, nous autorisons la requête de transfert uniquement depuis un serveur possédant l’adresse IP 192.168.1.12 qui correspondrait, par exemple, à un serveur DNS secondaire (slave).

zone "opensharing.priv" IN {
        type master;
        file "/var/cache/bind/db.opensharing.priv";
        allow-update { key "tsig-key"; };
        allow-transfer { localhost; 192.168.1.12; };
};

zone "1.168.192.in-addr.arpa" IN {
        type master;
        file "/var/cache/bind/db.opensharing.priv.inv";
        allow-update { key "tsig-key"; };
        allow-transfer { localhost; 192.168.1.12; };
};

Et si nous simulons une requête de transfert de zone avec la commande dig depuis un serveur d’IP 192.168.1.12, la requête aboutit sans avoir recours à la clef TSIG :

# dig @dns1.opensharing.priv opensharing.priv axfr
; <<>> DiG 9.9.5-9+deb8u5-Debian <<>> @dns1.opensharing.priv opensharing.priv axfr
; (1 server found)
;; global options: +cmd
opensharing.priv.	86400	IN	SOA	dns1-test.opensharing.priv. adminsys.opensharing.priv. 2016060501 21600 3600 604800 86400
opensharing.priv.	86400	IN	NS	dns1-test.opensharing.priv.
dns1.opensharing.priv.	86400	IN	CNAME	dns1-test.opensharing.priv.
dns1-test.opensharing.priv. 86400 IN	A	192.168.1.11
opensharing.priv.	86400	IN	SOA	dns1-test.opensharing.priv. adminsys.opensharing.priv. 2016060501 21600 3600 604800 86400
;; Query time: 1 msec
;; SERVER: 192.168.1.11#53(192.168.1.11)
;; WHEN: Tue Jun 07 16:38:57 CEST 2016
;; XFR size: 5 records (messages 1, bytes 174)

 


 

Transfert depuis une liste de contrôle d’accès

S’il est possible d’autoriser une adresse IP à l’origine de la demande de transfert de zones, il est également possible d’autoriser plusieurs adresses IP. D’après la méthode vue précédemment, on peut simplement ajouter des adresses IP séparées par des points-virgules, comme cela :

zone "opensharing.priv" IN {
	type master;
	file "/var/cache/bind/db.opensharing.priv";
	allow-update { key "tsig-key"; };
	allow-transfer { localhost; 192.168.1.19; 192.168.1.12; };
};

zone "1.168.192.in-addr.arpa" IN {
	type master;
	file "/var/cache/bind/db.opensharing.priv.inv";
        allow-update { key "tsig-key"; };
        allow-transfer { localhost; 192.168.1.19; 192.168.1.12; };

Mais il est également possible de grouper les IP autorisées en ACL :

acl "AUTHORIZED_SERVERS" {
	localhost; 192.168.1.12; 192.168.1.19;
};

zone "opensharing.priv" IN {
	type master;
	file "/var/cache/bind/db.opensharing.priv";
	allow-update { key "tsig-key"; };
	allow-transfer { "AUTHORIZED_SERVERS"; };
};

zone "1.168.192.in-addr.arpa" IN {
	type master;
	file "/var/cache/bind/db.opensharing.priv.inv";
        allow-update { key "tsig-key"; };
        allow-transfer { "AUTHORIZED_SERVERS"; };
};

Ou encore de conjuguer IP autorisées et IP non-autorisées (précédées d’un point d’exclamation afin de signifier la négation):

acl "AUTHORIZED_SERVERS" {
        localhost; !192.168.1.50; 192.168.1.0/24;
};


zone "opensharing.priv" IN {
        type master;
        file "/var/cache/bind/db.opensharing.priv";
        allow-update { key "tsig-key"; };
        allow-transfer { "AUTHORIZED_SERVERS"; };
};

zone "1.168.192.in-addr.arpa" IN {
        type master;
        file "/var/cache/bind/db.opensharing.priv.inv";
        allow-update { key "tsig-key"; };
        allow-transfer { "AUTHORIZED_SERVERS"; };
};

Ci-dessus, nous avons autorisé le transfert de zones aux IP 192.168.1.[1-254] sauf l’IP 192.168.1.50. Par contre, il est important de procéder à la négation d’une IP appartenant à un ensemble avant d’avoir listé cet ensemble. Par exemple, ici, nous devons restreindre l’IP 192.168.1.50 avant d’avoir autorisé l’ensemble 192.168.1.0/24 auquel elle appartient.
On pourrait d’ailleurs regrouper par ACL les IPs autorisées et les IPs non-autorisées :

acl "UNAUTHORIZED_SERVERS" {
        192.168.1.50;
};

acl "AUTHORIZED_SERVERS" {
        192.168.1.0/24;
};


zone "opensharing.priv" IN {
        type master;
        file "/var/cache/bind/db.opensharing.priv";
        allow-update { key "tsig-key"; };
        allow-transfer { localhost; !"UNAUTHORIZED_SERVERS"; "AUTHORIZED_SERVERS"; };
};

zone "1.168.192.in-addr.arpa" IN {
        type master;
        file "/var/cache/bind/db.opensharing.priv.inv";
        allow-update { key "tsig-key"; };
        allow-transfer { localhost; !"UNAUTHORIZED_SERVERS"; "AUTHORIZED_SERVERS"; };
};

 


 

Vérification de la syntaxe des fichiers de configuration

Pour vérifier la syntaxe des fichier de configuration, nous utiliserons la commande named-checkconf, comme ceci :

# named-checkconf /etc/bind/named.conf
# named-checkconf /etc/bind/named.conf.local 
# named-checkconf /etc/bind/named.conf.options 
#

A noter que la première commande suffit pour vérifier la syntaxe de l’ensemble des fichiers de configuration car named.conf.local et named.conf.options sont inclus dans named.conf. De plus, la commande named-checkconf contrôlera, par défaut, le fichier named.conf si elle n’est suivie d’aucun fichier en argument.

On constate que si le fichier de configuration ne présente aucune erreur de syntaxe alors la commande ne retourne rien.
Plus exactement, rien n’est affiché en retour, mais la valeur de retour est 0 :

# named-checkconf /etc/bind/named.conf
# echo $?
0
# named-checkconf /etc/bind/named.conf.local 
# echo $?
0
# named-checkconf /etc/bind/named.conf.options 
# echo $?
0

S’il y avait une erreur alors la commande afficherait une information de débogage et retournerait la valeur 1 :

# named-checkconf /etc/bind/named.conf.local
/etc/bind/named.conf.local:23: expected unquoted string near ';'
# echo $?
1

 


 
PAPL01

Explication des champs de fichiers de zones de résolution directe

Reprenons la définition de la zone opensharing.priv en lui ajoutant au passage quelques enregistrements :

$ORIGIN opensharing.priv.                                                                        1
$TTL 86400                                                                                       2
@		IN	SOA	dns1-test.opensharing.priv.	adminsys.opensharing.priv. (     3
				2016060501	; serial                                         4
				21600		; refresh 6h                                     5
				3600		; retry 1h                                       6
				604800		; expire 1 week                                  7
				86400 )		; minimum TTL 1 day                              8

		IN	NS	dns1-test.opensharing.priv.                                      9
		IN	NS	dns2-test.opensharing.priv.                                      10

		IN	MX	10	mail1-test.opensharing.priv.                             11
		IN	MX	20	mail2-test.opensharing.priv.                             12

                IN      A       192.168.1.14                                                     13
dns1-test	IN	A	192.168.1.11                                                     14
dns2-test	IN	A	192.168.1.12                                                     15

opsi-test	IN	A	192.168.1.13                                                     16
wp-test		IN	A	192.168.1.14                                                     17
mail1-test	IN	A	192.168.1.15                                                     18
mail2-test	IN	A	192.168.1.16                                                     19

dns1		IN	CNAME	dns1-test                                                        20
dns2		IN	CNAME	dns2-test                                                        21
dhcp1		IN	CNAME	dns1-test                                                        22
mail1		IN	CNAME	mail1-test                                                       23
mail2		IN	CNAME	mail2-test                                                       24
www		IN	CNAME	wp-test                                                          25
opsi		IN	CNAME	opsi-test                                                        26

1 $ORIGIN opensharing.priv.

Directive (identifiée par le $ initial) définissant le nom de la zone, c’est à dire le domaine, ici opensharing.priv.
Le « . » final de la zone est très important car il identifie le domaine comme le sommet de la zone et c’est une condition sine qua none.
Tout enregistrement sans point final sera complété par le nom du domaine, donc opensharing.priv sans point final sera complété et l’origine deviendra opensharing.priv.opensharing.priv et nous aurons l’erreur not at top of zone

Toutefois, comme la zone est déclarée dans le fichier /etc/bind/named.conf.local, cette directive pourrait potentiellement être omise, mais par souci de clarté je préfère la laisser.

2 $TTL 86400

Directive définissant le TTL, ou Time To Live. Cette valeur, en secondes, identifie la durée de validité des enregistrements qui suivent. Chaque enregistrement pourrait potentiellement avoir son propre TTL, écrasant le TTL précédemment défini. Si l’on augmente cette valeur, les serveurs de noms distants garderont les enregistrements en cache pour une durée plus longue, réduisant ainsi le nombre de requêtes pour cette zone mais augmentant le temps nécessaire à la prolifération des changements d’enregistrements de cette dernière.
Ici, 86400 secondes équivaut à 1 jour (3600 secondes x 24). Si cette directive est omise alors la valeur minimum-TTL définie dans le SOA sera utilisée.

Comme nous l’avons vu pour la directive d’origine, tout enregistrement ne possédant pas son propre TTL se verra affecter la valeur définie par la directive TTL. Le schéma suivant montre comment les directives d’origine et de TTL procèdent :


3 @ IN SOA dns1-test.opensharing.priv. adminsys.opensharing.priv. ([…])

Enregistrement de type SOA, ou Start Of Authority. C’est l’enregistrement fondamental définissant des informations importantes faisant autorité quant à une zone d’un serveur de noms.

Le « @ » initial remplace la valeur attribuée à l’origine ou le nom de la zone définie dans /etc/bind/named.conf.local/, c’est-à-dire opensharing.priv. On pourrait d’ailleurs écrire :
opensharing.priv. IN SOA dns1-test.opensharing.priv. adminsys.opensharing.priv. ([…])

Le IN qui suit fait référence à la classe de l’enregistrement, à savoir de type INternet. C’est généralement la seule classe que l’on retrouve. L’autre seule possibilité, mais rare, est la classe CH pour CHaos. Elle définit la version du serveur DNS. On pourrait omettre d’inscrire la classe IN car c’est la valeur par défaut, mais par souci de clarté je préfère la laisser.

La valeur dns1-test.opensharing.priv. définit le FQDN du serveur de noms primaire (master) faisant autorité pour ce domaine. Il doit correspondre à un enregistrement de type A (défini plus loin dans le fichier de zone) mais jamais à un CNAME (alias).

La valeur adminsys.opensharing.priv. fait référence à l’adresse mail de contact pour cette zone (Le @ de l’adresse mail est remplacé par un point).
On remarque à nouveau l’intervention du point final sur les FQDN, sinon ils se verraient ajouter le suffixe opensharing.priv., c’est à dire l’origine de la zone.

Cet enregistrement s’étale ici sur 6 lignes (les commentaires, commençant par un point virgule, sont ignorés), mais il serait possible de l’écrire sur une seule ligne :

@		IN	SOA	dns1-test	adminsys (2016060501 21600 3600 604800 86400 )

Si l’on retire le point final sur le hostname et le mail de contact, l’origine est automatiquement ajoutée.

4 2016060501 ; serial

Le serial-number est une valeur numérique que nous devons incrémenter à chaque fois que le fichier de zone est modifié. Il indique ainsi à Bind9 qu’il doit recharger le fichier de zone modifié. De même, un serveur de noms secondaire (slave) ayant un numéro de série inférieur pour cette zone saura qu’il doit requêter un transfert de zone pour mettre à jour sa propre base de données DNS.

Une convention veut que l’on définisse le numéro de série en utilisant la date au format AAAAMMJJVV, par exemple le 05/06/2016 donnera 20160605, valeur à laquelle on ajoute un numéro de version (VV), 01 pour une première modification. Ce qui donnera le numéro de série suivant : 2016060501
Si on modifie à nouveau le fichier de zone le même jour, il faudra incrémenter la version, soit un numéro de série 2016060502

5 21600 ; refresh 6h

Le time-to-refresh est une valeur numérique, en secondes, destinées aux serveurs de noms secondaires. Elle définit la fréquence à laquelle un serveur secondaire peut vérifier si le fichier de zone du serveur DNS master a été mis à jour. Ici, la valeur est de 21600 secondes, soit 6h. Toutes les 6h, les serveurs DNS slaves vérifient le numéro de série de la zone master et, si cette valeur est supérieure à la leur, ils demandent un transfert de zone et mettent à jour la base de données DNS pour cette zone.

6 3600 ; retry 1h

Le time-to-retry est une valeur numérique, en secondes, destinées aux serveurs de noms. Lorsqu’un serveur DNS slave tente de vérifier auprès du DNS master si des mises à jour pour la zone sont disponibles (voir valeur précédente, le time-to-refresh) mais que le master ne répond pas, le slave tentera à nouveau au bout du temps indiqué par le time-to-retry, ici 3600 secondes, soit 1h.

7 604800 ; expire 1 week

Le time-to-expire est une valeur numérique, en secondes, définissant le temps au bout duquel un serveur DNS slave cesse de faire autorité pour la zone s’il n’arrive pas à joindre le serveur DNS master avant ce temps imparti pour mettre à jour sa base de données DNS auprès de se dernier. Ici, cette valeur vaut 604800 secondes, soit 1 semaines. Au bout d’une semaine, si le slave, malgré des tentatives de refresh répétées (toutes les 6h ici), n’arrive pas à joindre le DNS master pour mettre à jour sa propre base de données, le slave ne fera plus autorité pour la zone.

8 86400 ) ; minimum TTL 1 day

Le minimum-TTL n’est plus utilisé pour définir le temps de rétention en cache des enregistrements de la zone sur les serveurs DNS distants. Pour cela, il faut se référer à la directive $TTL vue précédemment. Toutefois, si la directive $TTL n’est pas définie en début de fichier alors cette valeur sera utilisée.
La valeur ici représente maintenant le temps au bout duquel un serveur distant doit réitérer sa requête s’il reçoit une réponse négative du type NXDOMAIN ou NODATA lors de l’interrogation d’un enregistrement DNS pour cette zone.

9 IN NS dns1-test.opensharing.priv.

Cet enregistrement définit un serveur de noms (NS pour NameServer) faisant autorité pour la zone concernée. Il peut s’agir d’un serveur primaire ou secondaire. En l’occurrence, ici, il s’agit du serveur primaire, ou master, pour la zone. Le nom d’hôte renseigné doit de préférence être un FQDN.

10 IN NS dns2-test.opensharing.priv.

Idem que ci-dessus, mais il s’agit ici du serveur secondaire, ou slave, pour la zone.

11 IN MX 10 mail1-test.opensharing.priv.

Cet enregistrement définit le serveur de messagerie (MX pour Mail eXchange) pour cet espace de noms. Tout mail envoyé à XXXX@opensharing.priv transitera par le serveur de messagerie défini ici. Le nombre 10 signifie que ce serveur de messagerie est prioritaire sur d’éventuels autres serveurs MX possédant un indice supérieur. Plus l’indice est faible, plus la priorité est forte. Deux serveurs MX peuvent posséder la même priorité pour envoyer les mails de manière équitable. Le nom d’hôte renseigné doit de préférence être un FQDN.

12 IN MX 20 mail2-test.opensharing.priv.

Idem que ci-dessus mais ce serveur MX a une priorité inférieur au précédent car son indice est de 20.

13 IN A 192.168.1.14

Cet enregistrement de type A (A pour Address) attribue une adresse IPv4 à un nom d’hôte. Lorsque le nom d’hôte est omis, ce qui est le cas ici, l’IP pointe sur le sommet de l’espace de noms, à savoir le domaine opensharing.priv
Un ping sur opensharing.priv renvoit l’IP 192.168.1.14

14 dns1-test IN A 192.168.1.11

Enregistrement de type A attribuant l’adresse IPv4 192.168.1.11 au nom d’hôte (complété par la directive origine) dns1-test.opensharing.priv

15 dns2-test IN A 192.168.1.12

Enregistrement de type A, l’hôte dns2-test.opensharing.priv possède l’IPv4 192.168.1.12

16 opsi-test IN A 192.168.1.13

Enregistrement de type A, l’hôte opsi-test.opensharing.priv possède l’IPv4 192.168.1.13

17 wp-test IN A 192.168.1.14

Enregistrement de type A, l’hôte wp-test.opensharing.priv possède l’IPv4 192.168.1.14

18 mail1-test IN A 192.168.1.15

Enregistrement de type A, l’hôte mail1-test.opensharing.priv possède l’IPv4 192.168.1.15

19 mail2-test IN A 192.168.1.16

Enregistrement de type A, l’hôte mail2-test.opensharing.priv possède l’IPv4 192.168.1.16

20 dns1 IN CNAME dns1-test

Enregistrement de type CNAME (CNAME pour Canonical NAME) définissant un alias. Ici dns1.opensharing.priv est un alias de dns1-test.opensharing.priv
Un ping sur dns1.opensharing.priv pointera sur dns1-test.opensharing.priv et renverra l’IPv4 192.168.1.11

21 dns2 IN CNAME dns2-test

Ici dns2.opensharing.priv est un alias de dns2-test.opensharing.priv
Un ping sur dns2.opensharing.priv pointera sur dns2-test.opensharing.priv et renverra l’IPv4 192.168.1.12

22 dhcp1 IN CNAME dns1-test

Ici dhcp1.opensharing.priv est un alias de dns1-test.opensharing.priv
Un ping sur dhcp1.opensharing.priv pointera sur dns1-test.opensharing.priv et renverra l’IPv4 192.168.1.11

23 mail1 IN CNAME mail1-test

Ici mail1.opensharing.priv est un alias de mail1-test.opensharing.priv
Un ping sur mail1.opensharing.priv pointera sur mail1-test.opensharing.priv et renverra l’IPv4 192.168.1.15

24 mail2 IN CNAME mail2-test

Ici mail2.opensharing.priv est un alias de mail2-test.opensharing.priv
Un ping sur mail2.opensharing.priv pointera sur mail2-test.opensharing.priv et renverra l’IPv4 192.168.1.16

25 www IN CNAME wp-test

Ici www.opensharing.priv est un alias de wp-test.opensharing.priv
Un ping sur www.opensharing.priv pointera sur wp-test.opensharing.priv et renverra l’IPv4 192.168.1.14

26 opsi IN CNAME opsi-test

Ici opsi.opensharing.priv est un alias de opsi-test.opensharing.priv
Un ping sur opsi.opensharing.priv pointera sur opsi-test.opensharing.priv et renverra l’IPv4 192.168.1.13
 


 
PAPL02

Explication des champs de fichiers de zones de résolution 0inversée

Reprenons la définition de la zone 1.168.192.in-addr.arpa en lui ajoutant au passage quelques enregistrements :

$ORIGIN 1.168.192.in-addr.arpa.
$TTL 86400
@		IN	SOA	dns1-test.opensharing.priv.	adminsys.opensharing.priv. (
				2016060501	; serial
				21600		; refresh 6h
				3600		; retry 1h
				604800		; expire 1 week
				86400 )		; minimum TTL 1 day
		IN	NS	dns1-test.opensharing.priv.
		IN	NS	dns2-test.opensharing.priv.
11		IN	PTR	dns1-test.opensharing.priv.
12		IN	PTR	dns2-test.opensharing.priv.
11		IN	PTR	dhcp1.opensharing.priv.
11		IN	PTR	dns1.opensharing.priv.
12		IN	PTR	dns2.opensharing.priv.

13		IN	PTR	opsi.opensharing.priv.

14		IN	PTR	www.opensharing.priv.

15		IN	PTR	mail1.opensharing.priv.
16		IN	PTR	mail2.opensharing.priv.

Ici les champs sont globalement les même que pour la zone de résolution directe donc il est inule de revenir dessus. Mais il existe quelques différences tout de même. La principale est la présence d’un type d’enregistrement appelé PTR (pour Pointer)
Ce dernier type d’enregistrement permet de faire pointer une IP vers un FQDN.

Nous pouvons le tester avec la commande dig :

# dig -x 192.168.1.11
[...]
11.1.168.192.in-addr.arpa. 86400 IN	PTR	dns1-test.opensharing.priv.
11.1.168.192.in-addr.arpa. 86400 IN	PTR	dns1.opensharing.priv.
11.1.168.192.in-addr.arpa. 86400 IN	PTR	dhcp1.opensharing.priv.
[...]

Ou bien nslookup :

# nslookup 192.168.1.11
Server:		127.0.0.1
Address:	127.0.0.1#53

11.1.168.192.in-addr.arpa	name = dhcp1.opensharing.priv.
11.1.168.192.in-addr.arpa	name = dns1-test.opensharing.priv.
11.1.168.192.in-addr.arpa	name = dns1.opensharing.priv.

Ou bien encore host :

# host 192.168.1.11
11.1.168.192.in-addr.arpa domain name pointer dns1-test.opensharing.priv.
11.1.168.192.in-addr.arpa domain name pointer dhcp1.opensharing.priv.
11.1.168.192.in-addr.arpa domain name pointer dns1.opensharing.priv.

 


 

Aller encore plus loin

Pour continuer à explorer la configuration de Bind9, voir les articles suivants :

 

Annexes

PAPLxx : fait référence à un sujet développé dans la section Pour aller plus loin

 

Références

 

 

Fermer le menu
%d blogueurs aiment cette page :