DNS e risoluzione¶

Traduzione automatica dell'originale francese.

Tre possibili scenari per lo stesso nome¶

*.savethemall.eu non risolve verso lo stesso indirizzo a seconda del punto di partenza.

Da	Risolutore	Risposta per `<x>.savethemall.eu`
Internet	Server OVH	`<IP publique>` — indirizzo WAN della rete domestica
LAN	AdGuard / CoreDNS	`vm-docker` — vm-docker in esecuzione
Tailnet	CoreDNS di Tailnet	`<IP tailnet>` — vm-docker gestito da 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

Lo stesso nome, tre risposte. Solo il percorso superiore attraversa il NAT, nas-caddy e il certificato copiato sul NAS: gli altri due saltano tutto e vanno direttamente su vm-docker.

Testare dal LAN non testa il WAN

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

Questa richiesta va direttamente su vm-docker: salta il NAT del router, salta nas-caddy e il certificato copiato sul NAS. Un servizio può rispondere perfettamente in LAN e non essere raggiungibile da Internet.

Il test che verifica il vero percorso:

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

La zona OVH¶

È gestita tramite API, non tramite l'interfaccia web. Lo script del parco legge le credenziali dal file di acme.sh, accessibile solo da root, ed è eseguito su 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

Due trappole che lo script evita¶

Una creazione è visibile solo dopo un'esplicita POST /refresh. Altrimenti, l'API risponde con 200, l'interfaccia OVH mostra l'inserimento, e i server autorevoli rispondono con NXDOMAIN — con il flag aa, quindi non sembra una propagazione in corso.
Il campo subDomain prende solo l'etichetta monservice, mai il FQDN. Inserire monservice.savethemall.eu crea monservice.savethemall.eu.savethemall.eu, che risolve nel vuoto senza errori.

Un record creato qui si mantiene da solo

Un altro script (ovh-ddns.sh, ogni 15 minuti) riscrive tutti i record A denominati nella zona verso l'indirizzo IP WAN corrente. Vantaggio: la casa può cambiare indirizzo IP senza causare problemi. Svantaggio: un record A di questa zona non può essere permanentemente puntato verso un altro indirizzo senza modificare questo script.

Un problema di connettività, non di risoluzione¶

Un dispositivo situato all'interno del sottorete annunciato da un nodo di uscita, e configurato per accettare le rotte annunciate, perde l'accesso a Internet: si invia a se stesso tramite un tunnel. Questo tipo di guasto ha interrotto la connessione del Mac per 33 giorni. Il sintomo non è legato al DNS, ma è lì che bisogna iniziare a cercare.

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