- DynIP est un service de DNS dynamique pour les homelabs, les routeurs edge et les équipes infra, avec des mises à jour en 60 secondes et une offre gratuite
- Prend en charge RFC 2136 TSIG, l’API REST et les mises à jour UDP/53, avec intégration à FortiGate, OPNsense, OpenWRT et MikroTik
- Prend en charge IPv6 en plus d’IPv4 pour mettre à jour les enregistrements A et AAAA côte à côte, aussi bien pour le dual stack que pour les zones IPv6 only
- DNSSEC automatise la génération des clés de signature, la publication dans la zone parente et la signature des enregistrements, et il est nécessaire pour émettre des certificats Let’s Encrypt
- Avec BYOD, il est possible de connecter son propre domaine pour créer des sous-domaines dynamiques, mais une délégation vers ns1.dynip.dev et ns2.dynip.dev est requise
Présentation de DynIP
- DynIP est un service de DNS dynamique pour les homelabs, les routeurs edge et les équipes infra, mettant en avant des mises à jour en 60 secondes, une offre gratuite, RFC 2136 TSIG, l’usage de son propre domaine et DNSSEC
- Le service est conçu pour que, lorsqu’un routeur envoie une mise à jour, le nom d’hôte soit correctement résolu partout dans le monde en environ 60 secondes
- Il propose un TTL de 60 secondes, une propagation basée sur NOTIFY et des serveurs de noms multi-régions
- Inscription gratuite et documentation
Standards DNS et intégration avec les routeurs
- Prend en charge RFC 2136 TSIG, ce qui permet une utilisation avec FortiGate, OPNsense, OpenWRT et les routeurs compatibles DNS UPDATE
- Les utilisateurs de MikroTik peuvent utiliser une intégration native via HTTP API
- Les méthodes prises en charge incluent RFC 2136 TSIG, l’API REST et les mises à jour natives via UDP/53
- L’écran des snippets de configuration permet de générer puis copier un bloc de configuration à partir du type d’appareil, de l’adresse IP cible, du domaine et de la clé TSIG
- Pendant la propagation d’une nouvelle zone vers les serveurs de noms, les mises à jour RFC 2136/TSIG de FortiGate doivent attendre
- Les mises à jour via HTTP API comme cURL, PowerShell, Python et MikroTik fonctionnent immédiatement
IPv6 et DNSSEC
- Prend en charge IPv6 en plus d’IPv4, afin de mettre à jour les enregistrements A et AAAA côte à côte
- Prend en charge à la fois les configurations dual stack et les zones IPv6 only
- Pour émettre des certificats Let’s Encrypt, DNSSEC doit être activé sur la zone concernée
- Une fois DNSSEC activé, la génération des clés de signature, la publication dans la zone parente et la signature de tous les enregistrements DNS sont effectuées automatiquement
- La configuration de DNSSEC est une procédure ponctuelle, après quoi la zone reste signée en continu
- Le temps estimé affiché est de 30 secondes
Démarrage rapide et gestion des zones
- Le démarrage rapide consiste à saisir le nom de l’appareil, choisir un domaine de base, puis cliquer sur Create Zone pour créer une zone
- Le bouton Snippets à côté du nouveau domaine permet de récupérer la configuration, de choisir le type d’appareil, puis de copier le bloc de configuration généré dans le CLI du routeur
- IPv4 et IPv6 sont détectés automatiquement à partir des connexions entrantes puis mis à jour
- La liste des zones affiche le domaine et les outils, l’IP actuelle, le secret TSIG, DNSSEC et l’état du certificat SSL
- Pour chaque zone, il est possible de gérer le verrouillage, les snippets, la suppression, les notifications, l’heure de synchronisation, l’activation ou la désactivation de DNSSEC, ainsi que le téléchargement, le renouvellement et l’émission des certificats SSL
Utiliser son propre domaine
- La fonction Custom Namespaces (BYOD) permet de connecter un domaine existant à DynIP et de créer des sous-domaines dynamiques sous cet espace de noms
- Pour activer l’espace de noms, il faut créer les deux enregistrements NS chez le bureau d’enregistrement du domaine
- Une délégation avec un seul NS est refusée
- Les enregistrements NS requis sont
ns1.dynip.dev et ns2.dynip.dev
- La validation de la configuration est fournie sous la forme d’un flux indiquant soit que la délégation est active, soit les actions nécessaires à effectuer chez le registrar
Synchronisation rapide et automatisation
- Quick Sync permet d’aligner immédiatement les zones sélectionnées sur l’adresse IP externe actuelle de l’appareil
- Le service affiche l’IP réseau détectée et permet à l’utilisateur de mettre à jour en une fois les zones choisies
- Il est possible d’enregistrer programmatiquement une nouvelle zone en envoyant une requête
POST vers le point de terminaison /register avec un jeton de session
curl -X POST "{{ backendUrl }}/register?subdomain=my-new-router&base_domain={{ baseDomains[0] }}" \
-H "Authorization: Bearer {{ token }}"
- Les jetons de session expirent lors de la déconnexion, il faut donc utiliser des jetons API pour l’automatisation à long terme
- Les API tokens sont une fonctionnalité Pro ou supérieure et peuvent être utilisés pour l’automatisation, comme les scripts de supervision, les pipelines CI ou les intégrations MSP
- Les jetons API n’expirent pas lors de la déconnexion, peuvent être limités à un accès en lecture seule ou complet, et peuvent être révoqués à tout moment
- Un nouveau jeton API n’est affiché qu’une seule fois lors de sa création, il faut donc le conserver dans un gestionnaire de mots de passe ou un coffre à secrets
Tarification et sécurité du compte
- L’écran des offres affiche le niveau d’abonnement, l’état, la date de renouvellement ou de fin d’accès, le cycle de facturation, le nombre de zones utilisées et le nombre maximal de domaines
- En cas de rétrogradation de l’offre, seules les plus anciennes zones dans la limite autorisée restent actives, tandis que les autres sont verrouillées et ne peuvent plus recevoir de mises à jour d’IP
- En cas d’échec de paiement, il faut mettre à jour le moyen de paiement pour conserver l’accès
- La sécurité du compte prend en charge la 2FA par e-mail et TOTP, et lorsque TOTP est activé, il remplace la 2FA par e-mail
- La configuration de TOTP consiste à scanner un QR code avec Google Authenticator, Authy ou l’application 2FA de son choix, puis à valider le code
Liens associés
1 commentaires
Avis sur Hacker News
Je suis Daniel, ingénieur réseau en Suède, et j’ai créé DynIP parce que j’avais l’impression que les services DDNS existants étaient restés bloqués sur les réseaux des années 2010
Les mêmes problèmes revenaient sans cesse : protocole de mise à jour propriétaire limité à HTTP, prise en charge IPv6 faible, absence de DNSSEC, support insuffisant du matériel récent ; DynIP traite donc les mises à jour RFC 2136 / TSIG comme voie de premier ordre
Le DDNS générique de FortiGate et
/tool dns-updatede MikroTik fonctionnent sans client séparé, et une API HTTP est aussi fournie pour les autres usagesLes serveurs DNS faisant autorité sont accessibles en IPv6, un glue AAAA est publié dans la zone parente
.dev, et les zones clientes publient des enregistrements A/AAAA tout en prenant aussi en charge les clients IPv6-onlySur certaines zones, DNSSEC peut être activé d’un simple bouton, et il est possible d’apporter son propre domaine via une délégation de sous-domaine
L’architecture repose sur un primary caché qui ne reçoit pas de trafic public, ainsi que sur deux secondary géographiquement répartis en Suède et en Suisse, qui valident TSIG localement avant de relayer vers le primary
Les adresses RFC 1918 et CGNAT sont aussi autorisées dans les enregistrements, afin que des flottes cellulaires sur APN privé puissent utiliser des noms d’hôte DNS publics stables pointant vers des IP internes
Il existe aussi un petit conteneur Docker,
ghcr.io/33k-org/dynip-updater, et la stack repose sur PowerDNS 4.8 authoritative, FastAPI, Postgres, Postfix, Cloudflare et Paddle ; le service tourne surdynip.devet propose aussi une offre gratuiteIl propose IPv6, DNSSEC, l’utilisation de son propre domaine et d’autres fonctions, et c’est à la fois un projet open source et un service d’hébergement gratuit stable
J’ai peut-être raté l’info dans la documentation, mais il semble aussi y avoir ici une prise en charge de la délégation de préfixe IPv6, qui permet de ne mettre à jour que le préfixe réseau d’un domaine donné lorsque le préfixe IPv6 attribué au routeur par le FAI change
En Europe, ce préfixe n’est souvent pas fixe et change à chaque reconnexion au FAI, donc le fait de conserver la partie hôte tout en ne mettant à jour automatiquement que la partie réseau est utile
Exemple :
/update?myipv6:nas.home.mydomain.tld=2003:e6:bee:affe::/56En cliquant sur le lien de confirmation reçu par e-mail, il n’y a absolument aucun message de confirmation ni indication d’état, ce qui est assez déroutant
Si l’on est connecté, le lien redirige vers l’accueil du tableau de bord ; comme l’utilisateur reçoit généralement l’e-mail juste après avoir cliqué sur le bouton de changement de mot de passe, il doit d’abord se déconnecter
Ce serait plus fluide d’ajouter dans l’e-mail une mention du type « déconnectez-vous d’abord », ou que le lien ferme la session en cours avant d’afficher la page de réinitialisation
Il me semble me souvenir vaguement que ce genre de chose était considéré comme un tabou en sécurité
Le pitch a l’air vraiment bon, mais je n’ai pas le temps de l’essayer tout de suite
Cela dit, si je n’avais pas lu l’explication dans les commentaires ici, j’aurais probablement fermé l’onglet dès la landing page
Désolé d’être aussi direct, mais la page ressemble à une landing page générique au style IA ; je ne dis pas que c’est réellement le cas, mais comme l’explication est bonne, ce serait bien d’y mettre davantage de personnalité pour la différencier
Et mieux vaut éviter de créer un compte Hacker News dédié au projet
« N’utilisez pas comme nom d’utilisateur le nom d’une entreprise ou d’un projet. Cela donne l’impression que vous utilisez HN à des fins promotionnelles et que vous ne participez pas en tant que personne. Vous n’avez pas besoin d’utiliser votre vrai nom, mais votre pseudo doit signaler que vous êtes perçu ici comme un être humain, pas comme une marque. Si vous voulez changer de nom d’utilisateur, écrivez à hn@ycombinator.com. »
https://news.ycombinator.com/item?id=22336638
https://news.ycombinator.com/showhn.html peut aussi être utile
J’en suis à un stade où il y a ce que je sais et ce que je ne sais pas, des espoirs et des rêves, et un assez gros bloc de connaissances techniques ; je ne suis pas très fort en design, mais pour l’instant ça me va
D’après Pangram, c’est du 100 %, et franchement on pourrait le reconnaître même sans ce genre d’outil ; le fait qu’il y ait encore pas mal de gens ici qui n’arrivent pas à le distinguer est assez déprimant
C’est une bonne chose de voir arriver de la concurrence dans ce domaine
Cela dit, si l’on veut auto-héberger sans trop se soucier de la fiabilité ou de la facilité d’usage, bind9 prend aussi en charge RFC 2136 DNS UPDATE et DNSSEC
Dans ma configuration, mon routeur domestique ne sait pas parler DNS UPDATE, donc j’ai aussi écrit un petit exécutable Go qui convertit les requêtes HTTP
J’ai créé quelques cas de test sur FortiGate, et DynIP a d’ailleurs commencé comme une simple adaptation interne de DNS, copiée-collée pour un usage spécifique à FortiGate
Il existe des exemples de code utilisables en interne sur plusieurs hôtes Windows ou Linux, et si vous avez des appareils IoT dans votre homelab, il y a aussi des exemples Arduino
Créer un exécutable Go est également une bonne direction, donc n’hésitez pas à surveiller les mises à jour sous
/docsLa prise en charge de RFC 2136 mérite des points bonus, et ça fonctionne facilement avec external-dns
Cela fait des années que j’utilise Kubernetes on-premise avec external-dns, avec un serveur BIND auto-hébergé en configuration minimale sur un hôte public
Il existe déjà des guides d’exploitation de flotte, et le modèle Kubernetes est une extension naturelle, donc ça vaudrait le coup d’écrire un guide
Avant, j’écrivais moi-même des scripts OpenWrt DDNS pour mettre à jour AWS Route 53 ou Cloudflare DNS, et cela suffisait largement
Depuis l’arrivée de Tailscale, je ne me soucie plus du DDNS ni du CGNAT
J’ai rédigé un guide sur https://dynip.dev/guides/tailscale pour expliquer comment et pourquoi ils peuvent coexister
Les scripts OpenWrt DDNS sont un peu pénibles à cause des clés et des secrets, mais la fonction de snippet évite d’avoir à se demander « comment ça marche ? », donc j’en suis plutôt satisfait
J’utilise DynIP pour les services publics, et Tailscale pour ce qui ne doit être accessible qu’à moi, ce qui réduit fortement la surface d’attaque
Heureusement, je n’ai pas à me soucier du CGNAT
J’ai essayé de m’inscrire, mais l’e-mail de vérification n’arrive pas
Juste après l’inscription, il n’y avait rien non plus dans les logs du serveur mail, et même après avoir demandé plusieurs renvois, il n’y avait toujours rien dans la boîte de réception 6 à 7 heures plus tard
Je me demande si le token d’authentification de l’offre gratuite expire bien au bout de 24 heures
J’ai regardé la claim
expdu JWT, et je voudrais clarifier ce point avant d’investir du temps dans une migrationLa vraie question, c’est si l’offre gratuite est viable dans la durée
Toutes les zones reçoivent leur propre clé TSIG sur toutes les offres, et ce sont ces clés qui gèrent les mises à jour réelles
L’offre gratuite permet de gérer les zones via le tableau de bord, et les offres payantes ajoutent des tokens d’API pour la gestion programmatique
Le token d’authentification sert donc de bearer pour l’API, tandis que la TSIG reste valide tant que le domaine n’est pas supprimé
L’offre gratuite autorise 5 zones, chacune avec sa propre clé TSIG toujours active, donc sauf si vous créez, mettez à jour et supprimez des centaines de zones, il n’y a pas besoin de payer
Merci pour tous ces excellents commentaires et questions ; je vais continuer à suivre le fil en rentrant après avoir emmené ma fille à son cours de natation pendant quelques heures
Je me demande si vous avez aussi envisagé quelque chose comme https://github.com/hickory-dns/hickory-dns
Bien sûr, pas besoin de tout faire en Rust
Ça a l’air intéressant, et j’utilise le DDNS pour exposer plusieurs services de mon serveur domestique à des clients externes
En ce moment, j’utilise NO-IP DDNS et son offre gratuite est assez généreuse, mais ce qui me gêne, c’est l’absence de prise en charge de Let’s Encrypt
J’envisage d’acheter un domaine chez Cloudflare, mais je me demande concrètement ce que DynIP apporte de différent
Les mises à jour HTTP(S) uniquement à l’ancienne, façon années 2000, c’est bien aussi
Avec seulement
curl,wgetoufetch, ça marche partout, et si on veut, il suffit d’ajouter un tokenIl me semble que duckdns prend toujours en charge cette méthode aussi, et comme il n’y a pas besoin de client dédié, ça fonctionne presque partout
curl/wget/fetchest tout à fait valable, et il suffit d’aller voir les autres fonctions spécifiques possibles dans/docsL’idée ici n’est pas de se limiter à
curl/wget/fetch, mais de couvrir une base fonctionnelle plus large