Bind (Berkeley Internet Name Domain) is a popular DNS server. It can be used to host a master zone or simply as a DNS cache.

Install the package :

• bind9

Configuration files are located into /etc/bind/.

To make the operating system use bind localy, change /etc/resolv.conf to :

nameserver 127.0.0.1

By default bind is configured as a DNS proxy, requesting directly the DNS root servers. This configuration is independent of provider's DNS.

Default configuration inside named.conf.default-zones :

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

It is also possible to forward requests to another DNS server.

Configuration example to add into named.conf.local :

zone "." {
        type forward;
        forward only;
        forwarders { 192.168.10.10; } ;
};

Configuration example to forward only one domain :

zone "thisdomain.com" {
        type forward;
        forward only;
        forwarders { 10.0.10.11; 10.0.10.12; } ;
};

It is one of the main function or Bind : create a public or private zone.
This task is done in two steps :

1. Creating a zone file
2. Enabling this zone

The following example show the configuration of bouthors.fr.

The file below is the zone file for bouthors.fr, saved into db.bouthors.fr :

$ORIGIN .
$TTL 300        ; 5 minutes
bouthors.fr             IN SOA  dc1.bouthors.fr. matthieu.bouthors.fr. (
                                1110210001 ; serial
                                604800      ; refresh (1 week)
                                86400       ; retry (1 day)
                                2419200     ; expire (4 weeks)
                                300         ; minimum (5 minutes)
                                )
                        NS      dc1.bouthors.fr.
                        A       88.174.63.25
                        MX      10 mail.bouthors.fr.
$ORIGIN bouthors.fr.
matthieu                CNAME   www
www                     A       88.174.63.25
mail                    CNAME   ghs.google.com.
dc1                     A       88.174.63.25

A zone file is composed by several records of different types (SOA, NS, A, MX, …). In details :

• $ORIGIN defines the suffix for the following lines
• $TTL defines the caching duration for the following lines
• SOA (Start of Authority) is mandatory, it starts the zone definition :
  • dc1.bouthors.fr is the autoritative server of the zone (Primary Master)
  • matthieu.bouthors.fr is the admin email with a ”.” instead of ”@”
  • 20111021001 is the serial number, which allow to do versioning. This number should be increased at each modification.
  • the following values are the expiration length (seconds) :
    • refresh, retry and expire are used for secondary servers synchronization
    • minimum (300) is important, it defines the cache duration for negative answers
• A records define an IP resolution. For example www.bouthors.fr will be resolve by 88.174.63.25
• CNAME records define redirections to other records
• NS records define DNS servers
• MX records define mail relays of the domain (nom@bouthors.fr). If several records are used, lower weighted will be selected first. If they have the same weight, load sharing will be used.

A noter que les enregistrement textes sont relatifs à la zone par défaut, il faut ajouter un ”.” à la fin pour indiquer qu'il s'agit de noms absolus.

Ensuite, il faut renseigner la zone dans Bind, pour cela la modification de /etc/bind/named.conf.local est le moyen le plus propre :

zone "bouthors.fr" {
        type master;
        file "/etc/bind/db.bouthors.fr";
};

Pour appliquer les modifications, il faut redémarrer bind :

/etc/init.d/bind9 restart

La configuration d'une sous-zone est assez proche d'une zone racine, les étapes sont :

1. la création du fichier de zone
2. la déclaration de la zone dans le serveur dns
3. la modification de la zone supérieure ainsi :
   1. ajouter les serveurs DNS de la sous zone en tant qu'enregistrement de type NS
   2. si besoin ajouter des glue records

Voici un exemple de création de la sous zone ddns.bouthors.fr qui est dédiée pour les enregistrements dynamiques.

Le fichier de zone :

$ORIGIN .
$TTL 300        ; 5 minutes
ddns.bouthors.fr       IN SOA  dc1.bouthors.fr. matthieu.bouthors.fr. (
                                2011102303  ; serial
                                3600        ; refresh (1H)
                                1200        ; retry (20m)
                                2419200     ; expire (4 weeks)
                                180         ; minimum (3 minutes)
                                )
                        NS      dc1.bouthors.fr.

La déclaration de la zone dans named.conf.local :

zone "ddns.bouthors.fr" {
        type master;
        file "/etc/bind/db.ddns.bouthors.fr";
};

La déclaration de la sous zone dans la zone parent :

$ORIGIN .
$TTL 300        ; 5 minutes
bouthors.fr             IN SOA  dc1.bouthors.fr. matthieu.bouthors.fr. (
                                1110210001 ; serial
                                604800      ; refresh (1 week)
                                86400       ; retry (1 day)
                                2419200     ; expire (4 weeks)
                                300         ; minimum (5 minutes)
                                )
                        NS      dc1.bouthors.fr.
ddns.bouthors.fr.       NS      dc1.bouthors.fr.

Si les serveurs dns font partie de la sous zone (par exemple on indique que ddns.bouthors.fr est résolution par dc1.ddns.bouthors.fr) alors cela génère une boucle puisque dc1.ddns.bouthors.fr ne peut être résolu qu'en joignant le dns de ddns.bouthors.fr. C'est alors qu'interviennent les glue records : il suffit d'ajouter la résolution de dc1.ddns.bouthors.fr dans la zone parent. Par exemple :

dc1.ddns.bouthors.fr.       NS      192.168.10.2

Pour ajouter votre propre résolution, il faut à nouveau créer un fichier de zone inverse, par exemple db.192.168 :

$ORIGIN .
$TTL 60 ; 1 minute
168.192.in-addr.arpa    IN SOA  dc1.bouthors.fr. matthieu.bouthors.fr. (
                                1110210001 ; serial
                                604800     ; refresh (1 week)
                                86400      ; retry (1 day)
                                2419200    ; expire (4 weeks)
                                60         ; minimum (1 minute)
                                )
                        NS      dc1.bouthors.fr.
$ORIGIN 10.168.192.in-addr.arpa.
1                       PTR     rt1.bouthors.fr.
2                       PTR     dc1.bouthors.fr.

Ensuite on ajouter la zone à named.conf.local :

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

Le principe du serveur secondaire est de se synchroniser sur le primaire afin d'avoir un serveur de secours. Il est notamment obligatoire pour tout domaine publique.
Lorsqu'il y a une modification du primaire, celui-ci notifie les secondaires, la zone est transférée et stockée dans un fichier temporaire.
Le serial est utiliser pour identifier la révision du fichier, il est important de l'incrémenté à chaque modification.

Par défaut le primaire autorise tous les transferts et notifie automatiquement les serveurs définis par les enregistrements NS.
Il est cependant possible de configurer manuellement ces éléments, voici un exemple :

zone "bouthors.fr" {
        type master;
        file "/etc/bind/db.bouthors.fr";
        allow-transfer {192.168.10.3;};
        also-notify {192.168.10.3;};
};

La déclaration d'une zone slave sur le deuxième serveur est également relativement simple :

zone "bouthors.fr" {
        type slave;
        file "/var/cache/bind/db.bouthors.fr";
        masters {192.168.10.2;};
};

Il faut choisir un répertoire modifiable et définir l'ip du primaire.

Les mises à jour dynamiques (également appelées Dynamic DNS ou DDNS) permettent de modifier dynamiquement les enregistrements.
Cela permet par exemple de disposer de valeurs à jour pour les équipements en DHCP.

La mise à jour peut être réalisée par le client DHCP ou par le serveur DHCP. Le serveur DHCP a l'avantage de surveiller les baux DHCP et peut ainsi nettoyer le serveur DNS lors de leur expiration.

Très important : lorsqu'une zone accepte les mises à jour, un fichier journal est créé pour temporiser l'écriture de la zone, il n'est plus possible de modifier le fichier de zone directement.
Il faut utiliser une des options suivantes :

• utiliser la commande nsupdate pour réaliser une mise à jour dynamique manuellement
• bloquer temporairement le mode dynmique
• stopper temporairement le serveur DNS

Avant d'activer la mise à jour dynamique, vérifier que bind a le droit d'écrire dans /etc/bind pour la création des journaux :

chown bind /etc/bind

Ajouter les autorisations d'update sur la zone concernée avec allow-update :

zone "ddns.bouthors.fr" {
        type master;
        file "/etc/bind/db.ddns.bouthors.fr";
        allow-update { 192.168.10.2;192.168.10.3;};
};

Après redémarrage de bind, nous pouvons tester la mise à jour avec nsupdate :

# nsupdate
> server 192.168.10.2
> zone ddns.bouthors.fr
> update add test.ddns.bouthors.fr. 300 IN A 192.168.10.150
> send
> quit

# nslookup test.ddns.bouthors.fr
Server:         192.168.10.2
Address:        192.168.10.2#53

Name:   test.ddns.bouthors.fr
Address: 192.168.1.111
Name:   test.ddns.bouthors.fr
Address: 192.168.10.150

#

Pour bloquer la mise à jour dynamique afin de modifier le fichier de zone, il faut utiliser “rndc freeze zone” et “rndc unfreeze zone”, par exemple :

# rndc freeze ddns.bouthors.fr
# vi /etc/bind/db.ddns.bouthors.fr
# rndc unfreeze ddns.bouthors.fr
A zone reload and thaw was started.
Check the logs to see the result.
# 

Il est très fortement conseillé de sécuriser les mises à jours avec TSIG car il est très facile de forger les requêtes DNS.

Il est possible de sécuriser les échanges entre serveurs (update, transfert) avec TSIG.
Les étapes sont :

1. générer une clef
2. configurer cette clef sur les deux serveurs

La génération de la clef se fait avec la commande dnssec-keygen (remplacer dc1-dc2 par les noms de vos serveurs) :

dnssec-keygen -a hmac-md5 -b 128 -n HOST dc1-dc2

Sous VMWare le résultat n'arrive pas rapidement (cf bug https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/650721), le plus simple est de générer de l'activité disque par exemple avec “find /”).

Deux fichiers sont alors créés avec les extensions .key et .private, nous allons uniquement utiliser la clef présente à la ligne “Key:” dans le fichier .private :

Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: 0jnu3SdsMvzzlmTDPYRceA==
Bits: AAA=

Il faut ensuite déclarer cette clef sur les deux serveurs, par exemple sur le master :

key dc1-dc2 {
  algorithm hmac-md5;
  secret "0jnu3SdsMvzzlmTDPYRceA==";
};

server 192.168.10.3 {
  keys {dc1-dc2;};
};

zone "bouthors.fr" {
        type master;
        file "/etc/bind/db.bouthors.fr";
        allow-transfer { key dc1-dc2 ;};
        also-notify {192.168.10.3;};
        allow-update { key dc1-dc2 ;};
};

Sur le slave :

key dc1-dc2 {
  algorithm hmac-md5;
  secret "0jnu3SdsMvzzlmTDPYRceA==";
};

server 192.168.10.2 {
  keys {dc1-dc2;};
};

Enfin, il est conseillé de sécuriser la configuration en supprimant les fichiers .key et .private et en supprimant l'accès à named.conf.local :

chmod o-r named.conf.local

Communiquer via IPv6 et fournir des réponses IPv6 sont deux problématiques distinctes. Nous traitons ici de la résolution des noms DNS par des adresses IPv6.

L'annonce d'adresses IPv6 dans le DNS est très simple, il suffit d'ajouter des enregistrements de type AAAA dans la zone. Exemple :

 web3                    AAAA    2001:470:c981::24

Il est également possible de paramétrer une zone de résolution inverse.
Attention à bien respecter la notation reverse, chaque caractère hexadécimal est séparé par un point. Exemples :

• 2001:470:c981:: ⇒ 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.8.9.c.0.7.4.0.1.0.0.2.ip6.arpa.
• 2001:470:c981::24 ⇒ 4.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.8.9.c.0.7.4.0.1.0.0.2.ip6.arpa.

Pour effectuer la transformation, utiliser la commande dig :

dig -x 2001:470:c981::24

...
;; QUESTION SECTION:
;4.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.8.9.c.0.7.4.0.1.0.0.2.ip6.arpa. IN PTR
...

Dans l'exemple suivant, nous allons créer une zone reserve pour le réseau 2001:470:c981::/48

Il faut tout d'abord créer un nouveau fichier de zone /etc/bind/db.2001_470_c981 :

$ORIGIN .
$TTL 60 ; 1 minute
1.8.9.c.0.7.4.0.1.0.0.2.ip6.arpa.  IN SOA  dc1.bouthors.fr. matthieu.bouthors.fr. (
                                2011102301 ; serial
                                604800     ; refresh (1 week)
                                86400      ; retry (1 day)
                                2419200    ; expire (4 weeks)
                                60         ; minimum (1 minute)
                                )
                        NS      dc1.bouthors.fr.
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.8.9.c.0.7.4.0.1.0.0.2.ip6.arpa.
2.0                     PTR     dc1.bouthors.fr.
3.0                     PTR     dc2.bouthors.fr.

Puis ajouter la nouvelle zone à named.conf.local :

zone "1.8.9.c.0.7.4.0.1.0.0.2.ip6.arpa" {
        type master;
        file "/etc/bind/db.2001_470_c981";
        allow-transfer { key dc1-dc2;};
        also-notify {192.168.10.3;};
};

Remarque : la zone reverse IPv6 étant généralement publique, elle peut être synchronisée et annoncée comme les zones forward.

Look at reseau

• /etc/bind/*

• http://www.isc.org/software/bind
• http://www.freeos.com/articles/3956/
• http://doc.ubuntu-fr.org/bind9
• http://www.zytrax.com/books/dns/ch7/xfer.html
• http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.ch04.html
• http://www.cyberciti.biz/faq/unix-linux-bind-named-configuring-tsig/