Ceci est une ancienne révision du document !



Serveur DNS : PowerDNS

Cet article a pour but de vous présenter comment installer et configurer un serveur DNS en utilisant l'application powerDNS.

PowerDNs est un serveur de nom qui peut utiliser une base de données (mysql ou postgresql) comme stockage des informations de noms. Ceci a deux avantages très importants :

  • Qui dit "bases de données", dit "administration facilitée par une interface web".
  • En cas de crash système, et pour peu que vous ayez logé votre serveur de bases de données sur un point de montage séparé, vous ne perdrez pas vos données si vous réinstallez complètement votre système.
L'auteur a par exemple logé tous ses serveurs logiciels dans /home : apache, mysql, serveur de courriel dont les boîtes aux lettres sont dans le répertoire de chaque utilisateur…
  • Vous devez maitriser les bases de TCP/IP.
  • Vous devez avoir une connexion internet (ou intranet si vous voulez juste adresser votre lan sans connexion au reste du monde).

Pour installer PowerDNS sur Ubuntu, installez les paquets apt://pdns,pdns-recursor

Considérons les aspects suivants :

  • Le réseau local est 192.168.251.* et se nomme bureau.lan.
  • La machine serveur DNS est aussi le serveur de mail et porte l'IP 192.168.251.202; elle se nomme mail2.
  • Il y a 3 autres machines sur le réseau : 192.168.251.200 (nommée twin1), 192.168.251.201 (nommée twin2) et 192.168.251.205 (nommée portable).

Remarque : L'utilisation du TLD (Top Level Domain) fictif .lan est voulue. En effet, n'utilisez pas un TLD existant comme .com ou .ca sans en être le propriétaire.

Voyons comment configurer le serveur BIND avec ce petit réseau.

Configuration de base du serveur

Le fichier de configuration générale

La configuration principale de BIND se fait dans le fichier /etc/bind/named.conf.

Si vous voulez ajouter vos propres zones, il faut le faire dans le fichier /etc/bind/named.conf.local

Dans ce fichier, on définit un certain nombre de zones. Une zone correspond soit à une plage IP d'un réseau ou à un nom de domaine. Les deux zones qui nous intéressent ici sont 192.168.251.* et bureau.lan.

On définit deux zones pour avoir la résolution de nom dans les deux sens. C'est-à-dire que l'on peut obtenir une adresse IP à partir d'un nom d'hôte mais également, que l'on peut obtenir un nom d'hôte à partir d'une adresse IP.

Une zone avec un nom de domaine se définit comme ceci :

zone "bureau.lan" {
        type master;
        file "/etc/bind/db.bureau.lan";
};
Attention à ne pas oublier le ; à la fin …

On indique tout d'abord le nom de la zone que l'on connaît avec le mot clé zone suivi du nom de domaine (dans notre cas, "bureau.lan". On indique que c'est le DNS maître (en effet, on peut avoir un ou des DNS de backups qui sont aussi appelés des DNS secondaires) en indiquant type master. Et enfin, on indique dans quel fichier se trouve les informations de résolution concernant cette zone. En général, on place ces fichiers dans /etc/bind/ et on préfixe le nom de la zone par db..

Nous définissons également la zone de plage IP pour la résolution inverse. Pour se faire, nous utilisons les mêmes paramètres. Cependant, le nom de la zone s'écrit avec la plage réseau inversée suivi de .in-addr.arpa. L'entrée de zone pour notre réseau 192.168.251.* s'écrit comme ceci :

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

Nous en avons fini avec le fichier de configuration générale. Voyons maintenant comment définir les noms des machines présentes dans une zone.

Les fichiers zones

Comme vous vous en doutez, nous avons un fichier par zone. Les fichiers zones contiennent toutes les entrées comme une table de traduction pour les noms des machines d'une même zone.

Un fichier zone commence toujours par un champ SOA, ce champ SOA se compose comme suit :

$TTL 3h
@       IN      SOA     ns.bureau.lan. hostmaster.bureau.lan. (
                                2005090201
                                8H
                                2H
                                1W
                                1D )

Le symbole @ désigne la zone décrite par le fichier de configuration (ici, bureau.lan). A la place de @, vous auriez très bien pu indiquez bureau.lan. (n'oubliez pas le "." à la fin !!!).

Ensuite, on indique IN qui signifie que l'on a affaire à une zone Internet; c'est pour ainsi dire toujours le cas (sauf quelques très rares exceptions). Enfin, toujours sur la première ligne, on indique le serveur DNS qui dispose du fichier zone de référence (important lorsque que l'on a des DNS secondaires) et l'adresse email de la personne responsable de la zone (le premier "." dans le champ d'email est considéré comme un "@").

Dans notre cas, le serveur DNS primaire de la zone est ns.bureau.lan et l'adresse email de la personne responsable est hostmaster@bureau.lan.

Remarque : Vous avez sans doute noté que le serveur DNS et l'adresse email sont ponctuées par un point ("."). Ce point est indispensable. Si vous l'omettez, par défaut, BIND rajoute le nom de la zone et dès lors ns.bureau.lan. renvoie ns.bureau.lan alors que ns.bureau.lan (sans point) renvoie ns.bureau.lan.bureau.lan. Il s'agit d'une erreur très fréquente.

Les valeurs qui suivent sont respectivement :

  • le numéro de série (souvent on met la date courante suivie d'un numéro d'ordre); AAAAMMJJxx.
  • le temps de rafraichissement (refresh; ici, 8 heures); la valeur recommandée est de 24 heures.
  • le temps entre deux essais (retry; ici, 2 heures); la valeur recommandée est de 2 heures.
  • le temps d'expiration (expire; ici, 1 semaine); la valeur recommandée est de 1000 heures.
  • la valeur TTL minimum (minimum; ici, 1 jour); la valeur recommandée est de 2 jours.

En utilisant les valeurs que j'ai stipulées ci-dessus, tout devrait fonctionner. Pour plus d'informations, je vous renvoie à Google.

Après le champ SOA, on indique le serveur de nom à consulter pour résoudre un nom d'hôte dans le domaine bureau.lan. Nous faisons ça avec un champ NS de la manière suivante :

@       IN      NS      ns.bureau.lan.

Ensuite (ceci est facultatif), si vous avez un serveur de mail, vous pouvez indiquer au serveur DNS que les adresses de la forme *@bureau.lan sont gérées par un serveur de mail prédéfini; nous le faisons comme ceci :

@       IN      MX      10      mail2.bureau.lan.

Remarque : La valeur 10 indique la priorité du serveur concerné. En indiquant plusieurs champs MX avec des valeurs différentes, vous pouvez indiquer des serveurs de mail secondaires.

Enfin, nous terminons ce fichier zone avec la table de traduction des hôtes en adresse IP :

ns              A       192.168.251.202
mail2           A       192.168.251.202
twin1           A       192.168.251.200
twin2           A       192.168.251.201
portable        A       192.168.251.205

Le fichier zone complet pour bureau.lan ressemble à ceci :

$TTL 3h
@       IN      SOA     ns.bureau.lan. hostmaster.bureau.lan. (
                                2005090201
                                8H
                                2H
                                1W
                                1D )

@       IN      NS      ns.bureau.lan.

@       IN      MX      10      mail2.bureau.lan.


ns              A       192.168.251.202
mail2           A       192.168.251.202
twin1           A       192.168.251.200
twin2           A       192.168.251.201
portable        A       192.168.251.205

Avant de pouvoir utiliser notre serveur DNS, nous allons renseigner la zone pour la plage IP de notre réseau. La zone se décrit vaguement comme la précédente, à la différence près que l'on utilise le mot clé PTR au lieu de A dans la table de traduction.

Voici le fichier zone pour notre réseau 192.168.251.* d'exemple :

$TTL 3h
@       IN      SOA     ns.bureau.lan. hostmaster.bureau.lan. (
                                2005090201
                                8H
                                2H
                                1W
                                1D )

@       IN      NS      ns.bureau.lan.

@       IN      MX      10      mail2.bureau.lan.

$ORIGIN 251.168.192.in-addr.arpa.
202     IN      PTR     ns.bureau.lan.
202     IN      PTR     mail2.bureau.lan.
200     IN      PTR     twin1.bureau.lan.
201     IN      PTR     twin2.bureau.lan.
205     IN      PTR     portable.bureau.lan.
Si la ligne $ORIGIN 251.168.192.in-addr.arpa. vous crée une erreur (voir le fichier log /var/log/daemon.log apres avoir redemarré bind9) vous pouvez la supprimer, cela fonctionne

Vérification de la configuration

Pour vérifier le fonctionnement de notre serveur DNS, nous allons utiliser les utilitaires fournit avec BIND9 named-checkconf named-checkzone.

Vérification de la configuration global named-checkconf

Le programme named-checkconf sert à vérifier la syntaxe du fichier /etc/bind/named.conf.

Version de named-checkconf :

named-checkconf -v

Contrôle du fichier :

named-checkconf /etc/bind/named.conf

Vérification de la configuration des zones named-checkzone

Le programme named-checkzone vérifie la syntaxe et la cohérence d'un fichier de zone maître.

named-checkzone nom_zone fichier_de_zone

Nous pouvons maintenant demander à notre serveur de prendre en compte nos modifications en rechargeant la configuration de bind :

sudo /etc/init.d/bind9 reload

Nous pouvons maintenant passer à la phase de vérification.

Pour vérifier le fonctionnement de notre serveur DNS, nous allons lui adresser des requêtes directement via l'utilitaire nslookup, pour l'utiliser, il suffit de taper nslookup dans un terminal.

On doit lui indiquer le serveur DNS à vérifier via le mot clé server 127.0.0.1 et ensuite, on lui donne un nom d'hôte et il doit nous répondre l'adresse IP.

Voici la petite session de test que j'ai fait chez moi :

On commence par dire à nslookup quel serveur il doit interroger :

nslookup
> server 127.0.0.1
Default server: 127.0.0.1
Address: 127.0.0.1#53

Puis on l'interroge :

> mail2.bureau.lan
Server:         127.0.0.1
Address:        127.0.0.1#53

Name:   mail2.bureau.lan
Address: 192.168.251.202
> 192.168.251.201
Server:         127.0.0.1
Address:        127.0.0.1#53

201.251.168.192.in-addr.arpa    name = twin2.bureau.lan.
> set q=mx
> bureau.lan
Server:         127.0.0.1
Address:        127.0.0.1#53
bureau.lan    mail exchanger = 10 mail2.bureau.lan.
> exit

Si tout se déroule normalement, vous pouvez configurer vos clients et utiliser votre serveur DNS.

Configuration avancée

Configuration d'un serveur DNS secondaire

Dans cette section, nous allons envisager la configuration d'un serveur DNS secondaire qui se synchronise avec le serveur DNS principal que nous avons défini ci-dessus.

Le serveur DNS secondaire proprement dit

Pour configurer le serveur secondaire, nous devons simplement indiquer à BIND les zones qu'il doit traiter en mode esclave. Sur base de la configuration ci-dessus, nous configurons le fichier /etc/bind/named.conf de serveur DNS secondaire de la manière suivante :

zone "bureau.lan" {
        type slave;
        masters {192.168.251.202;} ;
        file "/etc/bind/db.bureau.lan";
};

zone "251.168.192.in-addr.arpa" {
        type slave;
        masters {192.168.251.202;} ;
        file "/etc/bind/db.192.168.251";
};

En faisant cela, il est inutile d'indiquer les fichiers zones (fichier db.) sur le serveur DNS secondaire. Les fichiers proviendront d'une synchronisation avec le DNS primaire.

Remarque : L'utilisateur faisant fonctionner le serveur DNS doit avoir les droits d'écriture sur les fichiers zones renseignés dans la configuration ci-dessus.

Si AppArmor est installé (c'est le cas par défaut depuis Ubuntu 7.10), il empêche de toute manière bind d'écrire dans le dossier /etc/bind en configuration type slave. Dans ce cas il faut utiliser le répertoire /var/cache/bind :
...
        file "/var/cache/bind/db.bureau.lan";
...
        file "/var/cache/bind/db.192.168.251";
...
Modification de la configuration du serveur DNS primaire

Nous devons renseigner dans les fichiers zones le deuxième serveur DNS, et pour se faire, on ajoute la ligne suivante au fichier /etc/bind/db.bureau.lan :

@       IN      NS      ns2.bureau.lan.

et nous devons également renseigner l'adresse IP de ns2.bureau.lan (n'oubliez pas de mettre à jour le fichier de zone pour le sous-réseau IP également avec le mot clé PTR !) :

ns2             IN      A       192.168.251.250
250             IN      PTR     ns2.bureau.lan.

Après avoir modifié les zones et de ce fait, dévoilé ns2, nous pouvons maintenant indiquer au serveur DNS maître que le serveur DNS secondaire peut accéder aux données de zones.

Pour ce faire, les informations concernant les zones qui nous intéressent (dans le fichier /etc/bind/named.conf du serveur maître) deviennent ceci :

zone "bureau.lan" {
        type master;
        notify yes;
        allow-transfer {192.168.251.250;} ;
        file "/etc/bind/db.bureau.lan";
};

zone "251.168.192.in-addr.arpa" {
        type master;
        notify yes;
        allow-transfer {192.168.251.250;} ;
        file "/etc/bind/db.192.168.251";
};

Après toutes ces modifications, demandez au service BIND de recharger la configuration :

sudo /etc/init.d/bind9 reload

Et surtout, n'hésitez pas à re-tester votre configuration (sur les deux serveurs).

Erreurs possibles

Il est possible que vous rencontriez des logs de ce genre lors d'une mise à niveau (l'auteur l'a rencotré lors de la mise à niveau vers Karmic Koala) :

Dec 21 10:37:47 einstein kernel: [322348.978172] type=1503 audit(1261388267.711:216): operation="inode_permission"
requested_mask="::r" denied_mask="::r" fsuid=113 name="/etc/ssl/openssl.cnf" pid=7039 profile="/usr/sbin/named"

On voit là qu'il y a une erreur de permissions qui empêche le serveur de s'auto-authentifier (rôle du protocole rdnc, appelé par named) et qu'il y aura donc une erreur comme ceci au redemarrage du service bind9 :

stephane@einstein:/etc/ssl$ sudo service bind9 restart
 * Stopping domain name service... bind9
rndc: connect failed: 127.0.0.1#953: connection refused                                           
                                                                                           [ OK ] 
 * Starting domain name service... bind9                                                   [fail] 

Cette erreur est due à une mauvaise configuration des profils Appamor. Rendez vous dans le dossier d'appamor : /etc/appamor.d/

Éditez le fichier usr.sbin.named et ajoutez les permissions d'écriture à ssl :

/etc/ssl/openssl.cnf rw,

Ne touchez à rien d'autre, enregistrez, puis relancez appamor et ensuite bind9 :

sudo service appamor restart
sudo service bind9 restart

La configuration de la résolution de nom pour les machines Linux se fait dans le fichier /etc/resolv.conf. Dans ce fichier, vous pouvez ajouter le domaine de recherche via la ligne suivante (en premier dans le fichier) :

search bureau.lan

Et ensuite, les adresses de vos serveurs de noms (primaire interne, autres internes, puis ceux de votre fournisseur d'accès par exemple) de la manière suivante :

nameserver 192.168.251.202

L'ordre dans lequel vous indiquez les lignes est important. Voici le fichier tel qu'il est chez moi :

search bureau.lan
nameserver 192.168.251.202
nameserver 192.168.251.212
nameserver 193.121.171.135
nameserver 193.74.208.65

Linux va essayer de résoudre un nom de la manière suivante (si une étape ne fonctionne pas, il essaye la suivante) :

  • recherche du serveur de nom de bureau.lan et interrogation de ce serveur.
  • interrogation du serveur DNS 192.168.251.202 qui est mon serveur DNS primaire (interne).
  • interrogation du serveur DNS 192.168.251.212 qui est mon serveur DNS secondaire (interne).
  • interrogation du serveur DNS 193.121.171.135 qui est le serveur DNS primaire de mon provider.
  • interrogation du serveur DNS 193.74.208.65 qui est le serveur DNS secondaire de mon provider.

Configuration DHCP équivalente

Si le fichier /etc/resolv.conf est généré (écrasé) automatiquement par dhclient, voici les lignes correspondantes à ajouter au fichier /etc/dhcp3/dhclient.conf (Configuration testée sur Ubuntu "hardy" 8.04.3 LTS) :

prepend domain-name-servers 192.168.251.202, 192.168.251.212;
append domain-name "bureau.lan.";

Configuration des clients Windows

Sans entrer dans les détails (ce n'est pas le but du site), il vous suffit d'introduire l'adresse IP de vos serveurs DNS primaire et secondaire dans les propriétés du protocole TCP/IP (accessible dans les connexions réseaux du panneau de configuration). Rajouter le suffixe DNS correspondant à votre domaine dans les propriétés réseaux de votre carte.


  • utilisateurs/stephaneguedon/pdns.1263732791.txt.gz
  • Dernière modification: Le 18/04/2011, 14:42
  • (modification externe)