DNS dynamique (DDNS) : comment le configurer sans se tromper

Un DNS dynamique met à jour automatiquement l'enregistrement A ou AAAA d'un nom quand l'adresse publique de votre connexion change, sans intervention manuelle. La configuration se résume à trois décisions : qui déclenche la mise à jour (le routeur, un client comme ddclient, un script), par quel canal (l'API d'un fournisseur ou un UPDATE DNS conforme à la RFC 2136), et avec quel TTL.

Sommaire

Deux technologies différentes portent le nom de DDNS

La confusion est fréquente et elle coûte des heures de recherche. D'un côté, il y a le service grand public : vous créez un nom chez No-IP, DuckDNS, Dynu ou votre registrar, un petit client tourne chez vous et signale la nouvelle adresse publique via une requête HTTPS. De l'autre, il y a le vrai protocole de mise à jour dynamique du DNS, défini par la RFC 2136, où un client envoie un message DNS de type UPDATE au serveur faisant autorité sur le port 53, exactement comme une requête classique mais avec un opcode différent.

Une troisième acception existe en environnement Windows : le serveur DHCP enregistre lui-même ses clients dans une zone DNS intégrée à l'annuaire, en s'appuyant sur l'option DHCP 81 (option FQDN, RFC 4702). Ce n'est pas la même chose du tout, cela concerne des noms internes et non votre adresse publique. Si un tutoriel vous parle de « zone autoriser les mises à jour dynamiques sécurisées uniquement », vous êtes dans ce troisième cas.

En pratique, choisissez la première approche si vous voulez juste joindre votre NAS depuis l'extérieur, la seconde si vous gérez déjà votre propre zone et que vous voulez garder la main sur la clé de signature.

Le montage courant : un client de mise à jour sur le routeur

La plupart des box et routeurs embarquent déjà un client DDNS. OpenWrt le fournit avec le paquet ddns-scripts, pfSense et OPNsense ont un onglet dédié, et côté opérateur français, la Freebox propose un nom gratuit en .fbxos.fr depuis Freebox OS. Quand le routeur ne sait pas parler au fournisseur que vous avez choisi, ddclient sur une machine allumée en permanence fait le travail.

Le paramètre qui casse le plus souvent une configuration est le mode de détection de l'adresse. Avec use=if, ddclient lit l'adresse de l'interface locale : correct si la machine est le routeur, faux dès qu'elle est derrière une box, puisqu'il publiera alors une adresse privée en 192.168.x.x. Avec use=web, il interroge un service externe et récupère l'adresse réellement vue depuis Internet. Dans le doute, prenez use=web.

Les fournisseurs qui parlent le protocole dyndns2 renvoient tous les mêmes codes en texte brut. Les lire évite de chercher au mauvais endroit.

protocol=dyndns2
use=web, web=checkip.dyndns.com/, web-skip='IP Address'
server=members.dyndns.org
login=mon-compte
password='mon-token'
maison.example.com

Réponse	Signification	Réaction attendue
good 203.0.113.10	Mise à jour acceptée	Mémoriser l'adresse envoyée, ne plus rien envoyer
nochg	L'adresse envoyée est déjà enregistrée	Cesser de répéter la requête, elle est comptée comme abus
badauth	Identifiants refusés	Vérifier le login et le token, pas le mot de passe du compte
notfqdn	Le nom envoyé n'est pas complet	Envoyer maison.example.com, pas maison
nohost	Le nom n'existe pas sur ce compte	Créer l'hôte côté fournisseur avant de lancer le client
abuse	Compte suspendu pour trop de requêtes	Espacer les mises à jour et contacter le support
911	Panne côté fournisseur	Attendre au moins 30 minutes avant de réessayer

Mettre à jour sa propre zone avec nsupdate

Si vous hébergez votre zone sur BIND, Knot ou PowerDNS, vous n'avez besoin d'aucun service tiers. Générez une clé partagée avec tsig-keygen, déclarez-la dans la configuration du serveur, puis limitez ce qu'elle a le droit de modifier. La directive update-policy de BIND est préférable à allow-update parce qu'elle restreint la clé à un seul nom : grant ddns-key name maison.example.com. A AAAA;

La signature TSIG est décrite par la RFC 8945, qui remplace la RFC 2845, et l'usage de TSIG ou SIG(0) pour authentifier un UPDATE relève de la RFC 3007. Sans signature, un UPDATE non authentifié permettrait à n'importe qui de déplacer votre nom, donc aucun serveur sérieux ne l'accepte par défaut.

Une session nsupdate ressemble à ceci. La suppression avant l'ajout évite d'empiler deux enregistrements A contradictoires, symptôme classique d'un script qui ne fait que des update add.

nsupdate -k /etc/bind/Kddns-key.+165+12345.key
> server ns1.example.com
> zone example.com
> update delete maison.example.com. A
> update add maison.example.com. 60 A 203.0.113.10
> send

TTL, IPv6 et CGNAT : les trois réglages qui font échouer un DDNS

Un TTL de 3600 secondes sur un nom dynamique, c'est jusqu'à une heure d'injoignabilité après chaque changement d'adresse. Descendez à 60 ou 300 secondes. Pensez aussi au champ minimum du SOA : il pilote la durée de mise en cache des réponses négatives (RFC 2308), donc si un résolveur a mis en cache un NXDOMAIN pendant que vous créiez le nom, il le gardera d'autant plus longtemps que cette valeur est élevée.

En IPv6, le problème se déplace. Beaucoup d'opérateurs délèguent un préfixe qui change à la reconnexion, et l'adresse de votre serveur change avec lui. Il faut alors publier un AAAA en plus du A, ce que ddclient gère avec usev6. Rien ne garantit que le client mette les deux à jour au même moment : vérifiez les deux enregistrements séparément.

Le cas de panne le plus frustrant reste le CGNAT. Si votre opérateur vous place derrière un partage d'adresses, l'interface WAN de votre box porte une adresse de la plage 100.64.0.0/10 réservée par la RFC 6598, et l'adresse publique est partagée avec d'autres abonnés. Le DDNS continuera de fonctionner et publiera une adresse valide, mais aucune redirection de port ne sera possible et votre service restera injoignable. Le test tient en une commande : comparez l'adresse WAN affichée par la box avec le résultat de curl -4 ifconfig.me. Si elles diffèrent, vous êtes derrière un CGNAT et il faut demander une adresse publique à l'opérateur ou passer par un tunnel.

TTL du A et du AAAA : 60 à 300 secondes
Fréquence de vérification du client : 5 minutes suffisent, une minute est du gaspillage
Adresse WAN dans 100.64.0.0/10 : CGNAT, redirection de port impossible
Adresse WAN dans 192.168.0.0/16 ou 10.0.0.0/8 : double NAT, la box amont doit être configurée

Vérifier que ça marche, et le garder sûr

Ne testez jamais avec le résolveur de votre poste, il vous servira une réponse en cache. Interrogez directement le serveur faisant autorité : dig +short maison.example.com @ns1.example.com. Comparez ensuite avec dig maison.example.com @1.1.1.1, la ligne de réponse affiche le TTL restant et vous dit combien de temps la vieille valeur va encore circuler.

Côté client, ddclient garde son état dans un fichier de cache et refuse de renvoyer une adresse identique. Pour forcer un cycle complet et voir la requête réelle : ddclient -daemon=0 -debug -verbose -noquiet. C'est là que les erreurs d'authentification apparaissent en clair.

Sur la sécurité, deux règles suffisent. Utilisez un jeton dédié plutôt que le mot de passe de votre compte : chez Cloudflare, un token limité à Zone.DNS Edit sur une seule zone, chez un registrar, une clé API restreinte à un enregistrement si l'offre le permet. Et sur un serveur que vous administrez, restreignez la clé TSIG au nom concerné, pas à la zone entière. Le même mécanisme sert d'ailleurs à Let's Encrypt pour le challenge DNS-01 : le plugin rfc2136 crée un TXT _acme-challenge temporaire, avec une clé qui ne doit pouvoir toucher qu'à ce nom.

Un point que je ne peux pas trancher pour vous : la tolérance des opérateurs et des fournisseurs de DDNS gratuits varie et leurs conditions changent. No-IP demande par exemple une confirmation du nom tous les 30 jours sur son offre gratuite. Relisez les conditions du service que vous retenez avant d'y accrocher un accès distant dont vous dépendez.

Testez vos connaissances

Quiz rapide Question 1 sur 3

Quelle RFC définit le message DNS UPDATE utilisé pour la mise à jour dynamique d'une zone ?

Questions fréquentes

Ai-je besoin d’une IP fixe pour héberger un service chez moi ?

Non dans la majorité des cas, un DDNS suffit à joindre votre connexion par un nom stable. L'adresse fixe redevient utile pour trois choses : sortir d'un CGNAT, obtenir un enregistrement PTR cohérent (indispensable pour un serveur de messagerie), et éviter les coupures pendant la propagation du changement d'adresse.

Quel TTL mettre sur un enregistrement dynamique ?

60 secondes si votre adresse bouge souvent, 300 secondes sinon. Descendre à 30 ou moins n'apporte rien de mesurable : certains résolveurs appliquent un plancher et ignorent les valeurs très basses, et vous augmentez la charge de requêtes pour rien.

Puis-je utiliser mon propre nom de domaine plutôt qu’un sous-domaine gratuit ?

Oui. Deux méthodes : pointer un CNAME de maison.example.com vers le nom fourni par le service DDNS, ou mettre à jour un A directement via l'API de votre registrar. Attention, un CNAME est interdit à l'apex de la zone (example.com sans sous-domaine) par le modèle de la RFC 1034 ; il faut alors un A mis à jour par API, ou un enregistrement de type ALIAS si votre hébergeur DNS en propose un.

Le DNS dynamique met-il aussi à jour le reverse (PTR) ?

Non. La zone inverse correspondant à votre adresse publique appartient à l'opérateur, vous ne pouvez pas y écrire. Seul l'opérateur peut y déclarer un PTR, et rares sont les offres grand public qui le permettent.

Mon client renvoie nochg en boucle, est-ce grave ?

Oui, à terme. Le protocole dyndns2 considère la répétition d'une mise à jour identique comme un abus et certains fournisseurs bloquent le compte. Le client doit mémoriser la dernière adresse envoyée dans son fichier de cache et ne réémettre qu'en cas de changement réel.