El DNS dinámico actualiza la dirección incorrecta cuando el actualizador observa una interfaz o salida a internet diferente a la que los clientes remotos deben alcanzar.
En una red doméstica, el router puede reportar una dirección WAN privada detrás de otro gateway, un actualizador del lado del servidor puede ver una salida VPN o proxy, un actualizador IPv6 puede sobrescribir un registro IPv4, o dos clientes pueden actualizar el mismo nombre de host desde diferentes ubicaciones. El diagnóstico comienza eligiendo una fuente de verdad de dirección pública y luego identificando exactamente qué actualizador, registro, familia de direcciones y método de detección produjo el valor incorrecto.
Compare Tres Direcciones al Mismo Tiempo
Registre el registro DDNS, la dirección WAN del router y la dirección pública observada por un servicio externo IPv4 o IPv6. Añada marcas de tiempo para que un cambio reciente legítimo no se confunda con una actualización incorrecta.
Un caso en la comunidad TP-Link mostró un router reportando una dirección de un pool NAT del proveedor mientras que el internet externo veía una dirección diferente, dejando el nombre de host DDNS apuntando a la dirección incorrecta del lado WAN.
Si las tres coinciden, el problema probablemente sea caché DNS o accesibilidad remota en lugar del valor de actualización. Si el registro DDNS coincide con el router pero no con la dirección externa, investigue NAT ascendente; si no coincide con ninguno, inspeccione la configuración y los registros del actualizador.
Identifique Cómo el Actualizador Detecta la Dirección
Determine si el cliente DDNS lee una interfaz nombrada, consulta al router, analiza un gateway local, usa la dirección fuente de la solicitud de actualización o consulta un servicio externo de “cuál es mi IP”.
Una discusión en la comunidad Zyxel pregunta por qué un firewall detrás de otro router NAT no puede actualizar automáticamente la verdadera dirección pública cuando solo conoce la dirección WAN privada ascendente.
Elija detección externa cuando el actualizador esté detrás de NAT y el proveedor lo soporte. Elija detección por interfaz solo cuando esa interfaz realmente posea la dirección pública; de lo contrario, un actualizador que funciona perfectamente puede publicar el valor incorrecto por diseño.
Verifique Doble NAT y CGNAT
Inspeccione si la dirección WAN del router está dentro de un rango privado o compartido y si otro módem o gateway ISP realiza el primer NAT. El DNS dinámico puede publicar una dirección, pero no puede crear reenvío entrante a través de una red ascendente que no controla.
Un caso en el foro de soporte alemán de Synology reportó que el NAT del proveedor causó que DDNS detectara una dirección que no era el punto final público real.
Si controla el router ascendente, coloque el router descendente en modo puente o reenvíe la ruta requerida a través de ambas capas. Si el ISP usa CGNAT, solicite una dirección pública o use un túnel o relé saliente en lugar de cambiar repetidamente el cliente DDNS.
Separe las Actualizaciones IPv4 e IPv6
Inspeccione los registros A y AAAA independientemente y compare cada uno con una prueba externa para la misma familia de direcciones. No asuma que una actualización IPv6 exitosa prueba que el registro IPv4 es correcto.
Un cliente configurado para monitorear una interfaz puede publicar una dirección IPv6 temporal, una dirección de prefijo delegado que luego cambia, o una dirección IPv4 desde una salida VPN. Mantenga trabajos de actualización y registros de proveedor separados cuando las familias de direcciones tengan ciclos de vida diferentes.
Desactive solo la actualización de la familia de direcciones sospechosa y repita la prueba. Si el acceso remoto se recupera cuando se elimina el registro AAAA o A incorrecto, repare esa ruta antes de restaurar el DNS de doble pila.
Encuentre Clientes Duplicados y Objetivos de Registro Incorrectos
Liste cada router, NAS, contenedor, script, host en la nube y dispositivo móvil que tenga credenciales para actualizar el nombre de host. Dos clientes válidos en diferentes ubicaciones pueden sobrescribirse repetidamente.
Usuarios de Dynu han documentado casos donde un cliente de actualización causó que múltiples registros compartieran una IP porque la cuenta o configuración del cliente apuntaba a más registros de los previstos.
Dé a cada ubicación y familia de direcciones un nombre de host, token y trabajo de actualización distintos. Revoque credenciales no usadas y confirme que el registro nombre el registro exacto que se está cambiando antes de confiar en un mensaje de éxito.
Valide el Registro Mediante un Cambio Real de Dirección
Después de corregir el método de detección y la propiedad del actualizador, fuerce una reconexión WAN segura o espere el próximo cambio legítimo de dirección. Registre la nueva dirección externa, el registro de actualización, la respuesta DNS autorizada, la respuesta del resolvedor recursivo y el resultado de la conexión remota.
La guía de ZimaSpace sobre por qué el acceso remoto sigue un estado IP antiguo proporciona la siguiente etapa después de que el valor DDNS en sí se vuelve correcto.
El problema se resuelve solo cuando un actualizador aprobado publica la dirección IPv4 o IPv6 correcta, ningún segundo cliente la sobrescribe, la respuesta autorizada cambia dentro del intervalo esperado y un cliente externo alcanza el servicio doméstico previsto.
Soporte y Consejos
Más para leer

How to Reduce Plex Database Contention on a Busy Docker Host
A Plex configuration guide for busy hosts that treats the database as local application state and reduces I/O contention without inventing a shared DB...

How to Prevent Duplicate Plex Scans and Imports
A prevention guide for duplicate Plex scans and imports that removes overlapping triggers instead of disabling library updates entirely.

How to Recover Plex After Its App-Data Volume Fills Up
A recovery ladder for full Plex app-data volumes that protects the database first and avoids deleting unknown files just to make the service start.

