DNS and Resolution¶

Machine translation of the French original.

Three different responses for the same name¶

*.savethemall.eu does not resolve to the same address depending on where the request is made.

Source	Resolver	Response for `<x>.savethemall.eu`
Internet	OVH servers	`<IP publique>` — the WAN IP of the home
LAN	AdGuard / CoreDNS	`vm-docker` — live vm-docker
Tailnet	Tailnet CoreDNS	`<IP tailnet>` — vm-docker via the 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

The same name, three different responses. Only the top path traverses the NAT, nas-caddy, and the certificate copied to the NAS: the other two bypass all of this and go directly to vm-docker.

Testing from the LAN does not test the WAN

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

This request goes directly to vm-docker: it bypasses the router's NAT, bypasses nas-caddy, and bypasses the certificate copied to the NAS. A service can function perfectly on the LAN and be completely unreachable from the Internet.

The test that actually tests the real path:

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

The OVH zone¶

It is managed via the API, not the web interface. The script reads the credentials from the acme.sh account file, which is only readable by root, and runs on 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

Two pitfalls that the script avoids¶

A new record is only visible after an explicit POST /refresh. Without it, the API responds with 200, the OVH interface displays the record, and the authoritative servers respond with NXDOMAIN — with the flag aa, so it doesn't look like a propagation in progress.
The field subDomain takes only the label monservice, never the FQDN. Entering monservice.savethemall.eu creates monservice.savethemall.eu.savethemall.eu, which resolves in an empty space without error.

A record created here remains active on its own

Another script (ovh-ddns.sh, every 15 minutes) rewrites all A records associated with the zone to the current WAN IP. Benefit: the house can change its IP address without breaking anything. Constraint: an A record from this zone cannot be permanently pointed elsewhere without modifying this script.

A connectivity issue, not a resolution¶

A device located within the subnet announced by an exit node, and configured to accept announced routes, loses all access to the internet: it sends itself a tunnel. This failure mode caused the Mac to be disconnected for 33 days. The symptom does not resemble a DNS issue, but that is where you should start looking.

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