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 :
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.
Le réplication de votre zone sur un serveur asservi doit être sécurisée. En effet, il faut éviter :
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
# dnssec-keygen -d tsig # répertoire de stockage \
-t HOST # type de clef \
-a HMAC-MD5 # algorithme de signature \
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
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 ?
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
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.
Si vous n'avez pas d'ami 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.