Headscale Tailscale Technitium - Résolution DNS home.arpa

Informations

cwwk

Serveur Debian qui héberge Technitium :

hostname
ip -br addr
ip addr show tailscale0
tailscale status
tailscale ip -4
tailscale ip -6

Vous devez confirmer :

LAN        : 192.168.0.205
Tailscale : 100.64.0.2
Tailscale : fd7a:115c:a1e0::2
Zone DNS   : home.arpa

VPS sxb

Sauvegardez les configurations :

sudo cp -a /etc/headscale /etc/headscale.backup-$(date +%F) 2>/dev/null || true
sudo cp -a /etc/ufw /etc/ufw.backup-$(date +%F)
sudo cp -a /etc/resolv.conf /etc/resolv.conf.backup-$(date +%F)

Technitium

Dans Technitium, exportez également la zone home.arpa ou sauvegardez sa configuration depuis l’interface d’administration.

Serveur Debian cwwk

Parefeu UFW

Commencez par afficher les règles numérotées :

sudo ufw status numbered

Supprimez les règles trop ouvertes :

DNS ALLOW Anywhere
DNS (v6) ALLOW Anywhere (v6)

Utilisez leur numéro :

sudo ufw delete NUMERO

Ajoutez les autorisations DNS limitées au LAN :

sudo ufw allow from 192.168.0.0/24 to any port 53 proto udp
sudo ufw allow from 192.168.0.0/24 to any port 53 proto tcp

sudo ufw allow from 192.168.10.0/24 to any port 53 proto udp
sudo ufw allow from 192.168.10.0/24 to any port 53 proto tcp

Ajoutez ensuite l’accès DNS par Tailscale :

sudo ufw allow in on tailscale0 to any port 53 proto udp
sudo ufw allow in on tailscale0 to any port 53 proto tcp

VOIR si régle précédente ne suffit pas
Pour IPv6 Tailscale :

sudo ufw allow from fd7a:115c:a1e0::/48 to any port 53 proto udp
sudo ufw allow from fd7a:115c:a1e0::/48 to any port 53 proto tcp

Vérifiez :

sudo ufw status verbose

L’objectif est d’avoir :

DNS depuis 192.168.0.0/24       ALLOW
DNS depuis 192.168.10.0/24      ALLOW
DNS via tailscale0               ALLOW
DNS depuis Internet              DENY

Vos règles NFS restent séparées :

2049/tcp on tailscale0 ALLOW
2049/tcp               DENY

Ne les modifiez pas dans le cadre de cette migration DNS.

Client tailscale

Sur le serveur Debian qui héberge Technitium, gardez :

sudo tailscale set --accept-dns=false

Cela évite que Tailscale remplace le résolveur DNS local du serveur DNS.

Technitium

zone home.arpa

Dans Technitium, créez ou vérifiez une zone primaire :

home.arpa

Ajoutez au minimum :

@           IN SOA  dns.home.arpa. hostadmin.home.arpa. (
                    52
                    900
                    300
                    604800
                    900 )

@           IN NS   dns.home.arpa.
dns         IN A    192.168.0.205

Vos enregistrements locaux :

cwwk        IN A     192.168.0.205
ged         IN A     192.168.0.205
link        IN A     192.168.0.205
lldap       IN A     192.168.0.205
portainer   IN A     192.168.0.205
pve         IN A     192.168.0.215
site        IN A     192.168.0.205

Ajoutez votre wildcard :

*           IN A     192.168.0.205

Si vous utilisez réellement IPv6 pour cwwk, conservez son enregistrement AAAA. Sinon, retirez-le pour éviter que certains clients tentent une connexion IPv6 non fonctionnelle.

Testez immédiatement depuis le serveur Debian :

dig @192.168.0.205 cwwk.home.arpa
dig @192.168.0.205 test.home.arpa

Résultat attendu :

cwwk.home.arpa.  IN A 192.168.0.205
test.home.arpa.  IN A 192.168.0.205

ACL Technitium

Dans les paramètres du résolveur Technitium, autorisez les réseaux suivants :

127.0.0.0/8
192.168.0.0/24
192.168.10.0/24
100.64.0.0/10
fd7a:115c:a1e0::/48

Dans l’interface Web :

1. Ouvrez Settings
2. Allez dans la section Recursion
3. Recherchez le champ Allowed Networks / Allowed Recursive Name Server Clients (le libellé peut varier légèrement selon la version)
4. Ajoutez les CIDR, à raison d’un réseau par ligne :
5. Cliquez sur Save Settings.

Cette liste contrôle les sources qui peuvent utiliser Technitium en tant que résolveur récursif. Les hôtes hors de ces plages ne doivent pas recevoir de résolution récursive, ce qui évite de transformer le serveur en open resolver exploitable. L’interface d’administration est normalement accessible sur le port 5380 (http://<IP-du-serveur>:5380/).[technitium][blog.technitium]

Vérifiez aussi Settings → General → DNS Server Local End Points :

• Cette option définit sur quelles adresses et quels ports Technitium écoute les requêtes DNS.
• Pour servir plusieurs interfaces IPv4 et IPv6, une configuration courante est :
• L’autorisation effective des clients demeure ensuite limitée par la liste Allowed Networks dans les réglages de récursion.

Technitium documente par exemple 0.0.0.0:53,[::]:53 comme endpoints locaux DNS dans sa configuration d’API.[github]

Attention aux réseaux indiqués

• 127.0.0.0/8 : loopback IPv4 local.
• 192.168.0.0/24 et 192.168.10.0/24 : vos deux LAN IPv4.
• 100.64.0.0/10 : espace CGNAT ; pertinent notamment pour des clients Tailscale utilisant des adresses 100.x.y.z.
• fd7a:115c:a1e0::/48 : préfixe IPv6 ULA ; assurez-vous qu’il correspond bien au préfixe effectivement attribué à vos clients.

Si votre objectif est aussi d’autoriser l’accès à la console Web depuis ces réseaux, c’est un réglage distinct : Settings → Web Service, avec les adresses d’écoute du service Web et, au besoin, les règles pare-feu/reverse proxy. Technitium expose habituellement la console HTTP sur le port 5380 et HTTPS sur 53443.[blog.technitium] Le réseau Tailscale est important :

100.64.0.0/10

Il contient l’adresse du serveur Technitium :

100.64.0.2

N’autorisez pas la récursion DNS depuis Internet.

Dans les points d’écoute DNS Technitium, utilisez de préférence :

0.0.0.0:53
[::]:53

Puis vérifiez sur Debian :

sudo ss -lunpt | grep ':53'

Technitium doit écouter en UDP et TCP.

Tester Technitium via Tailscale

Depuis le serveur Debian lui-même :

dig @100.64.0.2 cwwk.home.arpa
dig @100.64.0.2 test.home.arpa

Ces tests vérifient simultanément :

• l’écoute de Technitium sur tailscale0 ;
• le pare-feu UFW ;
• les ACL Technitium ;
• la zone home.arpa.

Le résultat doit être positif avant de modifier Headscale.

Vous pouvez également tester en IPv6 :

dig @fd7a:115c:a1e0::2 cwwk.home.arpa

Si IPv6 échoue, utilisez uniquement 100.64.0.2 dans la configuration Headscale dans un premier temps.

VPS Headscale

Section dns - /etc/headscale/config.yaml

Sur le VPS :

sudo cp -a /etc/headscale/config.yaml \
  /etc/headscale/config.yaml.backup-$(date +%F)

Modification configuration /etc/headscale/config.yaml

Vous pouvez remplacer example.com par un sous-domaine qui vous appartient :

base_domain: tailscale.xoyize.xyz

à condition que ce nom ne crée pas de conflit avec votre usage DNS actuel.

Votre section DNS doit devenir :

dns:
  magic_dns: true
  base_domain: tailscale.xoyize.xyz
  # Utiliser le DNS de l'hébergeur (ou le vôtre) et ne garder Tailscale que pour le tailnet
  # override_local_dns: false
  override_local_dns: false

  nameservers:
    global:
      - 1.1.1.1
      - 1.0.0.1
      - 2606:4700:4700::1111
      - 2606:4700:4700::1001

    split:
      home.arpa:
        - 100.64.0.2
        - fd7a:115c:a1e0::2

  search_domains: []
  extra_records: []

Vous pouvez commencer avec IPv4 seulement :

    split:
      home.arpa:
        - 100.64.0.2

Puis ajouter :

        - fd7a:115c:a1e0::2

après validation d’IPv6.

base_domain: example.com est le domaine MagicDNS de Headscale. Il est distinct de :

home.arpa

Ne définissez pas :

base_domain: home.arpa

home.arpa doit rester réservé à Technitium.

Politique - /etc/headscale/policy.hujson

La règle NFS ne change pas. Vous conservez exactement :

{
  "action": "accept",
  "src": ["tag:nfs-client"],
  "dst": ["tag:nfs-server:2049"]
}

Sur alder, vous ajoutez simplement tag:dns-server en plus de ses tags actuels. Un nœud peut porter plusieurs tags, et chaque tag peut être utilisé indépendamment dans les ACL.[tailscale][headscale]

Modifier le fichier /etc/headscale/policy.hujson

Ajoutez l’autorisation pour un nouveau tag :

"tag:dns-server": ["group:mesh-admin"],

Puis gardez votre ACL NFS et faites viser le DNS exclusivement vers tag:dns-server :

{
  "groups": {
    "group:mesh-admin": ["yann@"]
  },

  "tagOwners": {
    "tag:admin": ["group:mesh-admin"],
    "tag:server": ["group:mesh-admin"],
    "tag:nfs-server": ["group:mesh-admin"],
    "tag:nfs-client": ["group:mesh-admin"],
    "tag:dns-server": ["group:mesh-admin"],
    "tag:mobile": ["group:mesh-admin"],
    "tag:control-plane": ["group:mesh-admin"]
  },

  "acls": [
    {
      "action": "accept",
      "src": ["tag:admin"],
      "dst": [
        "tag:server:51002",
        "tag:server:55045",
        "tag:server:55134",
        "tag:server:55149",
        "tag:server:55215",
        "tag:server:55229",
        "tag:server:55240",
        "tag:server:56230",
        "tag:nfs-server:55205"
      ]
    },

    {
      "action": "accept",
      "src": ["tag:nfs-client"],
      "dst": ["tag:nfs-server:2049"]
    },

    {
      "action": "accept",
      "src": ["*"],
      "proto": "udp",
      "dst": ["tag:dns-server:53"]
    },
    {
      "action": "accept",
      "src": ["*"],
      "proto": "tcp",
      "dst": ["tag:dns-server:53"]
    }
  ]
}

Après adoption de la solution recommandée, le nœud alder doit conserver son rôle NFS et recevoir le rôle DNS :

alder
├── tag:server
├── tag:nfs-server
└── tag:dns-server

Ainsi :

Service sur alder	Tag ciblé par l’ACL	Port autorisé	Clients autorisés
NFS	tag:nfs-server	TCP 2049	tag:nfs-client
Technitium DNS	tag:dns-server	UDP 53 + TCP 53	Tous les nœuds (*)
Administration existante	tag:server / tag:nfs-server	Vos ports listés	tag:admin

Le sélecteur tag:nfs-server reste donc associé au rôle NFS, même si le même hôte porte aussi tag:dns-server. Un tag cible tous les appareils portant ce tag, et les tags multiples s’additionnent pour l’identité de l’appareil.[tailscale][tailscale]

Vérification et redémarrage headscale

Vérifier puis redémarrer Headscale

sudo headscale configtest

Redémarrez directement et surveillez les journaux :

sudo systemctl restart headscale
sudo systemctl status headscale
sudo journalctl -u headscale -n 100 --no-pager

Le VPS Headscale n’a pas besoin d’être un serveur DNS pour les clients. Il distribue uniquement la configuration indiquant que :

home.arpa → 100.64.0.2

Ne configurez pas 192.168.0.205 dans Headscale : cette adresse LAN n’est pas directement accessible par les clients Tailscale, sauf si vous mettez en place du subnet routing.

Vérifier pare-feu

Le VPS doit autoriser les ports nécessaires à Headscale, notamment :

443/tcp
3478/udp

Le port 53 n’est pas nécessaire sur le VPS pour cette architecture.

Le DNS est fourni par le serveur Technitium à travers le réseau Tailscale :

Client Tailscale → 100.64.0.2:53

Ajout tag sur alder

Avec l’ID Headscale 2, définissez tous les tags explicitement, sans retirer les existants :

sudo headscale nodes tag -i 2 \
  -t tag:server,tag:nfs-server,tag:dns-server

Headscale permet d’affecter plusieurs tags, séparés par des virgules, via headscale nodes tag. Attention : la commande définit la liste fournie ; c’est pourquoi il faut répéter tag:server et tag:nfs-server, pas seulement ajouter tag:dns-server.[headscale]

Vérifiez ensuite :

sudo headscale nodes list

Vous devez voir pour alder dans la colonne Tags :

tag:server
tag:nfs-server
tag:dns-server

Avec cette séparation :

tag:nfs-client ── TCP/2049 ──> tag:nfs-server
tous les clients ── UDP/TCP 53 ──> tag:dns-server

Si, plus tard, vous étiquetez pve ou un autre hôte avec tag:nfs-server, les clients NFS pourront atteindre son port 2049, comme prévu. En revanche, cet hôte ne sera pas automatiquement exposé comme résolveur DNS : seul un nœud ayant explicitement tag:dns-server recevra le trafic DNS.

Ajout tag pc1 e6230

# 3  | pc1
sudo headscale nodes tag -i 3 \
  -t tag:nfs-client,tag:server
# 4  | e6230

Clients Tailscale

Activer acceptation DNS Tailscale

Sur chaque client Tailscale qui doit recevoir la configuration Headscale :

Vérifier si dns true

sudo tailscale get accept-dns

Si false, l’activer

sudo tailscale set --accept-dns=true

Sur les clients Linux, vérifiez ensuite :

resolvectl status

Suivant paramètre VPS /etc/headscale/config.yaml
override_local_dns: false (choix actuel)

Global
         Protocols: +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (ens3)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 213.186.33.99
       DNS Servers: 213.186.33.99
     Default Route: yes

override_local_dns: true

Global
         Protocols: +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (ens3)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 213.186.33.99
       DNS Servers: 213.186.33.99
     Default Route: yes

Link 6 (tailscale0)
    Current Scopes: DNS
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 100.100.100.100
       DNS Servers: 100.100.100.100 fd7a:115c:a1e0::53
        DNS Domain: tailscale.xoyize.xyz ~0.e.1.a.c.5.1.1.a.7.d.f.ip6.arpa ~100.100.in-addr.arpa
                    ~101.100.in-addr.arpa ~102.100.in-addr.arpa ~103.100.in-addr.arpa ~104.100.in-addr.arpa
                    ~105.100.in-addr.arpa ~106.100.in-addr.arpa ~107.100.in-addr.arpa ~108.100.in-addr.arpa
                    ~109.100.in-addr.arpa ~110.100.in-addr.arpa ~111.100.in-addr.arpa ~112.100.in-addr.arpa
                    ~113.100.in-addr.arpa ~114.100.in-addr.arpa ~115.100.in-addr.arpa ~116.100.in-addr.arpa
                    ~117.100.in-addr.arpa ~118.100.in-addr.arpa ~119.100.in-addr.arpa ~120.100.in-addr.arpa
                    ~121.100.in-addr.arpa ~122.100.in-addr.arpa ~123.100.in-addr.arpa ~124.100.in-addr.arpa
                    ~125.100.in-addr.arpa ~126.100.in-addr.arpa ~127.100.in-addr.arpa ~64.100.in-addr.arpa
                    ~65.100.in-addr.arpa ~66.100.in-addr.arpa ~67.100.in-addr.arpa ~68.100.in-addr.arpa
                    ~69.100.in-addr.arpa ~70.100.in-addr.arpa ~71.100.in-addr.arpa ~72.100.in-addr.arpa
                    ~73.100.in-addr.arpa ~74.100.in-addr.arpa ~75.100.in-addr.arpa ~76.100.in-addr.arpa
                    ~77.100.in-addr.arpa ~78.100.in-addr.arpa ~79.100.in-addr.arpa ~80.100.in-addr.arpa
                    ~81.100.in-addr.arpa ~82.100.in-addr.arpa ~83.100.in-addr.arpa ~84.100.in-addr.arpa
                    ~85.100.in-addr.arpa ~86.100.in-addr.arpa ~87.100.in-addr.arpa ~88.100.in-addr.arpa
                    ~89.100.in-addr.arpa ~90.100.in-addr.arpa ~91.100.in-addr.arpa ~92.100.in-addr.arpa
                    ~93.100.in-addr.arpa ~94.100.in-addr.arpa ~95.100.in-addr.arpa ~96.100.in-addr.arpa
                    ~97.100.in-addr.arpa ~98.100.in-addr.arpa ~99.100.in-addr.arpa ~home.arpa
     Default Route: no

Sur un client Linux, /etc/resolv.conf peut afficher :

nameserver 100.100.100.100

Ce n’est pas forcément un problème. Cette adresse est le proxy DNS local de Tailscale. Le proxy doit transférer les requêtes de home.arpa vers 100.64.0.2.

Tester depuis un client Tailscale

Commencez par un test direct :

dig @100.64.0.2 cwwk.home.arpa

Puis testez la résolution normale :

dig cwwk.home.arpa
dig test.home.arpa
dig pve.home.arpa

Vérifiez également le serveur indiqué par dig :

SERVER: 100.100.100.100#53

Cette valeur peut être normale avec Tailscale. Pour confirmer le chemin réel, contrôlez les journaux ou statistiques de requêtes dans Technitium.

Testez enfin l’accès aux services :

curl -I https://cwwk.home.arpa
curl -I https://test.home.arpa

Les certificats wildcard doivent correspondre aux noms utilisés :

cwwk.home.arpa
test.home.arpa

Un certificat *.home.arpa couvre ces noms, mais pas nécessairement le nom racine :

home.arpa

Vérifier plusieurs types de clients

À tester depuis :

Client	Test attendu
Serveur Technitium	dig @192.168.0.205 cwwk.home.arpa
Serveur Technitium via Tailscale	dig @100.64.0.2 cwwk.home.arpa
Client LAN 192.168.0.0/24	dig cwwk.home.arpa
Client LAN 192.168.10.0/24	dig cwwk.home.arpa
Client Tailscale IPv4	dig cwwk.home.arpa
Client Tailscale IPv6	dig cwwk.home.arpa

Résultat attendu dans tous les cas :

cwwk.home.arpa. IN A 192.168.0.205

État final recherché

LAN
 │
 │ 192.168.0.205:53
 ▼
Technitium
 │
 ├── home.arpa
 ├── *.home.arpa
 └── résolution récursive
 ▲
 │ 100.64.0.2:53
 │
Réseau Tailscale
 ▲
 │ DNS split home.arpa
 │
Headscale VPS

Configuration finale essentielle :

Technitium LAN       192.168.0.205
Technitium Tailscale 100.64.0.2
Zone locale          home.arpa
Réseau Tailscale     100.64.0.0/10
Réseau Tailscale v6  fd7a:115c:a1e0::/48
Headscale split DNS  home.arpa → 100.64.0.2

Ne modifiez pas encore le DNS des clients tant que ce test ne fonctionne pas :

dig @100.64.0.2 cwwk.home.arpa

Erreurs

Diagnostiquer

Sur le serveur Technitium :

sudo ss -lunpt | grep ':53'
sudo ufw status verbose
sudo journalctl -f

Tester directement :

dig @100.64.0.2 cwwk.home.arpa

Depuis le client Tailscale :

tailscale ping 100.64.0.2
ping 100.64.0.2
dig @100.64.0.2 cwwk.home.arpa

Interprétation :

• tailscale ping échoue : problème Headscale/Tailscale ou connectivité mesh ;
• tailscale ping fonctionne mais dig @100.64.0.2 échoue : UFW, Technitium ou ACL ;
• dig @100.64.0.2 fonctionne mais dig cwwk.home.arpa échoue : configuration DNS Headscale ou client n’acceptant pas le DNS ;
• le nom résout mais HTTPS échoue : problème de reverse proxy, certificat ou routage ;
• la requête arrive dans Technitium mais retourne NXDOMAIN : problème de zone ou d’enregistrement.

VPS contourne systemd-resolved

Pourquoi la résolution DNS home.arpa ne fonctionne pas sur yannir ?

yair@yannir:~$ dig cwwk.home.arpa

; <<>> DiG 9.20.29-1~deb13u1-Debian <<>> cwwk.home.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39630
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;cwwk.home.arpa.			IN	A

;; AUTHORITY SECTION:
home.arpa.		3600	IN	SOA	prisoner.iana.org. hostmaster.root-servers.org. 1 604800 60 604800 604800

;; Query time: 23 msec
;; SERVER: 213.136.95.10#53(213.136.95.10) (UDP)
;; WHEN: Mon Sep 28 17:18:31 CEST 2026
;; MSG SIZE  rcvd: 120

yair@yannir:~$ resolvectl status
Global
         Protocols: +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: uplink

Link 2 (eth0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 213.136.95.10
       DNS Servers: 213.136.95.10 213.136.95.11 2a02:c207::1:53
     Default Route: yes

Link 10 (tailscale0)
    Current Scopes: DNS
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 100.100.100.100
       DNS Servers: 100.100.100.100 fd7a:115c:a1e0::53
        DNS Domain: tailscale.xoyize.xyz ~0.e.1.a.c.5.1.1.a.7.d.f.ip6.arpa ~100.100.in-addr.arpa
                    ~101.100.in-addr.arpa ~102.100.in-addr.arpa ~103.100.in-addr.arpa ~104.100.in-addr.arpa
                    ~105.100.in-addr.arpa ~106.100.in-addr.arpa ~107.100.in-addr.arpa ~108.100.in-addr.arpa
                    ~109.100.in-addr.arpa ~110.100.in-addr.arpa ~111.100.in-addr.arpa ~112.100.in-addr.arpa
                    ~113.100.in-addr.arpa ~114.100.in-addr.arpa ~115.100.in-addr.arpa ~116.100.in-addr.arpa
                    ~117.100.in-addr.arpa ~118.100.in-addr.arpa ~119.100.in-addr.arpa ~120.100.in-addr.arpa
                    ~121.100.in-addr.arpa ~122.100.in-addr.arpa ~123.100.in-addr.arpa ~124.100.in-addr.arpa
                    ~125.100.in-addr.arpa ~126.100.in-addr.arpa ~127.100.in-addr.arpa ~64.100.in-addr.arpa
                    ~65.100.in-addr.arpa ~66.100.in-addr.arpa ~67.100.in-addr.arpa ~68.100.in-addr.arpa
                    ~69.100.in-addr.arpa ~70.100.in-addr.arpa ~71.100.in-addr.arpa ~72.100.in-addr.arpa
                    ~73.100.in-addr.arpa ~74.100.in-addr.arpa ~75.100.in-addr.arpa ~76.100.in-addr.arpa
                    ~77.100.in-addr.arpa ~78.100.in-addr.arpa ~79.100.in-addr.arpa ~80.100.in-addr.arpa
                    ~81.100.in-addr.arpa ~82.100.in-addr.arpa ~83.100.in-addr.arpa ~84.100.in-addr.arpa
                    ~85.100.in-addr.arpa ~86.100.in-addr.arpa ~87.100.in-addr.arpa ~88.100.in-addr.arpa
                    ~89.100.in-addr.arpa ~90.100.in-addr.arpa ~91.100.in-addr.arpa ~92.100.in-addr.arpa
                    ~93.100.in-addr.arpa ~94.100.in-addr.arpa ~95.100.in-addr.arpa ~96.100.in-addr.arpa
                    ~97.100.in-addr.arpa ~98.100.in-addr.arpa ~99.100.in-addr.arpa ~home.arpa
     Default Route: no

yann@yannig:~$ dig cwwk.home.arpa

; <<>> DiG 9.20.29-1~deb13u1-Debian <<>> cwwk.home.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48641
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;cwwk.home.arpa.			IN	A

;; ANSWER SECTION:
cwwk.home.arpa.		86400	IN	A	192.168.0.205

;; Query time: 36 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Sep 28 17:18:10 CEST 2026
;; MSG SIZE  rcvd: 59

---

yann@yannig:~$ resolvectl status
Global
         Protocols: +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (ens3)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 213.186.33.99
       DNS Servers: 213.186.33.99
     Default Route: yes

Link 6 (tailscale0)
    Current Scopes: DNS
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 100.100.100.100
       DNS Servers: 100.100.100.100 fd7a:115c:a1e0::53
        DNS Domain: tailscale.xoyize.xyz ~0.e.1.a.c.5.1.1.a.7.d.f.ip6.arpa ~100.100.in-addr.arpa
                    ~101.100.in-addr.arpa ~102.100.in-addr.arpa ~103.100.in-addr.arpa ~104.100.in-addr.arpa
                    ~105.100.in-addr.arpa ~106.100.in-addr.arpa ~107.100.in-addr.arpa ~108.100.in-addr.arpa
                    ~109.100.in-addr.arpa ~110.100.in-addr.arpa ~111.100.in-addr.arpa ~112.100.in-addr.arpa
                    ~113.100.in-addr.arpa ~114.100.in-addr.arpa ~115.100.in-addr.arpa ~116.100.in-addr.arpa
                    ~117.100.in-addr.arpa ~118.100.in-addr.arpa ~119.100.in-addr.arpa ~120.100.in-addr.arpa
                    ~121.100.in-addr.arpa ~122.100.in-addr.arpa ~123.100.in-addr.arpa ~124.100.in-addr.arpa
                    ~125.100.in-addr.arpa ~126.100.in-addr.arpa ~127.100.in-addr.arpa ~64.100.in-addr.arpa
                    ~65.100.in-addr.arpa ~66.100.in-addr.arpa ~67.100.in-addr.arpa ~68.100.in-addr.arpa
                    ~69.100.in-addr.arpa ~70.100.in-addr.arpa ~71.100.in-addr.arpa ~72.100.in-addr.arpa
                    ~73.100.in-addr.arpa ~74.100.in-addr.arpa ~75.100.in-addr.arpa ~76.100.in-addr.arpa
                    ~77.100.in-addr.arpa ~78.100.in-addr.arpa ~79.100.in-addr.arpa ~80.100.in-addr.arpa
                    ~81.100.in-addr.arpa ~82.100.in-addr.arpa ~83.100.in-addr.arpa ~84.100.in-addr.arpa
                    ~85.100.in-addr.arpa ~86.100.in-addr.arpa ~87.100.in-addr.arpa ~88.100.in-addr.arpa
                    ~89.100.in-addr.arpa ~90.100.in-addr.arpa ~91.100.in-addr.arpa ~92.100.in-addr.arpa
                    ~93.100.in-addr.arpa ~94.100.in-addr.arpa ~95.100.in-addr.arpa ~96.100.in-addr.arpa
                    ~97.100.in-addr.arpa ~98.100.in-addr.arpa ~99.100.in-addr.arpa ~home.arpa
     Default Route: no

La différence est dans la ligne resolv.conf mode :

	yannig (fonctionne)	yannir (échoue)
resolv.conf mode	stub	uplink
Serveur interrogé par dig	127.0.0.53 (le stub de resolved)	213.136.95.10 (DNS de l’hébergeur, en direct)

Sur yannir, /etc/resolv.conf pointe vers /run/systemd/resolve/resolv.conf (mode uplink). Ce fichier liste directement les DNS des interfaces (ici ceux de l’hébergeur), sans passer par le stub. Les applications interrogent donc l’hébergeur, qui ne connaît pas cwwk.home.arpa et répond NXDOMAIN.

Le routage par domaine (~home.arpa vers Tailscale, 100.100.100.100) est bien présent sur les deux machines, mais il n’est appliqué que si les requêtes passent par resolved. Votre config Tailscale et resolved est correcte sur les deux, seul le lien symbolique diffère.

Vérification préalable (facultative). Pour confirmer que resolved fait bien son travail avant de changer quoi que ce soit :

resolvectl query cwwk.home.arpa

Résultat

cwwk.home.arpa: 192.168.0.205                  -- link: tailscale0
                2a01:e0a:95a:e2f0:aab8:e0ff:fe04:ec45 -- link: tailscale0

-- Information acquired via protocol DNS in 61.8ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

Cette commande passe par resolved et doit fonctionner même en mode uplink. Si c’est le cas, le diagnostic est confirmé.

Correction sur yannir

ls -l /etc/resolv.conf     # confirmer : ... -> /run/systemd/resolve/resolv.conf
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
resolvectl status | head -4   # doit afficher "resolv.conf mode: stub"
dig cwwk.home.arpa

Le dig doit maintenant interroger 127.0.0.53 et retourner 192.168.0.205.

Pourquoi c’est arrivé

Sur un VPS, cloud-init, un script de l’hébergeur ou un paquet (resolvconf, openresolv) peut recréer le lien vers resolv.conf (uplink), ou l’installation de Tailscale peut ne pas l’avoir modifié. Si le lien revient après un redémarrage, cherchez qui le réécrit :

dpkg -l | grep -E 'resolvconf|openresolv'
grep -r resolv /etc/cloud/ 2>/dev/null | head

home.arpa est routé uniquement vers Tailscale (~home.arpa). Cela suppose qu’un subnet router ou un split DNS est défini dans la console Tailscale pour ce domaine. C’est déjà le cas puisque yannig résout correctement.