Outils pour utilisateurs

Outils du site


services:nom_de_domaine_dynamique

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
services:nom_de_domaine_dynamique [Tue Apr 2 13:20:21 2013]
elessar sauvegarde, pas encore fini…
services:nom_de_domaine_dynamique [Tue Apr 2 16:50:29 2013] (Version actuelle)
elessar permissions pour BIND
Ligne 16: Ligne 16:
   * il est impossible d'​assurer son propre [[nom de domaine|service de nom de domaine]] avec une adresse IP publique dynamique.   * il est impossible d'​assurer son propre [[nom de domaine|service de nom de domaine]] avec une adresse IP publique dynamique.
 </​box>​ </​box>​
- 
-===== Mise en œuvre ===== 
  
 Il existe plusieurs mises en œuvre d'un service de nom de domaine dynamique :​ Il existe plusieurs mises en œuvre d'un service de nom de domaine dynamique :​
Ligne 23: Ligne 21:
   * avec un protocole spécifique à un fournisseur particulier comme DynDNS.   * avec un protocole spécifique à un fournisseur particulier comme DynDNS.
  
-==== Protocole ​standard ====+===== Mise en œuvre avec le protocole ​standard ​=====
  
 Le protocole standard de mise à jour dynamique permet à un client — vous — de demander au serveur d'un fournisseur de retirer un ancien enregistrement DNS et d'en ajouter un nouveau à la place. Il s'​utilise avec l'​outil ''​nsupdate''​ qui fait partie de la suite fournie avec le serveur de nom BIND, et nécessite une clef ou une paire de clefs cryptographiques pour valider la demande. Le protocole standard de mise à jour dynamique permet à un client — vous — de demander au serveur d'un fournisseur de retirer un ancien enregistrement DNS et d'en ajouter un nouveau à la place. Il s'​utilise avec l'​outil ''​nsupdate''​ qui fait partie de la suite fournie avec le serveur de nom BIND, et nécessite une clef ou une paire de clefs cryptographiques pour valider la demande.
  
-=== Côté client ===+==== Côté client ​====
  
-== Installation ==+=== Installation ​===
  
 Commencez par installer les outils fournis avec BIND, par exemple sous Debian : Commencez par installer les outils fournis avec BIND, par exemple sous Debian :
Ligne 35: Ligne 33:
 <​code>#​ apt-get install dnsutils</​code>​ <​code>#​ apt-get install dnsutils</​code>​
  
-== Génération des clefs ==+=== Génération des clefs ===
  
 Générez ensuite la paire de clefs SIG(0) qui sera utilisée pour signer vos demandes de mise à jour. Cette paire de clefs doit porter le nom que vous allez utiliser, par exemple ''​tintin.dyn.example.com''​ :​ Générez ensuite la paire de clefs SIG(0) qui sera utilisée pour signer vos demandes de mise à jour. Cette paire de clefs doit porter le nom que vous allez utiliser, par exemple ''​tintin.dyn.example.com''​ :​
Ligne 41: Ligne 39:
 <​code>​$ dnssec-keygen -a RSASHA512 -b 4096 -n HOST -T KEY tintin.dyn.example.com</​code>​ <​code>​$ dnssec-keygen -a RSASHA512 -b 4096 -n HOST -T KEY tintin.dyn.example.com</​code>​
  
-La génération d'une paire de clefs nécessite une grande quantité de nombres aléatoires et prend donc un certain temps, après quoi vous obtenez deux fichiers : un ''​.key''​ qui contient la clef publique, et un ''​.private''​ qui contient la clef privée. Transmettez le fichier de clef publique à votre fournisseur de DNS dynamique.+La génération d'une paire de clefs nécessite une grande quantité de nombres aléatoires et prend donc un certain temps, après quoi vous obtenez deux fichiers : un ''​.key''​ qui contient la clef publique, et un ''​.private''​ qui contient la clef privée. Transmettez le fichier de clef publique à votre fournisseur de DNS dynamique ​et attendez qu'il configure sur serveur pour autoriser les demandes de mise à jour ainsi signées… 
 + 
 +=== Utilisation du client de mise à jour === 
 + 
 +Le client de mise à jour ''​nsupdate''​ nécessite évidemment le fichier de clef privée à utiliser pour signer la demande :​ 
 + 
 +<​code>​$ nsupdate -k Ktintin.dyn.example.com*.private 
 +> update delete tintin.dyn.example.com. ​    A 
 +> update add    tintin.dyn.example.com. 300 A 192.0.2.32 
 +> send 
 +</​code>​ 
 + 
 +''​nsupdate''​ envoie automatiquement la demande au serveur maître de la zone DNS contenant l'​enregistrement concerné. Si le serveur est bien configuré pour accepter les demandes de mise à jour signées par cette clef, la demande devrait être acceptée et propagée immédiatement. 
 + 
 +=== Automatisation === 
 + 
 +En pratique, vous voudrez automatiser cela pour envoyer une mise à jour à chaque changement d'​adresse IP publique, idéalement dès qu'​elle change, ce qui est rarement possible, ou faute de mieux en vérifiant régulièrement si elle a changée. 
 + 
 +Vous pouvez pour cela vous inspirer du script suivant, qui utiliser l'​outil ''​external-ip''​ fourni avec MiniUPnP. Attention à bien vérifier qu'il fonctionne, parce qu'il n'a pas encore été testé : 
 + 
 +<file bash ip-ns-update>​ 
 +previous_ip="​$(cat /​tmp/​current-ip)"​ 
 +current_ip="​$(external-ip)"​ 
 +name="​tintin.dyn.example.com"​ 
 +ttl=300 
 + 
 +if [ "​$current_ip"​ != "​$previous_ip"​ ] 
 +then 
 +    cat <<EOF | nsupdate -k "​K$name"​*.private 
 +update delete $name      A 
 +update add    $name $TTL A $current_ip 
 +send 
 +EOF 
 +    printf '​%s\n'​ "​$current_ip"​ > /​tmp/​current-ip 
 +fi 
 +</​file>​ 
 + 
 +FIXME À vérifier 
 + 
 +Après avoir vérifié qu'il fonctionnait bien, vous pouvez le placer toutes les cinq minutes à la crontab d'un utilisateur dédié à cela, qui disposera de la clef privée pour signer la demande de mise à jour. 
 + 
 +==== Côté serveur ==== 
 + 
 +=== Définition d'une zone dédiée === 
 + 
 +Pour fournir un service de nom de domaine dynamique avec BIND, vous devez définir une zone dynamique. Comme cela modifiera le fichier de zone correspondant à chaque mise à jour, supprimant les commentaires et le formatage spécifique éventuels, il est judicieux de s'​auto-déléguer pour cela une zone //​en-dessous//​ de se zone principale, par exemple ''​dyn.example.com''​. 
 + 
 +Pour cela, dans le fichier de zone supérieur ''​exemple.com''​ :​ 
 + 
 +<​code>​ 
 +dyn.example.com. NS ns 
 +</​code>​ 
 + 
 +Et dans la configuration ''/​etc/​bind/​named.conf''​ ou ''/​etc/​bind/​named.conf.local''​ :​ 
 + 
 +<​code>​ 
 +zone "​example.com"​ { 
 +        type master ; 
 +        file "​dyn.example.com.zone"​ ; 
 +} ; 
 +</​code>​ 
 + 
 +Remplissez le fichier de zone avec les informations initiales pour cette zone — SOA, NS, MX nul : 
 + 
 +<file - dyn.example.com.zone>​ 
 +$TTL 600 
 +@ SOA ns hostmaster.example.com. ( 
 +      2013040201 ; serial 
 +      1y         ; intervalle de rafraîchissement systématique par les serveurs secondaires 
 +      5m         ; temps d'​attente avant de réessayer un rafraîchissement échoué pour les serveurs secondaires 
 +      1w         ; temps d'​expiration de la zone sur les serveurs secondaires si le rafraîchissement échoue 
 +      5m         ; TTL minimum 
 +  ) 
 +  NS ns.example.com. 
 +  MX 0 .         ; pas de courrier électronique pour cette zone 
 +</​file>​ 
 + 
 +=== Autorisation de mise à jour === 
 + 
 +Votre utilisateur de service de nom dynamique doit vous fournir une clef publique SIG(0) pour que vous autorisiez les mises à jour de son nom de domaine signées avec la clef privée correspondante,​ et seulement celles-là. Cette clef publique prend la forme d'un enregistrement DNS, à publier dans la zone dynamique avec le nom visé par la mise à jour dynamique — comme pour chaque changement, pensez à modifier le numéro de série de la zone : 
 + 
 +<​code>​ 
 +tintin.dyn.example.com. KEY 512 3 10 AwEAAe8yZcPoomw1H7iOodt1Ef3x7Xps9uy0r5lV+DIvx+9OdVGXOtmM … 
 +</​code>​ 
 + 
 +Il faut ensuite configurer la zone en question pour accepter les mises à jour dynamiques pour les noms identiques à celui de la clef qui a servi à signer la demande. Il est judicieux de placer cette zone dans un sous-répertoire de ''/​var/​cache/​bind''​ :​
  
-== Utilisation du client de mise à jour ==+<​code>​ 
 +zone "​example.com"​ { 
 +        type master ; 
 +        file "​dyn.example.com.zone"​ ; 
 +        update-policy {grant * self * ;} ; 
 +} ; 
 +</​code>​
  
 +BIND doit également avoir accès au fichier de zone et au répertoire qui le contient en lecture et en écriture, de façon à pouvoir mettre en place les mises à jour dynamiques demandées par les clients :
  
-==== Protocole spécifique ====+<​code>#​ chown -R bind:bind /​var/​cache/​bind/​dyn</​code>​
  
-=== DynDNS ===+Finalement, demandez à BIND de vérifier vos zones, puis votre configuration,​ et finalement de l'​appliquer :​
  
-=== Gandi ===+<​code>​ 
 +# named-checkzone example.com example.com.zone 
 +# named-checkzone dyn.example.com dyn.example.com.zone 
 +# named-checkconf 
 +# rndc reload 
 +</​code>​
  
 +===== Mise en œuvre avec un protocole spécifique =====
  
 +==== DynDNS ====
  
 +DynDNS est un fournisseur de DNS dynamique, probablement le premier à avoir vu le jour. Il existe de nombreux clients DynDNS, et la plupart des modem-routeurs domestiques en intègrent d'​ailleurs un.
  
 +==== Gandi ====
  
 +Le bureau d'​enregistrement DNS [[http://​www.gandi.net/​|Gandi]] propose une API spécifique,​ qui est utilisable pour envoyer des mises à jour de zone DNS.
services/nom_de_domaine_dynamique.1364901621.txt.gz · Dernière modification: Tue Apr 2 13:20:21 2013 par elessar