Pourquoi le DNS dynamique met-il à jour la mauvaise adresse publique ?

Le DNS dynamique met à jour la mauvaise adresse lorsque le client de mise à jour observe une interface ou une sortie Internet différente de celle que les clients distants doivent atteindre.

Dans un réseau domestique, le routeur peut signaler une adresse WAN privée derrière une autre passerelle, un client de mise à jour côté serveur peut voir une sortie VPN ou proxy, un client IPv6 peut écraser un enregistrement IPv4, ou deux clients peuvent mettre à jour le même nom d’hôte depuis des emplacements différents. Le diagnostic commence par choisir une source de vérité unique pour l’adresse publique, puis par identifier précisément quel client de mise à jour, quel enregistrement, quelle famille d’adresses et quelle méthode de détection ont produit la mauvaise valeur.

Comparer Trois Adresses en Même Temps

Notez l’enregistrement DDNS, l’adresse WAN du routeur et l’adresse publique observée par un service externe IPv4 ou IPv6. Ajoutez des horodatages pour ne pas confondre un changement récent légitime avec une mise à jour erronée.

Un cas dans la communauté TP-Link a montré un routeur signalant une adresse provenant d’un pool NAT du fournisseur alors que l’Internet extérieur voyait une adresse différente, laissant le nom d’hôte DDNS pointé vers la mauvaise adresse côté WAN.

Si les trois correspondent, le problème est probablement un cache DNS ou une accessibilité distante plutôt que la valeur de mise à jour. Si l’enregistrement DDNS correspond au routeur mais pas à l’adresse externe, examinez le NAT en amont ; s’il ne correspond à aucun des deux, inspectez la configuration et les journaux du client de mise à jour.

Identifier Comment le Client de Mise à Jour Détecte l’Adresse

Déterminez si le client DDNS lit une interface nommée, interroge le routeur, analyse une passerelle locale, utilise l’adresse source de la requête de mise à jour ou interroge un service externe « quel est mon IP ».

Une discussion dans la communauté Zyxel demande pourquoi un pare-feu derrière un autre routeur NAT ne peut pas automatiquement mettre à jour la véritable adresse publique alors qu’il ne connaît que l’adresse WAN privée en amont.

Choisissez la détection externe lorsque le client est derrière un NAT et que le fournisseur la prend en charge. Choisissez la détection d’interface uniquement lorsque cette interface possède réellement l’adresse publique ; sinon, un client parfaitement fonctionnel peut publier par conception une mauvaise valeur.

Vérifier la Double NAT et le CGNAT

Vérifiez si l’adresse WAN du routeur se trouve dans une plage privée ou partagée et si un autre modem ou passerelle ISP effectue le premier NAT. Le DNS dynamique peut publier une adresse, mais il ne peut pas créer de redirection entrante à travers un réseau en amont que vous ne contrôlez pas.

Un cas dans le forum de support Synology en Allemagne a signalé que le NAT du fournisseur a fait que le DDNS détectait une adresse qui n’était pas le point d’extrémité public réel.

Si vous contrôlez le routeur en amont, placez le routeur en aval en mode pont ou redirigez le chemin requis à travers les deux couches. Si l’ISP utilise le CGNAT, demandez une adresse publique ou utilisez un tunnel ou relais sortant plutôt que de changer sans cesse le client DDNS.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Séparer les Mises à Jour IPv4 et IPv6

Examinez indépendamment les enregistrements A et AAAA et comparez chacun avec un test externe pour la même famille d’adresses. Ne supposez pas qu’une mise à jour IPv6 réussie prouve que l’enregistrement IPv4 est correct.

Un client configuré pour surveiller une interface peut publier une adresse IPv6 temporaire, une adresse de préfixe délégué qui change ensuite, ou une adresse IPv4 provenant d’une sortie VPN. Gardez des tâches de mise à jour et des enregistrements fournisseurs séparés lorsque les familles d’adresses ont des cycles de vie différents.

Désactivez uniquement la mise à jour de la famille d’adresses suspecte et répétez le test. Si l’accès distant est rétabli lorsque l’enregistrement AAAA ou A incorrect est supprimé, réparez ce chemin avant de restaurer le DNS double pile.

Trouver les Clients Dupliqués et les Mauvaises Cibles d’Enregistrement

Listez chaque routeur, NAS, conteneur, script, hôte cloud et appareil mobile ayant les identifiants pour mettre à jour le nom d’hôte. Deux clients valides à différents emplacements peuvent s’écraser mutuellement à plusieurs reprises.

Les utilisateurs Dynu ont documenté des cas où un client de mise à jour a causé que plusieurs enregistrements partagent une même IP parce que la configuration du compte ou du client ciblait plus d’enregistrements que prévu.

Attribuez à chaque emplacement et famille d’adresses un nom d’hôte, un jeton et une tâche de mise à jour distincts. Révoquez les identifiants inutilisés et confirmez que le journal nomme précisément l’enregistrement modifié avant de faire confiance à un message de succès.

Valider l’Enregistrement par un Vrai Changement d’Adresse

Après avoir corrigé la méthode de détection et la propriété du client de mise à jour, forcez une reconnexion WAN sécurisée ou attendez le prochain changement légitime d’adresse. Notez la nouvelle adresse externe, le journal de mise à jour, la réponse DNS autoritaire, la réponse du résolveur récursif et le résultat de la connexion distante.

Le guide ZimaSpace expliquant pourquoi l’accès distant suit un ancien état IP fournit l’étape suivante après que la valeur DDNS elle-même soit correcte.

Le problème est résolu uniquement lorsqu’un client de mise à jour approuvé publie la bonne adresse IPv4 ou IPv6, qu’aucun second client ne l’écrase, que la réponse autoritaire change dans l’intervalle attendu, et qu’un client externe atteint le service domestique prévu.