Debian Tailscale résolution DNS

Debian Tailscale résolution DNS

Notes

Message 1 sur 8 de l'utilisateur - 06/10/2026 13:07:10: proxmox serveur, quel système pour la résolution DNS, peut on la modifier ?

Sur un serveur Proxmox VE, la résolution DNS est généralement gérée par la configuration Debian classique, principalement :

  • /etc/resolv.conf : serveurs DNS actuellement utilisés ;
  • /etc/hosts : résolution locale du nom du serveur et des nœuds ;
  • /etc/hostname : nom d’hôte ;
  • /etc/network/interfaces : configuration réseau, parfois avec le paramètre DNS ;
  • systemd-resolved, uniquement s’il est activé.

Pour vérifier la configuration actuelle :

1
2
3
4

cat /etc/resolv.conf
cat /etc/hosts
hostname --fqdn
resolvectl status

Vous pouvez modifier les DNS depuis l’interface Proxmox :

Datacenter → votre nœud → System → DNS

ou en ligne de commande, selon votre configuration :

1

nano /etc/resolv.conf

Exemple :

1
2
3

search example.local
nameserver 192.168.1.1
nameserver 1.1.1.1

Cependant, /etc/resolv.conf peut être régénéré ou être un lien symbolique. Vérifiez-le avec :

1

ls -l /etc/resolv.conf

Pour une configuration persistante du nœud Proxmox, vérifiez également :

1

nano /etc/network/interfaces

Exemple :

1
2
3
4
5
6
7
8

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    dns-nameservers 192.168.1.1 1.1.1.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

Puis rechargez le réseau, de préférence depuis la console locale ou une session de secours si vous êtes connecté en SSH :

1

ifreload -a

Pour un conteneur LXC, le DNS peut être défini indépendamment du nœud :

1

pct set 100 --nameserver 192.168.1.1

Plusieurs serveurs peuvent être indiqués :

1

pct set 100 --nameserver "192.168.1.1 1.1.1.1"

Pour une machine virtuelle, Proxmox ne fournit généralement pas directement le DNS au système invité. Il faut le configurer dans la VM elle-même, dans /etc/resolv.conf, NetworkManager, Netplan ou Windows selon l’OS.

À retenir : 127.0.0.53 dans /etc/resolv.conf signifie souvent que systemd-resolved sert de relais local. Ce n’est pas nécessairement le DNS final ; utilisez resolvectl status pour voir les vrais serveurs interrogés.

Message 2 sur 8 de l'utilisateur - 06/10/2026 13:08:09: Comment est défini le paramétrage DNS par défaut?

Par défaut, le DNS d’un nœud Proxmox est défini principalement au moment de l’installation, à partir de la configuration réseau fournie par l’installateur :

  • Nom d’hôte et FQDN : définis pendant l’installation.
  • Adresse IP et passerelle : configurées pour l’interface réseau.
  • Serveur DNS : généralement repris depuis le réseau/DHCP ou saisi manuellement pendant l’installation.
  • Domaine de recherche : éventuellement défini si vous utilisez un domaine local.
  • Résolution locale : enregistrée dans /etc/hosts.

Les fichiers importants sont :

1
2
3

cat /etc/hostname
cat /etc/hosts
cat /etc/resolv.conf

Sur un nœud Proxmox correctement configuré, on trouve souvent une entrée similaire dans /etc/hosts :

1
2

127.0.0.1       localhost
192.168.1.10    pve01.example.local pve01

L’adresse IP du nœud doit normalement être associée à son nom complet dans /etc/hosts. Par exemple, si le nom du serveur est pve01.example.local, vérifiez :

1
2
3
4

hostname
hostname --fqdn
getent hosts pve01
getent hosts pve01.example.local

La résolution DNS externe est indiquée dans /etc/resolv.conf, par exemple :

1
2
3

search example.local
nameserver 192.168.1.1
nameserver 1.1.1.1

Dans certains cas, /etc/resolv.conf contient plutôt :

1

nameserver 127.0.0.53

Cela signifie que systemd-resolved est utilisé comme résolveur local. Les serveurs DNS réellement configurés se vérifient alors avec :

1

resolvectl status

Pour voir la configuration réseau enregistrée par Proxmox :

1

cat /etc/network/interfaces

Vous pouvez aussi consulter la configuration DNS déclarée au niveau Proxmox :

1

cat /etc/pve datacenter.cfg

La commande correcte pour afficher uniquement les paramètres concernés est :

1

grep -E '^(search|nameserver|dns)' /etc/resolv.conf /etc/network/interfaces /etc/pve/datacenter.cfg 2>/dev/null

En pratique, la priorité est généralement la suivante :

  1. le résolveur défini par systemd-resolved, NetworkManager ou /etc/resolv.conf ;
  2. les entrées locales de /etc/hosts ;
  3. le serveur DNS configuré sur le réseau ;
  4. les DNS propres aux conteneurs LXC ou aux machines virtuelles, qui peuvent être différents de ceux du nœud Proxmox.

Pour un cluster Proxmox, chaque nœud doit pouvoir résoudre correctement tous les autres nœuds, idéalement dans les deux sens :

1
2
3

getent hosts pve01
getent hosts pve02
ping -c 2 pve01.example.local

Le nom du nœud Proxmox ne devrait pas dépendre uniquement d’un DNS externe : une entrée cohérente dans /etc/hosts est généralement recommandée, surtout pour le fonctionnement du cluster.

Message 3 sur 8 de l'utilisateur - 06/10/2026 13:10:38: Pourquoi tailscale à modifier le DNS? 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

leno@pve:~$ cat /etc/hostname
cat /etc/hosts
cat /etc/resolv.conf
pve
127.0.0.1 localhost.localdomain localhost
192.168.0.215 pve.home.arpa pve

# The following lines are desirable for IPv6 capable hosts

::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
# resolv.conf(5) file generated by tailscale
# For more info, see https://tailscale.com/s/resolvconf-overwrite
# DO NOT EDIT THIS FILE BY HAND -- CHANGES WILL BE OVERWRITTEN

nameserver 100.100.100.100
nameserver fd7a:115c:a1e0::53
search tailscale.xoyize.xyz

Tailscale a modifié /etc/resolv.conf parce que MagicDNS est probablement activé sur votre réseau Tailscale et que ce nœud accepte les paramètres DNS distribués par Tailscale.

Votre fichier le confirme :

1
2
3
4

# resolv.conf(5) file generated by tailscale
nameserver 100.100.100.100
nameserver fd7a:115c:a1e0::53
search tailscale.xoyize.xyz
  • 100.100.100.100 est le résolveur DNS local de Tailscale.
  • fd7a:115c:a1e0::53 est son équivalent IPv6.
  • search tailscale.xoyize.xyz permet de résoudre les noms internes de votre réseau Tailscale.
  • Tailscale utilise ces DNS pour MagicDNS et, éventuellement, pour le split DNS. [1]

Votre /etc/hosts, lui, n’a pas été modifié par Tailscale :

1

192.168.0.215 pve.home.arpa pve

Le nom local pve.home.arpa continuera donc à fonctionner grâce à /etc/hosts. En revanche, les requêtes DNS classiques — par exemple debian.org ou pve.home.arpa si cette zone existe réellement sur votre réseau — passent désormais par le résolveur Tailscale, qui les transmet normalement aux DNS amont configurés.

Pour voir l’état exact :

1

tailscale dns status

et :

1

tailscale debug prefs | grep -i dns

Pour empêcher Tailscale de gérer le DNS de ce serveur :

1

sudo tailscale set --accept-dns=false

Puis restaurez votre configuration DNS, par exemple :

1
2

sudo cp -a /etc/resolv.conf /etc/resolv.conf.tailscale
sudo nano /etc/resolv.conf

Exemple :

1
2
3

search home.arpa
nameserver 192.168.0.1
nameserver 1.1.1.1

Attention : si vous modifiez directement /etc/resolv.conf sans désactiver accept-dns, Tailscale risque de réécrire le fichier au prochain redémarrage ou changement de configuration. La commande recommandée est donc :

1

sudo tailscale set --accept-dns=false

Si vous souhaitez conserver MagicDNS tout en évitant que Tailscale écrive directement dans /etc/resolv.conf, utilisez plutôt systemd-resolved comme gestionnaire DNS. Tailscale essaie de s’intégrer à un gestionnaire DNS existant ; en l’absence d’un tel gestionnaire, il remplace directement /etc/resolv.conf. [1,2]

Vérifiez d’abord si systemd-resolved est actif :

1
2

systemctl is-active systemd-resolved
ls -l /etc/resolv.conf

Dans votre cas, le choix dépend donc de l’objectif :

  • Vous n’utilisez pas les noms Tailscale : désactivez accept-dns.
  • Vous utilisez MagicDNS : laissez cette configuration en place.
  • Vous voulez MagicDNS et votre DNS local : configurez systemd-resolved ou un autre gestionnaire DNS au lieu d’éditer manuellement /etc/resolv.conf.

Pour un serveur Proxmox, je recommande généralement de désactiver la prise en charge DNS de Tailscale sur le nœud si Tailscale sert uniquement à l’accès VPN, puis de conserver le DNS local du réseau :

1

sudo tailscale set --accept-dns=false

Cela ne désactive pas Tailscale ni le VPN ; cela empêche seulement Tailscale de remplacer la résolution DNS du serveur.

Lire la suite [1] Why is resolv.conf being overwritten? · Tailscale Docs — https://tailscale.com/docs/reference/faq/dns-resolv-conf [2] Configuring Linux DNS · Tailscale Docs — https://tailscale.com/docs/reference/linux-dns

Message 4 sur 8 de l'utilisateur - 06/10/2026 13:30:38: Les VPS ou machines distantes debian ont un réseau privé tailscale, resolv.conf: 
1
2
3

nameserver 127.0.0.53
options edns0 trust-ad
search tailscale.xoyize.xyz
Quelle incidence? - Si je garde le DNS taiscale actif, en cas de problème sur le réseau privé ? - Si je désactive, comment reconfigurer le DNS, manuellement ?

nameserver 127.0.0.53 indique que la machine utilise systemd-resolved comme résolveur local. Le fichier /etc/resolv.conf ne contient donc pas directement les serveurs DNS réels : les programmes interrogent systemd-resolved, qui décide ensuite vers quel DNS envoyer chaque requête.

La présence de :

1

search tailscale.xoyize.xyz

montre que Tailscale a ajouté son suffixe MagicDNS à la configuration DNS de systemd-resolved.

Si vous gardez le DNS Tailscale actif

Tant que Tailscale fonctionne, les noms Tailscale sont résolus normalement :

1

ping serveur-distant.tailscale.xoyize.xyz

En cas de problème du réseau privé Tailscale :

  • les noms en .tailscale.xoyize.xyz ne seront plus résolus ;
  • les connexions utilisant directement une adresse Tailscale 100.x.y.z échoueront ;
  • les requêtes Internet peuvent continuer à fonctionner si systemd-resolved dispose d’un DNS public ou local de secours ;
  • selon la configuration, les requêtes DNS peuvent subir un délai d’attente avant de basculer vers un autre serveur ;
  • le suffixe tailscale.xoyize.xyz peut rester présent, même si Tailscale est temporairement indisponible.

Pour voir les DNS réellement utilisés :

1

resolvectl status

Pour voir les routes DNS :

1
2

resolvectl dns
resolvectl domain

Pour tester un nom précis :

1
2

resolvectl query debian.org
resolvectl query machine.tailscale.xoyize.xyz

Le point important est que 127.0.0.53 ne garantit pas à lui seul un fonctionnement hors ligne : tout dépend des serveurs configurés derrière systemd-resolved.

Désactiver la prise en charge DNS par Tailscale

Sur chaque machine Debian :

1

sudo tailscale set --accept-dns=false

Cela désactive uniquement l’intégration DNS de Tailscale. Le réseau Tailscale reste actif et les adresses 100.x.y.z continuent de fonctionner.

Vérifiez ensuite :

1
2

resolvectl status
cat /etc/resolv.conf

Le suffixe tailscale.xoyize.xyz devrait disparaître après actualisation de la configuration. Si nécessaire :

1

sudo systemctl restart systemd-resolved

Configurer manuellement les DNS avec systemd-resolved

Identifiez le nom de l’interface réseau :

1

ip -br link

Par exemple, elle peut s’appeler ens3, eth0 ou enp1s0.

Définissez ensuite les DNS sur cette interface :

1
2

sudo resolvectl dns ens3 192.168.1.1 1.1.1.1
sudo resolvectl domain ens3 '~.'

Remplacez ens3 par le nom réel de votre interface.

  • 192.168.1.1 peut être le DNS de votre réseau ou de votre fournisseur VPS ;
  • 1.1.1.1 est un DNS public de secours ;
  • ~. indique que cette interface est la route DNS par défaut.

Vérifiez :

1
2

resolvectl status
resolvectl query debian.org

Cette configuration avec resolvectl peut être temporaire et être perdue après un redémarrage. Pour la rendre persistante, utilisez le gestionnaire réseau de la machine.

Avec systemd-networkd, créez ou modifiez par exemple :

1

sudo nano /etc/systemd/network/10-ens3.network

1
2
3
4
5
6
7
8

[Match]
Name=ens3

[Network]
DHCP=yes
DNS=192.168.1.1
DNS=1.1.1.1
Domains=~.

Puis :

1
2

sudo systemctl restart systemd-networkd
sudo systemctl restart systemd-resolved

Si le VPS utilise NetworkManager :

1
2
3
4

nmcli connection show
sudo nmcli connection modify "Nom de la connexion" ipv4.dns "192.168.1.1 1.1.1.1"
sudo nmcli connection modify "Nom de la connexion" ipv4.ignore-auto-dns yes
sudo nmcli connection up "Nom de la connexion"

Recommandation dans votre cas

Pour des VPS Debian qui utilisent Tailscale uniquement pour communiquer entre eux, je choisirais :

1

sudo tailscale set --accept-dns=false

Puis je configurerais les DNS normaux du VPS, avec au moins deux serveurs accessibles hors du réseau Tailscale. Les communications Tailscale continueront à fonctionner avec les adresses 100.x.y.z, mais les noms *.tailscale.xoyize.xyz ne fonctionneront plus par DNS.

Si vous avez besoin de MagicDNS, gardez accept-dns=true, mais assurez-vous que les DNS Internet ou locaux de secours apparaissent bien dans :

1

resolvectl status

La configuration idéale dépend aussi du gestionnaire réseau actif :

1
2
3

systemctl is-active systemd-networkd
systemctl is-active NetworkManager
systemctl is-active systemd-resolved
Message 5 sur 8 de l'utilisateur - 06/10/2026 13:38:22: Sur tous mes VPS systemd-networkd et systemd-resolved ACTIFS Mes serveurs Debian et Proxmox systemd-networkd, NetworkManage et systemd-resolved INACTIFS

Votre situation est cohérente : vous avez deux modes de gestion différents.

  • VPS Debian : systemd-networkd configure le réseau et systemd-resolved fournit le résolveur local.
  • Serveurs Debian/Proxmox : aucun de ces services ne gère le réseau ou le DNS. Proxmox utilise généralement ifupdown2, et Debian peut utiliser ifupdown. Tailscale peut donc gérer directement /etc/resolv.conf.

Avec systemd-resolved, le fichier suivant est normal :

1
2
3

nameserver 127.0.0.53
options edns0 trust-ad
search tailscale.xoyize.xyz

Les vrais DNS sont à consulter avec :

1

resolvectl status

127.0.0.53 est simplement le relais local de systemd-resolved; les DNS amont peuvent venir de systemd-networkd, de Tailscale, du DHCP ou de /etc/systemd/resolved.conf. [1,2]

Pour vos VPS Debian

Je vous conseille de conserver systemd-resolved, mais de choisir explicitement si Tailscale doit lui fournir le DNS.

Option 1 : conserver MagicDNS

Gardez :

1

sudo tailscale set --accept-dns=true

Puis vérifiez :

1

resolvectl status

Vous devriez voir une configuration Tailscale, probablement associée à l’interface tailscale0, et éventuellement un DNS global ou local.

Si Tailscale devient indisponible, les noms *.tailscale.xoyize.xyz ne fonctionneront plus. Les noms Internet peuvent continuer à fonctionner si resolvectl status affiche aussi un DNS accessible par l’interface réseau principale.

Option 2 : ne pas utiliser le DNS Tailscale

Désactivez seulement l’acceptation des DNS Tailscale :

1

sudo tailscale set --accept-dns=false

Ne supprimez pas systemd-resolved. Configurez ensuite les DNS de l’interface principale avec systemd-networkd.

Identifiez l’interface :

1

networkctl list

Puis vérifiez son nom, par exemple ens3 :

1

networkctl status ens3

Créez ou modifiez un fichier .network :

1

sudo nano /etc/systemd/network/20-ens3.network

Exemple avec DHCP :

1
2
3
4
5
6
7
8

[Match]
Name=ens3

[Network]
DHCP=yes
DNS=192.168.0.1
DNS=1.1.1.1
Domains=~.

Exemple avec IP statique :

1
2
3
4
5
6
7
8
9

[Match]
Name=ens3

[Network]
Address=192.168.0.215/24
Gateway=192.168.0.1
DNS=192.168.0.1
DNS=1.1.1.1
Domains=~.

Puis rechargez :

1
2

sudo systemctl restart systemd-networkd
sudo systemctl restart systemd-resolved

Contrôlez :

1
2

resolvectl status
resolvectl query debian.org

Domains=~. indique à systemd-resolved d’utiliser cette interface pour les domaines qui ne sont pas associés à une route DNS plus spécifique. Les DNS et domaines peuvent effectivement être déclarés par interface dans les fichiers .network. [1,2]

Pour que /etc/resolv.conf utilise bien le stub local :

1

ls -l /etc/resolv.conf

Vous devriez idéalement voir un lien vers :

1

/run/systemd/resolve/stub-resolv.conf

Si nécessaire :

1
2

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved

Pour vos serveurs Debian et Proxmox

Puisque systemd-networkd, NetworkManager et systemd-resolved sont inactifs, ne configurez pas resolvectl sur ces machines : rien ne maintiendra cette configuration après redémarrage.

Vérifiez plutôt le gestionnaire réseau :

1
2

systemctl is-active networking
systemctl is-active ifupdown2

Sur Proxmox, la configuration est généralement dans :

1

cat /etc/network/interfaces

Vous pouvez y ajouter les DNS :

1
2
3
4
5

auto vmbr0
iface vmbr0 inet static
    address 192.168.0.215/24
    gateway 192.168.0.1
    dns-nameservers 192.168.0.1 1.1.1.1

Puis rechargez prudemment :

1

ifreload -a

Évitez de faire systemctl restart networking sur un serveur distant : vous pourriez perdre votre session SSH.

Sur ces serveurs, si vous ne souhaitez pas que Tailscale remplace /etc/resolv.conf :

1

sudo tailscale set --accept-dns=false

Puis écrivez un fichier DNS classique :

1

sudo nano /etc/resolv.conf

1
2
3

search home.arpa
nameserver 192.168.0.1
nameserver 1.1.1.1

Mais vérifiez d’abord si le fichier est encore géré par Tailscale :

1

head -n 5 /etc/resolv.conf

S’il contient :

1

# resolv.conf(5) file generated by tailscale

désactivez accept-dns avant de le modifier, sinon Tailscale le réécrira.

Configuration recommandée

Pour vos VPS Debian :

1
2

systemd-networkd actif
systemd-resolved actif

Puis, selon le besoin :

1

sudo tailscale set --accept-dns=false

et DNS configurés dans le fichier .network.

Pour vos serveurs Debian/Proxmox :

1
2

ifupdown/ifupdown2 actif
systemd-resolved inactif

Puis :

1

sudo tailscale set --accept-dns=false

et DNS configurés dans /etc/network/interfaces ou /etc/resolv.conf.

C’est le choix le plus prévisible si Tailscale sert uniquement de réseau privé et que vous voulez que la résolution DNS Internet continue de fonctionner même lorsque Tailscale est arrêté.

Lire la suite [1] systemd-resolved.service(8) — https://manpages.debian.org/testing/systemd/systemd-resolved.service.8.en.html [2] resolved.conf — https://www.freedesktop.org/software/systemd/man/resolved.conf.html

Message 6 sur 8 de l'utilisateur - 06/10/2026 13:50:12: Avec mes configurations actuelles, en cas de 'problème' sur le réseau tailscale pas d'incidence sur le reste?

Oui, en principe, avec vos configurations actuelles, un problème du réseau Tailscale ne devrait pas affecter la résolution DNS Internet ni le réseau classique, mais il y a une nuance importante.

Sur vos VPS Debian, vous avez :

1
2

nameserver 127.0.0.53
search tailscale.xoyize.xyz

127.0.0.53 est seulement le relais local de systemd-resolved. Il faut vérifier vers quels DNS il envoie réellement les requêtes :

1

resolvectl status

Si vous voyez à la fois :

  • un DNS associé à Tailscale ;
  • un DNS associé à l’interface réseau principale, comme ens3 ;

alors la perte de Tailscale devrait seulement empêcher :

  • la résolution des noms *.tailscale.xoyize.xyz ;
  • l’accès aux adresses Tailscale 100.x.y.z ;
  • les connexions entre vos serveurs qui passent exclusivement par Tailscale.

Les noms Internet classiques comme debian.org, github.com ou les dépôts Debian devraient continuer à fonctionner via le DNS de l’interface principale.

En revanche, si resolvectl status ne montre qu’un DNS Tailscale, la panne peut provoquer des délais ou une absence de résolution DNS générale. Le contenu de /etc/resolv.conf ne permet pas de le déterminer, car 127.0.0.53 masque les DNS réellement utilisés.

À vérifier sur un VPS :

1
2
3

resolvectl status
resolvectl dns
resolvectl domain

Vous pouvez aussi tester séparément :

1
2

resolvectl query debian.org
resolvectl query nom-machine.tailscale.xoyize.xyz

Puis simuler l’arrêt de Tailscale sur une machine non critique :

1

sudo tailscale down

Testez alors :

1
2
3

ping -c 2 1.1.1.1
resolvectl query debian.org
resolvectl query autre-machine.tailscale.xoyize.xyz

Le résultat attendu est :

  • ping 1.1.1.1 fonctionne ;
  • debian.org est résolu ;
  • le nom Tailscale ne l’est plus ;
  • les adresses 100.x.y.z ne sont plus accessibles.

Pour remettre Tailscale :

1

sudo tailscale up

Sur vos serveurs Debian et Proxmox, où systemd-resolved est inactif, le risque est plus simple à identifier :

1

cat /etc/resolv.conf

Si le fichier contient uniquement :

1

nameserver 100.100.100.100

ou :

1

nameserver fd7a:115c:a1e0::53

alors une panne Tailscale peut effectivement casser toute la résolution DNS de ces serveurs. Si le fichier contient aussi un DNS local ou public indépendant, par exemple :

1
2

nameserver 192.168.0.1
nameserver 1.1.1.1

la résolution classique devrait continuer.

Vous pouvez tester directement les DNS indépendamment de Tailscale :

1
2

dig @192.168.0.1 debian.org
dig @1.1.1.1 debian.org

Conclusion : sur vos VPS, le risque est faible si resolvectl status affiche un DNS indépendant de Tailscale. Sur Proxmox et les autres serveurs sans systemd-resolved, vérifiez directement /etc/resolv.conf, car une configuration contenant uniquement les DNS Tailscale pourrait interrompre toute résolution lors d’une panne Tailscale.

Message 7 sur 8 de l'utilisateur - 06/10/2026 13:51:40: Un exemple resolvectl VPS 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

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

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

Link 4 (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

Cette configuration est bonne et résiliente. Votre DNS Tailscale est limité aux noms internes Tailscale et aux recherches inversées des adresses 100.x.y.z.

La partie importante est :

1
2
3
4
5

Link 2 (eth0)
    Current Scopes: DNS
    Current DNS Server: 2a02:c207::1:53
    DNS Servers: 213.136.95.10 213.136.95.11 2a02:c207::1:53
    Default Route: yes

Votre interface Internet eth0 possède trois DNS indépendants de Tailscale et est la route DNS par défaut.

La partie Tailscale indique :

1
2
3
4

Link 4 (tailscale0)
    Current Scopes: DNS
    Current DNS Server: 100.100.100.100
    DNS Domain: tailscale.xoyize.xyz ...

Les domaines associés à tailscale0 sont des routes DNS spécifiques. Ainsi :

  • serveur.tailscale.xoyize.xyz est envoyé vers Tailscale ;
  • les recherches inversées d’adresses 100.x.y.z sont envoyées vers Tailscale ;
  • les autres domaines, comme debian.org, sont envoyés vers les DNS de eth0.

Le point essentiel est :

1
2

Link 2 (eth0)
    Default Route: yes

et non :

1
2

Link 4 (tailscale0)
    Default Route: yes

Donc, si Tailscale tombe :

  • la résolution de debian.org, des dépôts Debian et des services Internet doit continuer ;
  • la résolution des noms *.tailscale.xoyize.xyz échouera ;
  • les recherches inversées des adresses Tailscale échoueront ;
  • les connexions utilisant les adresses 100.x.y.z échoueront ;
  • le trafic Internet normal via eth0 ne devrait pas être affecté.

Votre configuration correspond au fonctionnement attendu du split DNS : Tailscale ne prend en charge que ses domaines internes, tandis que eth0 garde la route DNS générale.

Vous pouvez le confirmer avec ces tests :

1
2

resolvectl query debian.org
resolvectl query votre-machine.tailscale.xoyize.xyz

Pour voir quelle interface est utilisée :

1

resolvectl query debian.org --legend=yes

Vous pouvez aussi arrêter Tailscale temporairement :

1

sudo tailscale down

Puis tester :

1
2
3

resolvectl query debian.org
resolvectl query votre-machine.tailscale.xoyize.xyz
ping -c 2 1.1.1.1

Le résultat normal est :

1
2
3

debian.org                         fonctionne
votre-machine.tailscale.xoyize.xyz échoue
1.1.1.1                            fonctionne

Remettez ensuite Tailscale en service avec :

1

sudo tailscale up

Une nuance : si votre application utilise les noms Tailscale pour joindre vos autres serveurs, cette application sera évidemment indisponible pendant la panne Tailscale, même si le DNS Internet et le réseau eth0 continuent à fonctionner.

Message 8 sur 8 de l'utilisateur - 06/10/2026 13:53:38: Par contre sur les machines gérées par ifup ?

Sur les machines gérées par ifup/ifupdown ou ifupdown2, il n’y a généralement pas de split DNS comparable à celui que vous voyez avec systemd-resolved.

Si Tailscale est autorisé à gérer le DNS :

1

sudo tailscale set --accept-dns=true

il peut remplacer /etc/resolv.conf par :

1
2
3

nameserver 100.100.100.100
nameserver fd7a:115c:a1e0::53
search tailscale.xoyize.xyz

Dans ce cas, toutes les requêtes DNS passent d’abord par Tailscale. Il n’y a pas forcément de DNS indépendant associé à l’interface réseau classique.

Conséquence en cas de panne Tailscale

Si /etc/resolv.conf contient uniquement :

1
2

nameserver 100.100.100.100
nameserver fd7a:115c:a1e0::53

alors une panne ou une déconnexion de Tailscale peut provoquer :

  • l’échec de résolution des noms Internet ;
  • l’impossibilité de résoudre les noms *.tailscale.xoyize.xyz ;
  • des délais d’attente lors des commandes apt, curl, ping par nom, etc.

Le réseau IP classique peut continuer à fonctionner, mais les logiciels utilisant des noms DNS seront perturbés.

Vérifiez vos machines :

1

cat /etc/resolv.conf

et :

1

tailscale debug prefs | grep -i acceptdns

Configuration recommandée avec ifup/ifupdown2

Si Tailscale sert uniquement de réseau privé, désactivez sa gestion DNS :

1

sudo tailscale set --accept-dns=false

Puis configurez les DNS classiques dans /etc/network/interfaces :

1
2
3
4
5

auto vmbr0
iface vmbr0 inet static
    address 192.168.0.215/24
    gateway 192.168.0.1
    dns-nameservers 192.168.0.1 1.1.1.1

Pour une interface physique classique :

1
2
3

auto eth0
iface eth0 inet dhcp
    dns-nameservers 192.168.0.1 1.1.1.1

Puis, avec ifupdown2 :

1

sudo ifreload -a

Sur une machine distante, évitez de redémarrer brutalement le service réseau avec :

1

systemctl restart networking

car vous pourriez perdre la connexion SSH.

Attention à dns-nameservers

La directive :

1

dns-nameservers 192.168.0.1 1.1.1.1

n’est réellement appliquée que si un mécanisme comme resolvconf ou un paquet équivalent est installé et utilisé. Vérifiez :

1
2

command -v resolvconf
ls -l /etc/resolv.conf

Si aucun gestionnaire ne met à jour le fichier, vous pouvez configurer /etc/resolv.conf directement après avoir désactivé le DNS Tailscale :

1
2

sudo tailscale set --accept-dns=false
sudo nano /etc/resolv.conf

Exemple :

1
2
3

search home.arpa
nameserver 192.168.0.1
nameserver 1.1.1.1

Vérifiez ensuite :

1
2

getent hosts debian.org
cat /etc/resolv.conf

Pour Proxmox

Sur Proxmox, les paramètres DNS peuvent aussi être définis dans :

Datacenter → votre nœud → System → DNS

ou avec :

1

pvenode config set --dns1 192.168.0.1 --dns2 1.1.1.1

Puis vérifiez :

1

cat /etc/resolv.conf

Dans votre cas, pour les machines ifup et Proxmox, le choix le plus robuste est généralement :

1

sudo tailscale set --accept-dns=false

et des DNS indépendants de Tailscale dans /etc/network/interfaces, dans la configuration DNS Proxmox ou dans /etc/resolv.conf, selon le mécanisme utilisé par chaque machine.