Fonctionnement

En attente

le changement est enregistré, pas encore publié

Appliqué

le serveur primaire publie la nouvelle adresse

Servi

ns1, ns2 et ns3 publient l’adresse

Sans adresse

aucun enregistrement A ni AAAA

Suspendu

retiré de la zone par l’administration

Erreur

la publication a échoué ; elle est retentée automatiquement

Une mise à jour DynDNS2 répond good une fois l’adresse publiée par le serveur primaire, en général en une ou deux secondes. Les trois serveurs publics la reçoivent ensuite en quelques secondes. Les enregistrements ont un TTL de 60 secondes : un résolveur qui avait gardé l’ancienne adresse la remplace en général dans la minute.

Les deux familles sont indépendantes. Sans paramètre myip, seule la famille de la connexion change : une requête arrivée en IPv4 ne touche pas l’adresse IPv6. api4.nomadns.net et api6.nomadns.net permettent à un client de mettre à jour chaque famille séparément.

La zone est servie par ns1, ns2 et ns3, chez deux hébergeurs différents. Elle est signée par DNSSEC. Chaque jeton ne sert qu’à un sous-domaine et à un usage ; son secret n’est jamais stocké en clair.

Pour modifier plusieurs adresses à la fois, l’éditeur de fichier de zone (lien sur la fiche) accepte les enregistrements A et AAAA des sous-domaines du compte, au format DNS. Il affiche un aperçu des ajouts, modifications et retraits avant de les appliquer.

120 requêtes par heure et par sous-domaine, 60 changements d’adresse par jour et par sous-domaine, 10 échecs d’authentification par 10 minutes et par adresse IP. Au-delà, la réponse est abuse ou badauth jusqu’à la fin de la fenêtre. La rotation du jeton ne réinitialise pas ces limites. Les modifications web et les imports comptent dans le budget quotidien DynDNS, mais restent toujours possibles.

Connexion à l’espace : 10 échecs par 10 minutes et par adresse IP, 20 par heure et par compte. Au-delà, la connexion est refusée jusqu’à la fin de la fenêtre, même avec le bon mot de passe.