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
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
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.
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.
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.
<p »>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).
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==";
};
<p »>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
- IETF – RFC1034 – Domain Names – Concepts and Facilities
- IETF – RFC1035 – Domain Names – Implementation and Specification
- Internet Systems Consortium – ISC BIND Homepage
- ISC Bind9 – Administrator Reference Manual
- Zytrax – Bind9 – List of Statements
- Red Hat Enterprise Linux 3: Reference Guide – Chapter 12. Berkeley Internet Name Domain (BIND)
- Ubuntu-fr – Bind9
- APNIC – Guide to reverse zones
- RHEL5 – Deployment Guide – Zone File Resource Records
- RHEL5 – Deployment Guide – Reverse Name Resolution Zone Files
- Référence Debian – Chapitre 5. Configuration du réseau
- Red Hat Enterprise Linux Deployment Guide – Zone Files
- Répartition géographique des root servers à travers le monde
- AFNIC – Gestion des TLD
</p »></p »>
