DDNS : garder un nom stable devant une IP qui change

Le DDNS (Dynamic DNS) fait pointer en permanence un nom d'hôte vers l'adresse IP publique de votre connexion, même quand votre opérateur vous en attribue une nouvelle : un petit client tourne sur la box, le NAS ou un serveur, détecte le changement et prévient le fournisseur DNS. Deux mécanismes très différents portent ce nom, le protocole DNS UPDATE du RFC 2136 côté entreprise et l'API HTTP des services grand public type No-IP ou DuckDNS.

Le problème que le DDNS résout

Votre box reçoit une adresse IP publique de votre opérateur, et cette adresse peut bouger : à chaque redémarrage chez certains FAI, une fois par jour chez d'autres, jamais pendant six mois puis un mardi matin sans prévenir. Tant que vous naviguez, cela n'a aucune conséquence. Le jour où vous voulez joindre votre NAS depuis le bureau, ou laisser un collègue tester une application hébergée chez vous, il faut un nom stable devant une adresse instable.

Le DDNS ajoute une boucle de retour au DNS classique. Un logiciel installé chez vous surveille l'adresse publique de la connexion et, dès qu'elle change, écrit la nouvelle valeur dans l'enregistrement A (ou AAAA en IPv6). Le nom reste maison.example.net, la valeur derrière évolue toute seule.

Le DNS ordinaire suppose des valeurs écrites à la main et modifiées rarement. Le DDNS part de l'hypothèse inverse.

Deux technologies derrière le même sigle

Le sigle DDNS recouvre deux choses qui n'ont presque rien en commun, ce qui explique une bonne partie des malentendus dans les documentations et les forums.

La première est normalisée. Le message DNS UPDATE décrit par le RFC 2136 (1997) permet à un client d'ajouter, de supprimer ou de remplacer des enregistrements dans une zone en s'adressant directement au serveur faisant autorité. Le RFC 3007 y greffe l'authentification, en pratique une clé partagée TSIG (RFC 8945) ou GSS-TSIG dans un domaine Active Directory, où chaque poste Windows enregistre lui-même son A et son PTR. La commande nsupdate de BIND fait exactement cela : nsupdate -k Kmaison.+165+12345.key, puis update add maison.example.net 60 A 203.0.113.24 et send.

La seconde n'est normalisée nulle part. C'est l'API HTTP inventée par DynDNS à la fin des années 1990, recopiée depuis par No-IP, DuckDNS, Dynu, OVH, Cloudflare et la quasi-totalité des firmwares de routeurs. Le client envoie une requête HTTPS avec ses identifiants, le fournisseur écrit dans sa propre zone. Vous ne touchez jamais à un serveur DNS.

Critère	DNS UPDATE (RFC 2136)	API HTTP (type DynDNS)
Transport	Message DNS, port 53 UDP ou TCP	Requête HTTPS, port 443
Authentification	Clé TSIG ou GSS-TSIG	HTTP Basic ou jeton d'API
Qui détient la zone	Vous, sur votre serveur autoritaire	Le fournisseur, dans son domaine
Outils courants	nsupdate, dhcpd, Windows Server	ddclient, inadyn, firmware de box
Normalisé	Oui	Non, convention de fait

L’appel de mise à jour, ligne par ligne

La requête grand public est d'une simplicité qui surprend quand on la voit pour la première fois : curl -u pseudo:motdepasse 'https://dynupdate.no-ip.com/nic/update?hostname=maison.ddns.net&myip=203.0.113.24'. Les identifiants circulent en clair dans l'en-tête Basic, d'où l'obligation du HTTPS.

La réponse tient en une ligne de texte brut, sans JSON ni code de statut parlant : un HTTP 200 peut très bien transporter une erreur. Un client qui ne lit pas ce corps de réponse finit par se faire bloquer.

Sous Linux, ddclient fait ce travail depuis /etc/ddclient.conf avec un intervalle typique de 300 secondes (daemon=300). Sur OpenWrt c'est le paquet ddns-scripts, sur un Synology l'onglet Accès externe du panneau de configuration. Tous envoient la même requête.

Réponse	Signification	Réaction attendue
good 203.0.113.24	Enregistrement mis à jour	Mémoriser l'IP et se taire
nochg	Adresse déjà enregistrée	Cesser de renvoyer la même valeur
badauth	Identifiants refusés	Arrêter, surtout ne pas boucler
nohost	Nom d'hôte inconnu du compte	Corriger la configuration
abuse	Compte bloqué pour excès de requêtes	Contacter le fournisseur
911	Panne côté fournisseur	Réessayer au bout de 30 minutes

TTL, cache et fréquence des mises à jour

Un enregistrement DDNS se publie avec un TTL court, 60 secondes chez la plupart des fournisseurs, parfois 30. C'est le seul moyen pour que les résolveurs oublient vite l'ancienne adresse. La contrepartie : presque chaque visite déclenche une vraie requête vers le serveur autoritaire au lieu de lire un cache, ce qui rend ces noms peu adaptés à un site à fort trafic. Un dig maison.ddns.net vous montre le TTL restant qui décompte à chaque interrogation.

Ce TTL reste une indication. Certains résolveurs appliquent un plancher, et beaucoup d'applications gardent la résolution en mémoire pour toute leur durée de vie : la JVM met en cache les résolutions réussies 30 secondes par défaut, et indéfiniment lorsqu'un security manager est actif (networkaddress.cache.ttl). Quand un tunnel VPN ne se rétablit pas après un changement d'IP, le coupable est presque toujours là, pas dans la zone DNS.

Côté rythme, la règle des fournisseurs ne varie pas : on écrit quand l'adresse change, pas toutes les minutes. Vérifier son IP toutes les 5 minutes et n'envoyer une requête qu'en cas de différence est le comportement attendu. Renvoyer la même valeur en boucle vaut une réponse abuse, puis un compte suspendu.

Les comptes gratuits No-IP ajoutent une contrainte que peu de gens notent à l'installation : le nom d'hôte doit être confirmé manuellement tous les 30 jours, sinon il est supprimé. C'est la première cause des accès qui tombent d'un seul coup après un mois de fonctionnement irréprochable.

Ce qui casse en vrai

Le DDNS lui-même tombe rarement en panne. Ce sont ses conditions d'usage qui se dérobent, presque toujours pour l'une de ces raisons.

• CGNAT : votre box n'a pas d'adresse publique à elle. Le client publie fidèlement une adresse partagée avec des centaines d'abonnés, et aucune redirection de port ne peut aboutir. Test immédiat : si l'IP WAN affichée par la box tombe entre 100.64.0.0 et 100.127.255.255, l'espace partagé du RFC 6598, vous êtes derrière un NAT opérateur. Demandez une IPv4 publique, souvent accordée gratuitement sur simple demande, ou basculez vos accès en IPv6.
• Double NAT : le client tourne sur une machine placée derrière un second routeur et publie 192.168.1.42. Le nom résout vers une adresse privée et personne ne le joint depuis l'extérieur.
• Paramètre myip omis : le fournisseur utilise alors l'adresse source de la requête. Si celle-ci sort en IPv6, vous inscrivez une valeur IPv6 là où votre configuration attend une IPv4.
• IPv6 à moitié géré : le client met à jour le A et laisse le AAAA figé sur une ancienne valeur. Les visiteurs en IPv6 sont les seuls à voir la panne, ce qui rend le diagnostic pénible. Publiez les deux familles ou aucune.
• Identifiants périmés : mot de passe changé, jeton régénéré, réponse badauth pendant trois semaines dans un journal que personne ne consulte.

Certificat TLS et exposition d’un nom DDNS

Un nom DDNS est public, prévisible et scanné en permanence : les plages des grands fournisseurs sont balayées en continu par des robots. Exposer le port 3389 (RDP) ou 5900 (VNC) derrière un nom en .ddns.net revient à publier une invitation. Ouvrez plutôt un seul port UDP pour WireGuard, 51820 par défaut, et faites passer le reste dans le tunnel.

Pour obtenir un certificat sur ce nom, la validation HTTP-01 fonctionne si le port 80 est joignable depuis Internet. Sinon il faut DNS-01, que peu de services DDNS gratuits exposent par API. Autre détail qui piège : les domaines des gros fournisseurs figurent sur la Public Suffix List, ils comptent donc comme des domaines racines distincts pour la portée des cookies et pour les limites de délivrance de Let's Encrypt. Votre voisin qui abuse du même suffixe ne consomme pas votre quota.

Questions fréquentes

Le DDNS est-il gratuit ?

En partie. DuckDNS et les offres gratuites de No-IP couvrent un usage domestique, avec des contraintes (un ou trois noms d'hôte, confirmation tous les 30 jours chez No-IP). DynDNS a supprimé son offre gratuite en 2014. Si vous possédez déjà un nom de domaine, la solution la plus propre reste un script qui appelle l'API de votre hébergeur DNS : pas de suffixe étranger, pas de date d'expiration à surveiller.

Ai-je encore besoin d’une IP fixe avec un DDNS ?

Non pour joindre une machine par son nom, c'est précisément ce que le DDNS remplace. Oui dans deux cas : si votre opérateur vous place derrière un CGNAT, aucune redirection de port n'est possible sans adresse publique dédiée, et si vous hébergez un serveur de messagerie, les plages dynamiques étant listées comme telles par la plupart des filtres antispam.

Quelle différence entre DDNS et DNS classique ?

Le protocole de résolution est identique, seul le mode d'écriture change. En DNS classique un humain modifie la zone chez le registrar ou l'hébergeur, avec des TTL de quelques heures. En DDNS un programme écrit l'enregistrement automatiquement, avec un TTL de 60 secondes pour que le changement se propage vite.

Puis-je utiliser mon propre nom de domaine avec un service DDNS ?

Oui, par un CNAME de acces.mondomaine.fr vers maison.ddns.net. Le client continue de mettre à jour le nom du fournisseur, votre alias suit. Une limite à connaître : un CNAME est interdit à la racine du domaine (mondomaine.fr tout court), il faut alors un enregistrement de type ALIAS ou l'aplatissement proposé par certains hébergeurs, ou publier directement le A par API.

Combien de temps après un changement d’IP le nom redevient-il joignable ?

Comptez le délai de détection du client, souvent jusqu'à 5 minutes, plus l'expiration du TTL, 60 secondes en général. Une à six minutes en pratique. Les clients qui restent longtemps injoignables gardent presque toujours l'ancienne réponse en cache dans l'application elle-même, pas dans le DNS.

Testez vos connaissances

À lire aussi

changer adresse ip · commande dig · box internet · cloudflare dns 1 1 1 1