ISC Bind9 – Serveur DNS primaire

# 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

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
 

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 :

• ISC Bind9 – Serveur DNS secondaire
• ISC Bind9 – Configuration avancée
• ISC Bind9 – Commandes utiles

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