BIND serveur de zone

DNS BIND 2^e partie : serveur de Zone

DNS BIND 2^e partie : serveur de Zone

Par Serge

---

Pour cet article, je considère que vous avez lu la première partie sur les serveurs DNS « cache », qui permet déjà de comprendre les fichiers de zones et donne la configuration minimale d'un serveur DNS. Sans cette configuration minimale votre serveur DNS ne fonctionnera pas.

J'explique dans cet article comment configurer une zone personnelle pour un serveur primaire et secondaire. Je n'explique pas les zones inverses ni la sécurité que l'on peut ajouter sur les zones que notre serveur va contenir. Ces parties seront vu dans un troisième article « configuration avancée ».

Un serveur DNS pour mon domaine.

Nous prenons ici un exemple de configuration pour le domaine « .org ». Remplacez bien sûr avec votre propre domaine.

Attention :

Votre serveur DNS doit, pour pouvoir fonctionner, avoir une adresse IP fixe sur l'Internet. De plus votre domaine doit être enregistré chez un registar (Gandi, Namebay, ou tout autre registar) et lors de l'enregistrement du domaine vous devez fournir l'IP du serveur de nom en serveur « primaire » et l'IP du serveur secondaire. Nous détaillons d’abord la configuration du serveur primaire, celle du secondaire étant triviale (voir plus bas dans l'article).

Le fichier /etc/named

On reprend le fichier déjà créé dans l'article “dns cache”.

Pour rappel, voici ce qu'il doit donc déjà contenir:

// Fichier /etc/named.conf 

// pour serveur DNS cache
options {

   // Répertoire des fichiers de configuration 
    

   directory "/var/named"; 
    

   // Si vous traversez un firewall 

   // et que vous avez des problèmes DNS 

   // décommentez la ligne ci-dessous 

    // query-source port 53; 
    

   version "SECRET"; 

   //permet de masquer la version de Bind - voir précisions ci-dessous 
  
 }; 
    

controls {

   inet 127.0.0.1 allow { localhost; } keys { rndc_key; }; 

   }; 

key "rndc_key" {

   algorithm hmac-md5; 

   secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; 

   }; 

//Zone racine (root)

zone "."

   { 

   type hint; 

   file "root"; 

   }; 

//Zone locale

zone "0.0.127.in-adr.arpa"

   { 

   type master; 

   file "zone/127.0.0"; 

   }; 

On ajoute alors dans ce fichier l'entrée pour notre fichier de zone “lea-linux.org:

zone “lea-linux.org” 

   { 

   type master 

file “zone/lea-linux.org” 

   }

L'ajout de zone est très simple comme vous pouvez le voir. Il suffit de dire quelle zone ce serveur va “servir”, mot clef zone , d'indiquer si nous si sommes le serveur d'autorité pour cette zone, mot clef type master et d'indiquer le fichier contenant les informations de la zone, mot clef file.

Voyons maintenant ce que doit contenir ce fichier de zone.

Le fichier de zone de mon domaine.

Nous devons donc créer le fichier de zone de notre domaine “lea-linux.org”.

Voyons le fichier, puis expliquons le:

$TTL 3D
@ IN SOA ns1.kilio.com. serge.kilio.net. (
2003091801; serial
86400 ; refresh
3600 ; retry
3600000 ; expire
604800 ; default_ttl
)

@ IN NS ns1.kilio.com.
@ IN NS ns2.kilio.com.
@ IN MX 50 ns1.kilio.net.
@ IN MX 10 nice.kilio.net.

IN A 80.245.32.131
irc IN A 80.245.32.129
www IN CNAME linuxmutuel.kilio.fr.
wiki IN A 80.67.179.10
vizu IN A 195.202.0.21
devel IN A 80.67.179.10
sniper IN A 62.212.100.216
ftp IN A 80.245.32.131
beta IN CNAME linuxmutuel.kilio.fr

Cela peut vous paraître très “barbare” mais en fait rien n'est très compliqué. On peut découper ce fichier en deux parties:

• L'en-tête: qui commence au début du fichier $TTL et se finit à la “)”
• Les enregistrements de la zone: le reste du fichier.

Détail de l'en-tête.

Nous l'avons déjà vu dans l'article précédent mais voici ce qu'elle doit contenir obligatoirement:

$TTL : l'indication du TTL (Time To Live) ou la durée de vie de la zone, exprimée en secondes par défaut, ou dans une autre unité si on la spécifie comme dans l'exemple, ici le D spécifiant que l'unité est en jours, donc 3 jours pour notre exemple.

Le bloc suivant défini tous les autres paramètres “techniques et administratifs” de la zone de la forme:

@ IN SOA dns_primaire. adresse_mail. (
xxxxxxxx; serial
xxxxx; refresh
xxxxx; retry
xxxxx; expire
xxxxx; default_ttl
)

dns_primaire: mettre ici le nom du serveur faisant autorité pour la zone

adresse email: email du responsable technique de la zone en remplaçant le “@” de l'email par un “.”

Le reste, encadré par des parenthèses renseigne les données techniques de la zone avec:

serial: le numéro de version de la zone.

Ce chiffre est particulièrement important. A chaque fois que vous modifiez quoi que ce soit dans un fichier de zone, vous devez impérativement incrémenter ce numéro, autrement les changements ne seront pas pris en compte par le reste du monde et particulièrement par le serveur secondaire. C'est ce numéro, s'il est incrémenté, qui indique au reste du monde que votre zone a subit un changement et que donc les autres serveurs DNS doivent redemander la zone à votre serveur pour prendre en compte ces changements.

On a l'habitude de suivre une règle simple pour être sûr d'incrémenter ce numéro de version, on le compose par la suite des chiffres de l'année en cours, mois, jour et le nombre de changements effectués ce jour là:

AAAAMMJJNN

Donc par exemple si je modifie la zone le 10 juillet 2003 , je vais mettre 2003071001, puis je m'aperçois que je me suis trompé donc je la modifie à nouveau le même jour, donc ce serial devient 2003071002, et si je la modifie ensuite le 15 août de la même année le serial devient alors 2003081501.

Cette règle n'est pas du tout obligatoire, vous pouvez utiliser votre propre règle du moment que le nombre soit incrémenté et que ce nombre ne comporte pas plus de 10 chiffres.

Refresh: Temps en secondes d'attente du serveur secondaire avant de contrôler si le serveur primaire a subi une modification au niveau de sa zone. Sur 8 chiffres max.

Retry: Temps d'attente du serveur secondaire avant de faire à nouveau une demande si le serveur primaire n'a pas répondu à une requête. Sur 8 chiffres max.

Expire: Temps pendant lequel le serveur secondaire va conserver les données en cache. Si ce délai est dépasse et que le serveur secondaire n'a pas pu contacter le serveur primaire, il va alors considérer que les données qu'il a en cache ne sont plus fiable et ne pourra plus servir de serveur secondaire pour la zone tant qu'il n'aura pas réussi à contacter le serveur primaire. Sur 8 chiffres max.

Ttl: Valeur par défaut de ttl des enregistrements. On peut spécifier les ttls au niveau de chaque enregistrement, mais d'une manière générale on défini ici un ttl qui vaut pour tous les enregistrements.

Enregistrement de la zone.

Tout les enregistrements d'une zone suivent cette syntaxe:

hôte_ou_wildcard (ttl) classe type (priorité_si_besoin) valeur

Voici les explications de ces champs, puis en dessous quelques exemples pour mieux comprendre. Par défaut nous n'utilisons pas de ttl pour les enregistrements (voir la remarque au dessus pour le ttl dans l'en-tête de zone).

Hôte ou wildcard: indique si on défini une machine ou un ensemble de machine.

Classe: type de classe, a comme valeur IN pour l'Internet. Nous ne détaillerons pas ce champ, vous utiliserez toujours la classe IN pour vos besoins.

Type: Indique quel type d'enregistrement nous sommes en train de définir. Les types les plus utilisés sont A pour une adresse, CNAME pour un alias de nom, NS pour un serveur de nom, MX pour un serveur de Mail, TXT pour des commentaires.

Priorité: Si le type à besoin d'une priorité, nous l'indiquons ici.

Valeur: la valeur ou la donnée de l'enregistrement que nous définissons.

Détaillons alors les exemples de notre zone pour mieux comprendre:

@ IN NS ns1.kilio.com.
@ IN NS ns2.kilio.com.

Nous indiquons ici que les deux serveurs DNS (type NS) de la zone (wildcard @) lea-linux.org sont ns1.kilio.com et ns2.kilio.com

@ IN MX 50 ns1.kilio.net.
@ IN MX 10 nice.kilio.net.

Nous indiquons ici que les deux serveurs de Mail (type MX) de la zone (wildcard @) lea-linux.org sont : nice.kilio.net avec la priorité 10 ns1.kilio.net avec la priorité 50. Cela veut dire que tout mail du type xxxxxx@lea-linux.org doit être envoyé en priorité sur nice.kilio.net et que si ce serveur ne répond pas on l'envoie alors sur le serveur ns1.kilio.net. Faites attention, c'est la priorité la plus basse qui indique le premier serveur à contacter.

irc IN A 80.245.32.129

Nous indiquons ici que l'hôte irc.lea-linux.org correspond à l'adresse 80.245.32.129

www IN CNAME linuxmutuel.kilio.fr.

Nous indiquons ici que l'hôte www.lea-linux.org correspond à l'hôte linuxmutuel.kilio.fr .
On aurait pu aussi le définir en type A et mettre l'adresse ip correspond à linuxmutuel.kilio.fr comme valeur. Mais dans ce cas, si la machine linuxmutuel.kilio.fr change d'adresse IP on doit modifier la valeur de www pour la zone lea-linux.org. De plus, comme cette machine héberge environ 200 sites web différents, il y aurait 200 fichiers de zones à modifier avec la nouvelle IP. Pour éviter cela, on définit alors www.lea-linux.org comme CNAME de linuxmutuel.kilio.fr.

IN A 80.245.32.131

Vous remarquerez que le 1er champ est vide. Cela indique tout simplement que si l'on demande lea-linux.org directement (sans spécifier d'hôte) on aura l'IP 80.245.32.131. Ce qui permet de taper dans votre navigateur http://lea-linux.org sans le "www"..

Voici un autre exemple qui n'est pas dans notre zone mais qui définit le type TXT:

info IN TXT Zone du fabuleux site linux entre amis

Indique que info à comme valeur “Zone du fabuleux site Linux entre amis”. Aucune application n'a besoin de ce type d'enregistrement, mais il peut être utile pour donner des infos sur une zone, etc..

Il existe d'autres types d'enregistrements que ceux vu ci-dessus, mais ils sont très rarement utilisés sur l'Internet. Consultez les RFC sur les DNS si vous souhaitez les connaître.

Serveur secondaire.

Tout ce que nous avons vu au dessus concerne la configuration du serveur primaire de votre zone. Il faut généralement déclarer lors de l'enregistrement de votre domaine chez un registar un serveur secondaire (et parfois des tertiaires etc.. mais la configuration est exactement identique à celle d'un serveur secondaire, et seul le secondaire et obligatoire). Il faut donc, vous vous en doutez, le configurer lui aussi.

Le serveur secondaire sert tout simplement à répondre aux requêtes à la place du primaire pour ne pas surcharger le serveur primaire ou si le serveur primaire est hors service temporairement.

Il doit contenir tout d'abord la configuration de base vue dans l'article “serveur cache” comme n'importe quel serveur DNS qu'il soit primaire ou secondaire. Et il doit aussi contenir dans son fichier named.conf les zones pour lesquelles il est serveur secondaire sous la forme:

zone “lea-linux.org”
{
type slave
file “zone/lea-linux.org”
masters {ip_serveur_primaire;}
}

et rien d'autre. Pas de fichier de zone ni rien. Les fichiers de zones seront créés automatiquement en interrogeant le serveur primaire directement via la directive masters.

Et si ça ne marche pas ?

Vous pouvez alors faire exactement les mêmes vérifications que celles données dans l'article serveur cache. La seule différence est que si vous faites les tests nslookup sur le serveur primaire vous ne devez pas avoir de réponse “Non-authoritative”.

Cette page est issue de la documentation 'pré-wiki' de Léa a été convertie avec HTML::WikiConverter. Elle fut créée par Serge Tchesmeli le 04/10/2003.

Copyright

Copyright © 04/10/2003, Serge Tchesmeli

Vous avez l'autorisation de copier, distribuer et/ou modifier ce document suivant les termes de la Licence pour documents libres, Version 1.1 publiée par la La Guilde des Doctorants. Pour plus d'informations consulter la LDL sur le site de La Guilde des Doctorants.