Outils pour utilisateurs

Outils du site


coopération:serveur_de_noms_secondaire

Serveur de noms secondaire

Le système DNS prévoit l'utilisation de plusieurs serveurs de noms pour un domaine, ce qui permet de maintenir le service en cas de défaillance d'un serveur. Ces serveurs sont déclarés auprès du registre et dans le domaine lui-même, sous la forme de plusieurs enregistrements NS.

Le principe d'utilisation de serveurs secondaires est le suivant :

  1. lors de leur mise en place, les serveurs secondaires, asservis, récupèrent le fichier de zone complet auprès du serveur maître ;
  2. à chaque modification du fichier de zone, le serveur maître envoie aux serveurs asservis une notification ;
  3. à la réception de cette notification, les serveurs asservis récupèrent les changements apportées.

Voici comment, en tant qu'administrateur d'un serveur et propriétaire d'un domaine example.com., vous pouvez préparer votre configuration, et donner à un ami example.org. les instructions pour qu'il fasse office de serveur asservi pour votre domaine.

Sur le serveur maître

Le réplication de votre zone sur un serveur asservi doit être sécurisée. En effet, il faut éviter :

  • que n'importe qui puisse se faire passer pour votre serveur secondaire et récupérer toutes les informations de votre zone ;
  • que n'importe qui puisse se faire passer pour votre serveur primaire et fournir des fausses informations à vos serveurs secondaires.

La réplication DNS est donc basée sur un système de signature numérique, TSIG. C'est un système symétrique, c'est à dire que votre serveur primaire partage un secret commun avec chaque serveur secondaire (ce secret peut être différent pour chaque serveur secondaire, il doit juste être commun aux deux parties impliquées dans un échange). La première étape consiste donc à générer une clef TSIG, à laquelle on donne généralement un nom composé de la concaténation des noms des serveurs impliqué, comme s'il s'agissait d'un nom d'enregistrement DNS de votre zone :

# mkdir tsig ; cd tsig
# dnssec-keygen -n HOST        # type de clef \
                -a HMAC-SHA512 # algorithme de signature \
                -b 512         # taille de clef \
                ns.example.org.ns.example.com. # nom de la clef

Cela génère deux fichiers, un .private et un .key. Comme il s'agit ici d'un algorithme symétrique, les deux contiennent en fait les mêmes données, et doivent rester secrètes. Vous pouvez maintenant modifier votre fichier de configuration de BIND, /etc/bind/named.conf[.local], pour y ajouter la clef et autoriser le transfert de votre zone aux serveurs disposant de cette clef :

key ns.example.org.ns.example.com. {
        algorithm hmac-md5 ;
        secret "le contenu de la clef, récupéré dans un des fichiers générés" ;
} ;

zone example.com {
        type master ;
        file "master/example.com.zone" ;
        allow-transfer { key ns.example.org.ns.example.com. ;} ;
} ;

Sur ce, demandez à BIND de recharger sa configuration :

# rndc reload

Sur le serveur asservi

Vous devez transmettre le contenu de la clef à l'administrateur du serveur qui vous servira de NS secondaire. Il devra ensuite modifier son fichier de configuration de BIND, pour y ajouter la définition de cette clef, de votre serveur maître, et de votre zone :

key ns.example.org.ns.example.com. {
        algorithm hmac-md5 ;
        secret "le contenu de la clef, récupéré dans un des fichiers générés" ;
} ;
masters ns.example.com { votre_adressse_IP key ns.example.org.ns.example.com. ;} ;

zone example.com {
        type slave ; notify no ;
        file "slave/example.com.zone" ;
        masters ns.example.com ;
} ;

Votre adresse IP ?

Lorsque vous modifierez votre zone, votre serveur en notifiera ses serveurs asservis. En revanche, pour le premier transfert, et pour les transferts de routine, les serveurs asservis contacteront directement votre serveur : ils doivent pour cela connaître son adresse IP, d'où sa présence dans leur fichier de configuration.

Quant aux notifications, votre serveur les envoie tout simplement à tous les NS déclarés dans votre fichier de zone. Par conséquent, tant que vous n'aurez pas ajouté votre serveur asservi à votre fichier de zone, les notifications ne fonctionneront pas, à moins d'utiliser l'option also-notify dans le bloc de définition de votre zone.

Il faut enfin vérifier que BIND peut écrire dans le répertoire /var/cache/bind/slave/, où il devra écrire le fichier de zone récupéré, puis recharger sa configuration :

# rndc reload

Dans le fichier de zone

Commencez par vérifier que la réplication se déroule bien : lorsque l'administrateur du serveur asservi recharge sa configuration, vous devez voir apparaître des lignes à ce sujet dans le fichier journal de BIND, /var/log/daemon.log. Vérifiez ensuite le bon comportement du serveur asservi aux requêtes DNS, en lui demandant quelques enregistrements :

$ dig A www.example.com. @ns.example.org.

Si vous êtes satisfait de votre serveur asservi, vous pouvez l'ajouter à la liste de vos NS, dans votre fichier de zone :

@       NS      ns
@       NS      ns.example.org.

Vous devez également effectuer cette modification auprès de votre bureau d'enregistrement, pour qu'il demande au registre de mettre à jour les enregistrements glue correspondants.

Fournisseurs de serveurs secondaires

Si vous n'avez pas d'ami (coopération) prêt à vous fournir un service DNS secondaire, sachez qu'il existe plusieurs organisations proposant un tel service :

En revanche, les systèmes de réplication DNS de ces fournisseurs n'utilisent généralement pas de signature numérique TSIG, et leur (faible) sécurité est donc basée sur l'adresse IP de votre serveur. Par ailleurs, certains fournisseurs ne réagissent pas aux notifications de modification de zone, et se contentent de recharger votre zone une fois par jour.

coopération/serveur_de_noms_secondaire.txt · Dernière modification: Thu Nov 28 11:26:56 2013 par elessar