DNS y resolución¶

Traducción automática del original francés.

Tres escenarios para el mismo nombre¶

*.savethemall.eu no resuelve a la misma dirección según desde dónde se solicita.

Desde	Servidor	Respuesta para `<x>.savethemall.eu`
Internet	Servidores OVH	`<IP publique>` — la IP WAN de la casa
LAN	AdGuard / CoreDNS	`vm-docker` — vm-docker en vivo
Tailnet	CoreDNS de tailnet	`<IP tailnet>` — vm-docker por tailnet

flowchart LR
    ext["Client<br/>sur Internet"]
    lan["Client<br/>sur le LAN"]
    ts["Client<br/>sur le tailnet"]

    ovh["Serveurs OVH"]
    adg["AdGuard / CoreDNS"]
    cts["CoreDNS du tailnet"]

    wan["<IP publique><br/>IP WAN → NAT → nas-caddy"]
    vmd1["vm-docker<br/>vm-docker en direct"]
    vmd2["<IP tailnet><br/>vm-docker par le tailnet"]

    ext --> ovh --> wan
    lan --> adg --> vmd1
    ts --> cts --> vmd2

    wan -.->|"le SEUL chemin<br/>qui traverse l'edge"| vmd1

Un mismo nombre, tres respuestas. Solo el camino superior atraviesa el NAT, nas-caddy y el certificado copiado en el NAS: las otras dos saltan todo eso y van directamente a vm-docker.

Probar desde la LAN no prueba la WAN

curl https://<fqdn>              # ne prouve RIEN sur le chemin public

Esta solicitud va directamente a vm-docker: salta el NAT del router, salta nas-caddy, salta el certificado copiado en el NAS. Un servicio puede responder perfectamente en la LAN y ser totalmente inaccesible desde Internet.

La prueba que verifica el verdadero camino:

curl --resolve <fqdn>:443:<IP publique> https://<fqdn>/

La zona OVH¶

Está gestionada por la API, no por la interfaz web. El script del parque lee los identificadores en el archivo de acme.sh, que solo es legible por root, y se ejecuta en vm-docker.

# lister, inspecter
ovh-record.sh list savethemall.eu A
ovh-record.sh show savethemall.eu A monservice

# créer (sans --apply : montre ce qui serait fait, n'écrit rien)
ovh-record.sh add savethemall.eu A monservice <IP publique> --apply

Dos trampas que evita el script¶

Una creación solo es visible después de una POST /refresh explícita. Sin ella, la API responde con 200, la interfaz de OVH muestra el registro, y los servidores autoritativos responden con NXDOMAIN — con la bandera aa, por lo que no parece una propagación en curso.
El campo subDomain toma solo la etiqueta monservice, nunca el FQDN. Introducir monservice.savethemall.eu crea monservice.savethemall.eu.savethemall.eu, que resuelve en vacío sin errores.

Un registro creado aquí se mantiene solo

Otro script (ovh-ddns.sh, cada 15 minutos) reescribe todos los registros A denominados de la zona hacia la IP WAN actual. Beneficio: la casa puede cambiar de IP sin causar ningún problema. Restricción: un registro A de esta zona no puede ser apuntado permanentemente desde otro lugar sin modificar este script.

Un problema de conectividad, no de resolución¶

Un dispositivo ubicado dentro de la subred anunciada por un nodo de salida, y configurado para aceptar las rutas anunciadas, pierde todo acceso a Internet: se envía a sí mismo a través de un túnel. Este modo de fallo ha dejado el Mac sin acceso durante 33 días. El síntoma no se parece a un problema de DNS, pero es ahí donde se debe empezar a investigar.

Dernière vérification de cette page : 2026-09-08