DNS et résolution¶

Trois horizons pour un même nom¶

*.savethemall.eu ne résout pas vers la même adresse selon d'où l'on demande.

Depuis	Résolveur	Réponse pour `<x>.savethemall.eu`
Internet	Serveurs OVH	`<IP publique>` — l'IP WAN de la maison
LAN	AdGuard / CoreDNS	`vm-docker` — vm-docker en direct
Tailnet	CoreDNS du tailnet	`<IP tailnet>` — vm-docker par le 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 même nom, trois réponses. Seul le chemin du haut traverse le NAT, nas-caddy et le certificat copié sur le NAS : les deux autres sautent tout ça et vont droit sur vm-docker.

Tester depuis le LAN ne teste pas le WAN

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

Cette requête part directement sur vm-docker : elle saute le NAT du routeur, saute nas-caddy, saute le certificat copié sur le NAS. Un service peut répondre parfaitement en LAN et être totalement injoignable depuis Internet.

Le test qui porte sur le vrai chemin :

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

La zone OVH¶

Elle est gérée par l'API, pas par l'interface web. Le script du parc lit les identifiants dans le fichier de compte d'acme.sh, lisible par root seulement, et s'exécute sur 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

Deux pièges que le script évite¶

Une création n'est visible qu'après un POST /refresh explicite. Sans lui, l'API répond 200, l'interface OVH affiche l'enregistrement, et les serveurs autoritatifs répondent NXDOMAIN — avec le drapeau aa, donc ça ne ressemble pas à une propagation en cours.
Le champ subDomain prend le label seul (monservice), jamais le FQDN. Saisir monservice.savethemall.eu crée monservice.savethemall.eu.savethemall.eu, qui résout dans le vide sans erreur.

Un enregistrement créé ici se maintient tout seul

Un autre script (ovh-ddns.sh, toutes les 15 minutes) réécrit tous les enregistrements A nommés de la zone vers l'IP WAN courante. Bénéfice : la maison peut changer d'IP sans rien casser. Contrainte : un enregistrement A de cette zone ne peut pas être pointé durablement ailleurs sans toucher à ce script.

Un piège de connectivité, pas de résolution¶

Un appareil situé dans le sous-réseau annoncé par un nœud de sortie, et configuré pour accepter les routes annoncées, perd tout accès à Internet : il s'envoie à lui-même par un tunnel. Ce mode de panne a coupé le Mac pendant 33 jours. Le symptôme ne ressemble pas à du DNS, mais c'est là qu'on cherche d'abord.

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