DNS en resolutie¶

Machinevertaling van het Franse origineel.

Drie mogelijkheden voor dezelfde naam¶

*.savethemall.eu lost niet op naar hetzelfde adres, afhankelijk van waar het wordt aangevraagd.

Vanuit	Resolver	Antwoord voor `<x>.savethemall.eu`
Internet	OVH-servers	`<IP publique>` — het WAN-IP van het huis
LAN	AdGuard / CoreDNS	`vm-docker` — live vm-docker
Tailnet	CoreDNS van de tailnet	`<IP tailnet>` — vm-docker via de 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

Eenzelfde naam, drie antwoorden. Alleen de bovenstaande methode gaat via NAT, nas-caddy en het certificaat dat op de NAS is gekopieerd: de andere twee omzeilen dit en gaan direct naar vm-docker.

Een test vanaf het LAN test niet het WAN

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

Deze aanvraag gaat direct naar vm-docker: het omzeilt het NAT van de router, het omzeilt nas-caddy en het certificaat dat op de NAS is gekopieerd. Een service kan perfect reageren in het LAN en volledig onbereikbaar zijn vanaf het internet.

De test die de werkelijke route test:

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

De OVH-zone¶

Deze wordt beheerd via de API, niet via de webinterface. Het script leest de credentials uit het bestand van acme.sh, wat alleen leesbaar is door root, en wordt uitgevoerd op 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

Twee valkuilen die het script vermijdt¶

Een creatie is alleen zichtbaar na een expliciete POST /refresh. Zonder dit, beantwoordt de API 200, de OVH-interface toont het record, en de autoritatieve servers antwoorden met NXDOMAIN — met het aa-vlag, dus het lijkt niet op een lopende propagatie.
Het veld subDomain neemt alleen het label monservice, nooit het FQDN. Het invoeren van monservice.savethemall.eu creëert monservice.savethemall.eu.savethemall.eu, wat in het vacuüm reageert zonder fouten.

Een record dat hier wordt aangemaakt, blijft automatisch bestaan

Een ander script (ovh-ddns.sh, elke 15 minuten) herstelt alle A-records van de zone naar het huidige WAN-IP-adres. Voordeel: het huis kan zijn IP-adres wijzigen zonder dat er iets kapot gaat. Nadeel: een A-record van deze zone kan niet permanent naar een andere locatie worden verwijderd zonder dit script aan te passen.

Een verbindingsprobleem, geen oplossingsmethode¶

Een apparaat dat zich binnen het subnet bevindt dat door een uitgangsknoop wordt aangekondigd, en dat is geconfigureerd om de aangekondigde routes te accepteren, verliest alle toegang tot het internet: het stuurt zichzelf via een tunnel. Deze storing heeft de Mac gedurende 33 dagen uitgeschakeld. Het symptoom lijkt niet op een DNS-probleem, maar dat is waar men eerst naar moet kijken.

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