Outils pour utilisateurs

Outils du site


services:nom_de_domaine_dynamique

Nom de domaine dynamique

Principe

Lorsqu'on ne dispose que d'une adresse IP publique dynamique — c'est à dire qui change de temps en temps —, pour publier ses services sur Internet il est nécessaire de définir un enregistrement de nom de domaine pointant vers cette adresse, et de mettre à jour cet enregistrement à chaque changement d'adresse : c'est ce que l'on appelle un nom de domaine dynamique. Par exemple, vous pourrez passer de :

example.com. A 192.0.2.48

… à ceci, le lendemain :

example.com. A 192.0.2.32

Palliatif

Un système de nom de domaine dynamique reste une mesure pour pallier les limitations artificielles d'une connexion à Internet de seconde zone. Une telle mesure souffre malgré tout de défauts intrinsèques :
  • après chaque changement d'adresse IP publique, vos services seront inaccessibles le temps que les utilisateurs récupèrent la nouvelle version de l'enregistrement DNS, qui peut aller de cinq minutes à une journée pour les résolveurs qui ne respectent pas les temps d'expiration ;
  • il est impossible d'assurer son propre service de nom de domaine avec une adresse IP publique dynamique.

Il existe plusieurs mises en œuvre d'un service de nom de domaine dynamique :

  • avec un protocole standard, spécifié dans la RFC 2136 ;
  • avec un protocole spécifique à un fournisseur particulier comme DynDNS.

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.

Côté client

Installation

Commencez par installer les outils fournis avec BIND, par exemple sous Debian :

# apt-get install dnsutils

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 :

$ dnssec-keygen -a RSASHA512 -b 4096 -n HOST -T KEY tintin.dyn.example.com

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 :

$ 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

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é :

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

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 :

dyn.example.com. NS ns

Et dans la configuration /etc/bind/named.conf ou /etc/bind/named.conf.local :

zone "example.com" {
        type master ;
        file "dyn.example.com.zone" ;
} ;

Remplissez le fichier de zone avec les informations initiales pour cette zone — SOA, NS, MX nul :

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

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 :

tintin.dyn.example.com. KEY 512 3 10 AwEAAe8yZcPoomw1H7iOodt1Ef3x7Xps9uy0r5lV+DIvx+9OdVGXOtmM …

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 :

zone "example.com" {
        type master ;
        file "dyn.example.com.zone" ;
        update-policy {grant * self * ;} ;
} ;

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 :

# chown -R bind:bind /var/cache/bind/dyn

Finalement, demandez à BIND de vérifier vos zones, puis votre configuration, et finalement de l'appliquer :

# named-checkzone example.com example.com.zone
# named-checkzone dyn.example.com dyn.example.com.zone
# named-checkconf
# rndc reload

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 Gandi propose une API spécifique, qui est utilisable pour envoyer des mises à jour de zone DNS.

services/nom_de_domaine_dynamique.txt · Dernière modification: Tue Apr 2 16:50:29 2013 par elessar