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 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>