Projet

Général

Profil

Bind » Historique » Version 4

Version 3 (Fabien Dupont, 28/07/2012 11:56) → Version 4/25 (Fabien Dupont, 28/07/2012 17:27)

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

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.

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 transférer lors de mises à jour de la zone sur le primaire. zone.

h2. Configuration d'un serveur secondaire

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.

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 transfèrera 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>