[a-h-aide] Serveur DynDNS

Tanguy Ortolo tanguy at ortolo.eu
Lun 4 Juin 18:27:39 CEST 2012


Andre POMPAS, 2012-06-04 14:41+0200:
>J'avoue que je me suis trompé de terme avec le "DynDNS" car se sont des
>services existant sur le net comme "No-IP" etc....désolé pour cette erreur.

Pas besoin de t'excuser, je tenais à être précis pour expliquer, c'est 
tout. :-)

>Vue que tu as de l'expérience dans ce domaine car tu en as déjà mit en
>place, pourrais tu m'aider ou bien me donner de la documentations pour que
>je puisse mettre ce système en place s'il te plaît.

C'est un sujet que je dois justement documenter. Assez rapidement, ce 
qu'il va falloir c'est :

1. Définir une zone DNS dédiée
==============================

En effet, cette zone sera mise à jour très souvent et par des demandes 
extérieures à BIND. Si ton nom de domaine principal est example.com, il 
faut donc définir une zone dyn.example.com et te la déléguer à toi-même. 
Dans le fichier de configuration de BIND named.conf :
     zone "dyn.example.com" {
         type master;
         file "dyn.example.com.zone";
         allow-transfer { <tes serveurs secondaires> };
     };

Et dans le fichier de zone correspondant, dyn.example.com.zone donc, les 
définitions habituelles du SOA (avec un TTL minimum faible, de l'ordre 
de 5 minutes) et des NS.

2. Créer une paire de clefs d'identification
============================================

N'importe qui ne doit pas être autorisé à demander des mises à jour de 
la zone dyn.example.com : on utilise pour cela un système de signature 
cryptographique appelé SIG(0).

Pour un poste nommé toto, sur le client qui enverra les mises à jour :
     $ dnssec-keygen -a RSASHA1 -b 2048 \
           toto.dyn.example.com

Cela génère deux fichiers, l'un (.key) contenant la clef publique, qui 
doit être insérée dans le fichier de zone dyn.example.com, l'autre 
contenant la clef privée qui permettra au logiciel de mise à jour de 
s'identifier auprès du serveur.

3. Autoriser les mises à jour
=============================

Dans la définition de la zone dans le fichier de configuration de BIND 
named.conf, on va autoriser les gens munis d'une clef à mettre à jour 
les enregistrements d'adresse de même nom. Par exemple, quelqu'un 
disposant de la clef privée toto.dyn.example.com pourra mettre à jour 
les enregistrements toto.dyn.example.com A et AAAA :
     zone "dyn.example.com" {
         type master;
         file "dyn.example.com.zone";
         update-policy {grant * self * A AAAA ;} ;
         allow-transfer { <tes serveurs secondaires> };
     }

4. Rédiger un script de mise à jour
===================================

Le poste client doit régulièrement envoyer des demandes de mise à jour 
de la zone, avec l'outil nsupdate. Il faut pour cela rédiger un script 
qui :
1. détermine l'adresse publique du poste ;
2. vérifie qu'elle a changé ;
3. si elle a changé :
    1. demande le retrait de l'ancien enregistrement A ou AAAA,
    2. demande l'ajout du nouvel enregistrement A ou AAAA.

Le script en question doit être idéalement lancé au moment où l'adresse 
change, ou, si ce n'est pas possible, à intervalle régulier. La commande 
nsupdate pour enlever l'enregistrement existant et le remplacer par un 
nouveau ressemble à ceci (le fichier de clef publique doit être dans le 
même répertoire) :
     nsupdate -k Ktoto.dyn.example.com.+010+54707.private <<EOF
         update delete toto.dyn.example.com A
         update add toto.dyn.example.com A $nouvelle_adresse
         send
     EOF

-- 
Tanguy Ortolo
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: signature.asc
Type: application/pgp-signature
Taille: 836 octets
Desc: Digital signature
URL: <http://listes.auto-hebergement.fr/pipermail/auto-hebergement-aide/attachments/20120604/0bc75a61/attachment.pgp>


Plus d'informations sur la liste de diffusion auto-hebergement-aide