h1. Installation et configuration de bind

{{>toc}}

h2. Principe général

Un serveur de nom *primaire* pour une zone est un serveur hébergeant la zone déclarée en type « *master* » et étant déclaré en tant que « NS » pour cette zone.

Un serveur de nom *secondaire* pour une zone est un serveur hébergeant la zone déclarée en type « *slave* » et étant déclaré en tant que « NS » pour cette zone.

Du point de vue du client DNS, celui qui interroge le serveur pour résoudre un nom, il n'y a pas de notion de primaire ou secondaire. Tous les serveurs déclarés sur une zone seront interrogés tour à tout avec du round-robin pour répartir la charge.

<pre>
temps primaire secondaire
| | |
| [modification d'une zone] |
| | |
| |-----notificaiton---->|
| | NOTIFY |
| | |
| |<---téléchargement----|
| | AXFR/IXFR |
| | |
| | |
| | |
| | [expiration du TTL]
| | |
| |<---téléchargement----|
| | AXFR/IXFR |
| | |
v v v
</pre>

Le serveur secondaire télécharge la zone depuis le primaire dans deux cas :

* La zone a été modifiée sur le primaire. Celui-ci notifie alors le secondaire de la présence d'une nouvelle version de la zone. Le secondaire initie le téléchargement par une requête AXFR (transfert de la zone complète) ou IXFR (transfert incrémental).
* Le TTL (Time To Live) expire sur le serveur secondaire. Celui-ci récupère une version fraîche de la zone depuis le primaire (idem, AXFR ou IXFR).

Il est possible de forcer l'envoi d'une notification depuis le primaire afin de mettre à jour les zones sur tous les secondaires configurés. Cela est utile dans le cas où le(s) secondaire(s) étaient inaccessibles au moment de la mise à jour d'une zone. Cela permet de ne pas avoir à attendre l'expiration du TTL sur les secondaires.

Dans le cas d'un transfert incrémental (IXFR), le serveur secondaire indique au primaire le numéro de série de la zone qu'il connaît et le serveur primaire retourne uniquement les différences avec la zone active.

h2. Installation de bind « chrooté »

h3. Installation

Debian stable (actuellement squeeze) n'est pas très à jour niveau mise à jour de sécurité de bind. Personnellement, je préfère installer la version « testing » (wheezy) dans un environnement « chrooté ».

<pre>
# aptitude -t wheezy install bind
</pre>

h3. Création de l'environnement chrooté

<pre>
# mkdir -p /var/bind9/chroot/{etc,dev,var/named/pri,var/named/sec,var/run/named}
# mknod /var/bind9/chroot/dev/null c 1 3
# mknod /var/bind9/chroot/dev/random c 1 8
# chmod 660 /var/bind9/chroot/dev/{null,random}
# mv /etc/bind /var/bind9/chroot/etc/bind
# ln -sv /var/bind9/chroot/etc/bind /etc/bind
# chown -R bind:bind /var/bind9/chroot/etc/bind
# chmod 775 /var/bind9/chroot/var/{named/pri,named/sec,run/named}
# chgrp bind /var/bind9/chroot/var/{named/pri,named/sec,run/named}
</pre>

h3. Configuration des scripts de démarrage de bind et de rsyslog

<pre>
# sed -i -e 's/^OPTIONS=.*$/OPTIONS="-u bind -t \/var\/bind9\/chroot"/' /etc/default/bind9
# sed -i -e 's/^PIDFILE=.*$/PIDFILE=\/var\/bind9\/chroot\/var\/run\/named\/named.pid/' /etc/init.d/bind9
# echo "\$addUnixListenSocket /var/bind9/chroot/dev/log" > /etc/rsyslog.d/bind9-chrooted.conf
</pre>

h3. Configuration de bind

/etc/bind/named.conf : Fichier de configuration lu par le daemon au démarrage. Il est préférable de séparer la configuration par « activité ».

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

/etc/bind/named.conf.options : Options du daemon.

<pre>
options {
directory "/var/named";

// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113

// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.

// forwarders {
// 0.0.0.0;
// };

auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
transfer-source { 80.67.176.156; };
transfer-source-v6 { 2001:910:109c:2::53; };
};

controls {
inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; };
};

include "/etc/bind/rndc.key";
</pre>

Les paramètres transfer-source et transfer-source-v6 permette de définir l'adresse IP source utilisée lors de transferts de zones depuis le primaire vers le secondaire.
Par défaut, bind utilise l'interface qui a l'adresse IP la plus « proche » de celle du serveur secondaire (même subnet, en gros).
Ce paramètre est très utile dans le cas où un serveur primaire dispose de plusieurs interface réseau.

/etc/bind/named.conf.local : zones des reverses RFC1918. Le fichier /etc/bind/zones.rfc1918 est fourni par debian.

<pre>
//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
include "/etc/bind/zones.rfc1918";
</pre>

/etc/bind/named.conf.default-zones : zones par « défaut » (serveurs root, localhost, reverse 127.0.0.0/8), fichiers fournis par debian.

<pre>
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
type master;
file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
</pre>

/etc/bind/named.conf.zones : Définition des zones primaires ou secondaires (voir plus loin) hébergées par le serveur.

<pre>
zone "kafe-in.net" IN {
type slave;
file "sec/kafe-in.net.zone";
allow-notify { 2001:910:109c:2::53/128; };
masters { 2001:910:109c:2::53/128; };
};

zone "k-f.in" IN {
type master;
file "pri/k-f.in.zone";
allow-transfer { 2001:910:109c:2::53/128; };
};
</pre>

Pour que les modifications soient prises en compte, il faut redémarrer rsyslog et bind9.

<pre>
# /etc/init.d/rsyslog restart
# /etc/init.d/bind9 restart
</pre>

h2. Configuration d'un serveur primaire

Example pour la zone k-f.in :

<pre>
# cat /var/bind9/chroot/var/named/k-f.in.zone
$TTL 864000
@ IN SOA dns2.kafe-in.net. fab.kafe-in.net. (
2012061701 ; serial
3600 ; refresh
900 ; retry
1209600 ; expire
43200 ; default_ttl
)

@ IN NS dns.kafe-in.net.
@ IN NS dns2.kafe-in.net.

@ 28800 IN MX 10 mail.kafe-in.net.
@ 28800 IN MX 20 mail2.kafe-in.net.

28800 IN A 91.224.149.142
28800 IN AAAA 2a01:6600:8081:8e00::fab

; FDN
roussane 28800 IN A 80.67.176.156
roussane 28800 IN AAAA 2001:910:109c:1::2

; Tetaneutral
muscat 28800 IN A 91.224.149.142
muscat 28800 IN AAAA 2a01:6600:8081:8e00::fab

; Services
www 28800 IN CNAME muscat
</pre>

Le serveur primaire est dns.kafe-in.net (80.67.176.156 et 2001:910:109c:2::53). Ce n'est pas forcément le premier « NS » défini qui est primaire. C'est celui qui héberge la zone avec un type « master » et qui est défini en « SOA » (« Start of Authority »).

Le zone k-f.in doit donc être déclarée de la façon suivante dans le fichier named.conf.zones du serveur primaire :

<pre>
zone "k-f.in" IN {
type master;
file "pri/k-f.in.zone";
allow-transfer { 2a01:6600:8081:8e00::fab/128; };
};
</pre>

La zone k-f.in est de type « master » (serveur primaire) et seul le serveur secondaire 2a01:6600:8081:8e00::fab/128 est autorisé à la demander lors de mises à jour de la zone sur le primaire.

h2. Configuration d'un serveur secondaire

La même zone k-f.in doit donc être déclarée de la façon suivante dans le fichier named.conf.zones du serveur secondaire :

<pre>
zone "k-f.in" IN {
type slave;
file "sec/k-f.in.zone";
allow-notify { 2001:910:109c:2::53/128; };
masters { 2001:910:109c:2::53/128; };

};
</pre>

La zone est de type « slave » (serveur secondaire) et seul le serveur primaire 2001:910:109c:2::53/128 est autorisé à notifier le serveur secondaire de la présence de modifications. Le serveur secondaire téléchargera la zone mise à jour sur le serveur 2001:910:109c:2::53/128 (ici le même, mais pas forcément).

h2. Gestion des logs

Par défaut, bind envoie tous les logs de l'application « en vrac » dans /dev/log. Charge au daemon syslog de les ranger comme on veut. Le problème est qu'il est très difficile de configurer un daemon syslog pour séparer ces logs en catégories afin de faciliter la résolution de problèmes.

Pour rediriger une catégorie de log, il faut d'abord définir un canal (channel) ayant pour destination un fichier puis il faut rediriger une categorie (category) dans ce canal.

Voilà un exemple de configuration séparant chaque catégorie de log dans des fichiers différents :

<pre>
# Configuration des logs
logging {
channel default_file { file "/var/log/named/default.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel general_file { file "/var/log/named/general.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel database_file { file "/var/log/named/database.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel security_file { file "/var/log/named/security.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel config_file { file "/var/log/named/config.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel resolver_file { file "/var/log/named/resolver.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel xfer-in_file { file "/var/log/named/xfer-in.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel xfer-out_file { file "/var/log/named/xfer-out.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel notify_file { file "/var/log/named/notify.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel client_file { file "/var/log/named/client.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel unmatched_file { file "/var/log/named/unmatched.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel queries_file { file "/var/log/named/queries.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel network_file { file "/var/log/named/network.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel update_file { file "/var/log/named/update.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel dispatch_file { file "/var/log/named/dispatch.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel dnssec_file { file "/var/log/named/dnssec.log" versions 3 size 5m; severity dynamic; print-time yes; };
channel lame-servers_file { file "/var/log/named/lame-servers.log" versions 3 size 5m; severity dynamic; print-time yes; };

category default { default_file; };
category general { general_file; };
category database { database_file; };
category security { security_file; };
category config { config_file; };
category resolver { resolver_file; };
category xfer-in { xfer-in_file; };
category xfer-out { xfer-out_file; };
category notify { notify_file; };
category client { client_file; };
category unmatched { unmatched_file; };
category queries { queries_file; };
category network { network_file; };
category update { update_file; };
category dispatch { dispatch_file; };
category dnssec { dnssec_file; };
category lame-servers { lame-servers_file; };
};
</pre>

h2. Gestion des zones

h3. Forcer le transfert d'une zone depuis un serveur secondaire :

Le transfert d'une zone est généralement déclenché par le serveur primaire (envoi d'un NOTIFY à chaque modification du serial). Mais il est possible de forcer un téléchargement de la zone depuis le serveur secondaire avec la commande « rndc retransfert nom-de-la.zone ».

Sur le secondaire :

<pre>
# rndc retransfer kafe-in.net
# tail /var/log/daemon.log
Jul 28 11:31:14 muscat named[22111]: received control channel command 'retransfer kafe-in.net'
Jul 28 11:31:14 muscat named[22111]: zone kafe-in.net/IN: Transfer started.
Jul 28 11:31:14 muscat named[22111]: transfer of 'kafe-in.net/IN' from 2001:910:109c:2::53#53: connected using 2a01:6600:8081:8e00::fab#46243
Jul 28 11:31:14 muscat named[22111]: zone kafe-in.net/IN: transferred serial 2012072701
Jul 28 11:31:14 muscat named[22111]: transfer of 'kafe-in.net/IN' from 2001:910:109c:2::53#53: Transfer completed: 1 messages, 30 records, 749 bytes, 0.105 secs (7133 bytes/sec)
Jul 28 11:31:14 muscat named[22111]: zone kafe-in.net/IN: sending notifies (serial 2012072701)
</pre>

Sur le primaire :

<pre>
Jul 28 11:31:14 ve-jail named[288]: client 2a01:6600:8081:8e00::fab#46243: view wan: transfer of 'kafe-in.net/IN': AXFR started
Jul 28 11:31:14 ve-jail named[288]: client 2a01:6600:8081:8e00::fab#46243: view wan: transfer of 'kafe-in.net/IN': AXFR ended
</pre>

h3. Forcer la notification d'une zone

Parfois, surtout pendant la mise en place des serveurs, il faut « forcer » le primaire à notifier les secondaires sur une zone particulière afin qu'ils la téléchargent. Cela se fait avec la commande « rndc notify nom-de-la.zone ».

Sur le primaire :

<pre>
# rndc -k rndc.key notify kafe-in.net
zone notify queued
# tail /var/log/daemon.log
Jul 28 11:39:36 ve-jail named[288]: zone kafe-in.net/IN: sending notifies (serial 2012072701)
</pre>

Sur le secondaire :
<pre>
Jul 28 11:39:36 muscat named[22111]: client 2001:910:109c:2::53#41892: received notify for zone 'kafe-in.net'
Jul 28 11:39:36 muscat named[22111]: zone kafe-in.net/IN: notify from 2001:910:109c:2::53#41892: zone is up to date
</pre>

h3. Délégation d'une reverse

Historiquement, le protocole DNS ne permet pas la délégation de reverses (association IP->nom) pour des préfixes « classless » (autres que /8, /16 et /24). Toutefois, le "RFC 2317":http://www.ietf.org/rfc/rfc2317.txt décrit une astuce permettant cela.

Le principe est plutôt simple : on définit un CNAME pour le reverse en question et il est parfaitement légitime de déléguer la résolution d'un CNAME à un autre NS. Le tour est joué.

Pour l'exemple, disons que tetaneutral.net délègue 91.224.149.142 à dns.kafe-in.net. La convention de nommage du CNAME est « dernier_digit IN CNAME dernier_digit/netmask ».

Ainsi pour déléguer 91.224.149.142/32 dans la zone 149.224.91.in-addr.arpa. :
<pre>
142/32 IN NS dns.kafe-in.net.
142 IN CNAME 142/32.149.224.91.in-addr.arpa.
</pre>

Sur le serveur DNS de l'adhérent il suffit alors d'héberger une zone 142/32.149.224.91.in-addr.arpa. et d'y positionner le PTR désiré pour son IP.

Dans named.conf :
<pre>
zone "142/32.149.224.91.in-addr.arpa" IN {
type master;
file "wan/142-32.149.224.91.in-addr.arpa.zone";
};
</pre>

Et dans 142-32.149.224.91.in-addr.arpa.zone :
<pre>
$ORIGIN .
$TTL 864000
142/32.149.224.91.in-addr.arpa IN SOA dns.kafe-in.net. fab.kafe-in.net. (
2012071201 ; serial
3600 ; refresh
900 ; retry
1209600 ; expire
43200 ; default_ttl
)

$ORIGIN 142/32.149.224.91.in-addr.arpa.
IN NS dns.kafe-in.net.
142 IN PTR muscat.kafe-in.net.
</pre>

Lors d'une résolution, cela done :
<pre>
# dig +trace -x 91.224.149.142

; <<>> DiG 9.8.1-P1 <<>> +trace -x 91.224.149.142
;; global options: +cmd
. 136994 IN NS b.root-servers.net.
. 136994 IN NS k.root-servers.net.
. 136994 IN NS a.root-servers.net.
. 136994 IN NS l.root-servers.net.
. 136994 IN NS g.root-servers.net.
. 136994 IN NS f.root-servers.net.
. 136994 IN NS m.root-servers.net.
. 136994 IN NS i.root-servers.net.
. 136994 IN NS c.root-servers.net.
. 136994 IN NS d.root-servers.net.
. 136994 IN NS e.root-servers.net.
. 136994 IN NS h.root-servers.net.
. 136994 IN NS j.root-servers.net.
;; Received 512 bytes from 91.224.149.254#53(91.224.149.254) in 25 ms

in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa.
;; Received 432 bytes from 128.63.2.53#53(128.63.2.53) in 131 ms

n-addr.arpa. 86400 IN NS ns3.nic.fr.
91.in-addr.arpa. 86400 IN NS pri.authdns.ripe.net.
91.in-addr.arpa. 86400 IN NS sec1.apnic.net.
91.in-addr.arpa. 86400 IN NS sec3.apnic.net.
91.in-addr.arpa. 86400 IN NS sns-pb.isc.org.
91.in-addr.arpa. 86400 IN NS tinnie.arin.net.
;; Received 201 bytes from 196.216.169.10#53(196.216.169.10) in 209 ms

149.224.91.in-addr.arpa. 172800 IN NS ns2.tetaneutral.net.
149.224.91.in-addr.arpa. 172800 IN NS ns1.tetaneutral.net.
;; Received 96 bytes from 2001:660:3006:1::1:1#53(2001:660:3006:1::1:1) in 17 ms

142.149.224.91.in-addr.arpa. 86400 IN CNAME 142.142/149.224.91.in-addr.arpa.
142/32.149.224.91.in-addr.arpa. 86400 IN NS dns.kafe-in.net.
;; Received 213 bytes from 2a01:6600:8000::3#53(2a01:6600:8000::3) in 14 ms

# dig -x 91.224.149.142

; <<>> DiG 9.8.1-P1 <<>> -x 91.224.149.142
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7168
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;142.149.224.91.in-addr.arpa. IN PTR

;; ANSWER SECTION:
142.149.224.91.in-addr.arpa. 86359 IN CNAME 142.142/32.224.91.in-addr.arpa.
142.142/32.224.91.in-addr.arpa. 172795 IN PTR muscat.kafe-in.net.

;; AUTHORITY SECTION:
142.142/32.224.91.in-addr.arpa. 172795 IN NS dns.kafe-in.net.

;; ADDITIONAL SECTION:
dns.kafe-in.net. 6732 IN A 80.67.176.156

;; Query time: 1 msec
;; SERVER: 91.224.149.254#53(91.224.149.254)
;; WHEN: Sat Aug 4 09:48:12 2012
;; MSG SIZE rcvd: 229
</pre>