duck.ai_2026-10-27_11-48-58

duck.ai_2026-10-27_11-48-58

Notes

Cette conversation a été générée avec Duck.ai (https://duck.ai) à l’aide du modèle GPT-6 Luna d’OpenAI. Les chats IA peuvent afficher des informations inexactes ou offensantes (voir https://duckduckgo.com/duckai/privacy-terms pour en savoir plus).

====================

Message 1 sur 11 de l’utilisateur - 27/10/2026 10:37:18: Portable PC wifi cachyos, PC Bureau Lan KDE Plasma EndeavourOs. Accès internet sur portable pas sur pc bureau. Procédure ligne de commande ou autre pour déterminer la cause?

GPT-6 Luna: <!– Troubleshooting Linux connectivity

I need to address the internet issue on a desktop running EndeavourOS, specifically checking the LAN connection. Since I’m working with Linux and KDE on a CachyOS laptop, I should draft some diagnostic commands to identify why there’s no internet on the desktop. While I might typically rely on web searches for information, I think focusing on actionable commands and interpreting the results will be more effective. I could consider using NetworkManager or nmcli for troubleshooting. –> Oui. Le plus efficace est de tester du câble jusqu’au DNS, dans cet ordre, sur le PC fixe. Les commandes ci-dessous ne modifient pas la configuration. Sur KDE, NetworkManager est généralement pilotable avec nmcli.

  1. Vérifier que la carte Ethernet et le lien sont détectés 
    1
2

    nmcli device status
ip -br link

    Repérez l’interface Ethernet (enp…, eno…). Si elle est disconnected ou unavailable, vérifiez le câble, le port du routeur/switch et les voyants. Si elle est unmanaged, NetworkManager ne la gère pas.

  2. Vérifier l’adresse IP et la passerelle 
    1
2

    ip -4 addr
ip route

    Sur l’interface Ethernet, cherchez une adresse privée (souvent 192.168…, 10.… ou 172.16–31.…) et une route default via ….

    • Pas d’adresse IPv4, ou une adresse 169.254.… : le PC n’a probablement pas reçu de bail DHCP.
    • Pas de route default : il n’a pas de passerelle par défaut.
  3. Tester la connexion par étapes

L’adresse de passerelle indiquée après default via à l’étape précédente est à utiliser à la place de <passerelle> :

1
2
3

ping -c 3 <passerelle>
ping -c 3 1.1.1.1
getent hosts example.com
  • Passerelle inaccessible : problème entre le PC et le routeur — câble, port, DHCP, configuration IP ou réseau local.
  • Passerelle joignable, mais 1.1.1.1 inaccessible : problème de route vers Internet ou côté routeur/FAI.
  • 1.1.1.1 joignable, mais le nom de domaine ne se résout pas : problème DNS.

nmcli device status, ip addr et ip route sont des vérifications usuelles pour diagnostiquer l’état du réseau. [1,2]

  1. Récupérer les détails utiles 
    1
2
3

    nmcli connection show --active
nmcli device show
journalctl -b -u NetworkManager --no-pager | tail -80

Si l’interface est connectée mais sans adresse, vous pouvez essayer de relancer sa connexion — cela coupe brièvement le réseau :

1

nmcli device connect <interface>

Remplacez <interface> par le nom relevé à l’étape 1, par exemple enp3s0.

Comparez aussi avec le portable sur le même routeur et le même câble, si possible. Si le portable fonctionne avec ce câble et ce port, le souci est plus probablement lié à la configuration ou à la carte réseau du PC fixe.

Vous pouvez coller ici les sorties de nmcli device status, ip -4 addr et ip route (masquez les adresses MAC si vous préférez) : elles permettront de situer précisément la panne.

Lire la suite [1] 5 Linux network troubleshooting commands — https://www.redhat.com/en/blog/five-network-commands [2] Get started with NetworkManager on Linux — https://opensource.com/article/22/4/networkmanager-linux

Message 2 sur 11 de l’utilisateur - 27/10/2026 10:46:50: Tout semble correct, mais pas de connexion internet?

GPT-6 Luna: <!– Clarifying diagnostics commands

I think I need to clarify the diagnostic results a bit more. I should provide targeted commands like curl, tracepath, firewall proxy, route, and possibly check if the interface is connected. I also need to remember that the response should be in French. There’s no search needed right now, as the instructions might specify that I should always search for real-world information, so I’ll focus on potential avenues related to those commands. –> Dans ce cas, il faut distinguer une panne réseau réelle d’un problème qui ne touche que le navigateur ou certains logiciels. Lancez ces tests sur le PC fixe et notez précisément les messages :

1
2
3
4
5

ip route get 1.1.1.1
ping -c 3 1.1.1.1
getent hosts example.com
curl -4 -v --max-time 10 https://example.com -o /dev/null
curl -6 -v --max-time 10 https://example.com -o /dev/null

ip route get indique par quelle interface et quelle passerelle le trafic devrait sortir ; ensuite, le ping par IP teste la connectivité sans dépendre du DNS. curl vérifie l’accès HTTPS, plus proche de l’usage d’un navigateur. [1]

Interprétation rapide :

  • ip route get indique Network is unreachable : route ou interface à corriger.
  • Le ping vers 1.1.1.1 échoue : problème de routage, de pare-feu ou en amont du PC. Un ping bloqué ne suffit toutefois pas, à lui seul, à prouver qu’Internet est coupé.
  • Le ping par IP fonctionne, mais getent hosts example.com échoue : piste DNS.
  • La résolution fonctionne, mais curl -4 échoue : regardez le détail de l’erreur — proxy, pare-feu, port 443 ou certificats peuvent être en cause.
  • curl -4 fonctionne et curl -6 échoue : problème possible avec IPv6 ; les applications qui le privilégient peuvent alors sembler hors ligne.

Pour vérifier si un VPN ou un proxy interfère :

1
2

nmcli connection show --active
env | grep -i proxy

Ne changez pas encore les DNS ni le pare-feu avant d’avoir ces résultats. Collez ici les sorties des commandes, en masquant votre adresse IP publique si elle apparaît : on pourra identifier l’étape exacte où ça bloque.

Lire la suite [1] Check Internet Connection in Linux (2026): curl, ping, DNS, … — https://www.golinuxcloud.com/commands-check-if-connected-to-internet-shell/

Message 3 sur 11 de l’utilisateur - 27/10/2026 10:49:41: [yann@pc1 ~]$ ip route get 1.1.1.1 ping -c 3 1.1.1.1 getent hosts example.com curl -4 -v –max-time 10 https://example.com -o /dev/null curl -6 -v –max-time 10 https://example.com -o /dev/null 1.1.1.1 via 192.168.0.254 dev enp7s0 src 192.168.0.20 uid 1000 cache PING 1.1.1.1 (1.1.1.1) 56(84) octets de données. 64 octets de 1.1.1.1 : icmp_seq=1 ttl=60 temps=8.36 ms 64 octets de 1.1.1.1 : icmp_seq=2 ttl=60 temps=8.03 ms 64 octets de 1.1.1.1 : icmp_seq=3 ttl=60 temps=7.72 ms

— statistiques ping 1.1.1.1 — 3 paquets transmis, 3 reçus, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 7.718/8.036/8.363/0.263 ms

  • Could not resolve host: example.com
  • Could not resolve host: example.com
  • Could not resolve: example.com:443
  • closing connection #0 curl: (6) Could not resolve host: example.com
  • Could not resolve host: example.com
  • Could not resolve host: example.com
  • Could not resolve: example.com:443
  • closing connection #0 curl: (6) Could not resolve host: example.com

GPT-6 Luna: Les tests isolent la panne : le PC atteint Internet par adresse IP, mais la résolution DNS échoue. C’est pourquoi curl ne peut pas trouver example.com.

Commencez par voir quels DNS sont configurés :

1
2

nmcli device show enp7s0 | grep -E 'IP4.DNS|IP6.DNS'
cat /etc/resolv.conf

Puis testez un serveur DNS directement, si dig est installé :

1
2

dig @1.1.1.1 example.com
dig @9.9.9.9 example.com

Si l’un répond avec une adresse IP, vous pouvez configurer temporairement cette paire de DNS pour la connexion Ethernet. Repérez d’abord son nom :

1

nmcli connection show --active

Puis remplacez <connexion> par le nom affiché :

1
2

sudo nmcli connection modify "<connexion>" ipv4.dns "1.1.1.1 9.9.9.9" ipv4.ignore-auto-dns yes
sudo nmcli connection up "<connexion>"

Retestez ensuite :

1
2

getent hosts example.com
curl -4 -I --max-time 10 https://example.com

Pour revenir aux DNS fournis automatiquement par le routeur :

1
2

sudo nmcli connection modify "<connexion>" ipv4.ignore-auto-dns no ipv4.dns ""
sudo nmcli connection up "<connexion>"

Si dig @1.1.1.1 et dig @9.9.9.9 échouent, envoyez les sorties des deux commandes DNS, de nmcli device show enp7s0 | grep -E 'IP4.DNS|IP6.DNS' et de cat /etc/resolv.conf : ça aidera à déterminer si le blocage vient du routeur, de NetworkManager ou de la configuration DNS locale.

Message 4 sur 11 de l’utilisateur - 27/10/2026 10:51:51: [yann@pc1 ~]$ nmcli device show enp7s0 | grep -E ‘IP4.DNS|IP6.DNS’ cat /etc/resolv.conf IP4.DNS[1]: 192.168.0.254 IP4.DNS[2]: 1.1.1.1 IP6.DNS[1]: fd0f:ee:b0::1

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 [yann@pc1 ~]$ dig @1.1.1.1 example.com dig @9.9.9.9 example.com

; «» DiG 9.20.30 «» @1.1.1.1 example.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -»HEADER«- opcode: QUERY, status: NOERROR, id: 48456 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;example.com. IN A

;; ANSWER SECTION: example.com. 16 IN A 172.66.147.243 example.com. 16 IN A 104.20.23.154

;; Query time: 9 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP) ;; WHEN: Tue Oct 27 10:51:19 CET 2026 ;; MSG SIZE rcvd: 72

; «» DiG 9.20.30 «» @9.9.9.9 example.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -»HEADER«- opcode: QUERY, status: NOERROR, id: 35860 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;example.com. IN A

;; ANSWER SECTION: example.com. 191 IN A 172.66.147.243 example.com. 191 IN A 104.20.23.154

;; Query time: 9 msec ;; SERVER: 9.9.9.9#53(9.9.9.9) (UDP) ;; WHEN: Tue Oct 27 10:51:19 CET 2026 ;; MSG SIZE rcvd: 72

GPT-6 Luna: <!– Exploring Tailscale DNS settings

I’m looking into how Tailscale overwrites resolv.conf and MagicDNS. I might want to inspect the Tailscale DNS settings. Perhaps disabling the accept-dns option with the command tailscale set –accept-dns=false could help, or maybe I could adjust global node preferences. I should consider searching on DuckDuckGo for more information about the Tailscale product to see if there’s anything I’m missing. Let’s see what I can find! –> On a bien trouvé la cause : Tailscale a remplacé /etc/resolv.conf. Le système envoie donc les recherches DNS à 100.100.100.100 (le DNS local de Tailscale), alors que les requêtes directes vers 1.1.1.1 et 9.9.9.9 fonctionnent. Tailscale peut gérer ce fichier quand ses réglages DNS sont acceptés par la machine. [1,2]

Si vous n’avez pas besoin des réglages DNS de Tailscale sur ce PC, désactivez-les pour cette machine :

1

sudo tailscale set --accept-dns=false

Puis testez :

1
2

getent hosts example.com
curl -4 -I --max-time 10 https://example.com

Cela désactive l’utilisation des DNS Tailscale sur ce PC, mais ne désactive pas Tailscale lui-même. Vous pourrez rétablir le comportement précédent avec :

1

sudo tailscale set --accept-dns=true

Si vous avez besoin de MagicDNS ou de noms privés Tailscale, ne désactivez pas cette option : il faudra plutôt corriger l’intégration DNS avec le gestionnaire DNS local. La documentation Tailscale indique que --accept-dns=false ignore les réglages DNS du réseau Tailscale pour ce client. [2]

Lire la suite [1] Why is resolv.conf being overwritten? — https://tailscale.com/docs/reference/faq/dns-resolv-conf [2] Manage client preferences · Tailscale Docs — https://tailscale.com/docs/features/client/manage-preferences

Message 5 sur 11 de l’utilisateur - 27/10/2026 10:53:38: [yann@pc1 ~]$ sudo tailscale set –accept-dns=false [yann@pc1 ~]$ getent hosts example.com curl -4 -I –max-time 10 https://example.com curl: (6) Could not resolve host: example.com

GPT-6 Luna: <!– Diagnosing Tailscale DNS issues

I need to take some next steps regarding Tailscale settings and how they interact with resolv.conf. It seems like the symlink for resolv.conf might be overridden by Tailscale. Setting accept-dns false could help restore the original resolv.conf. I should inspect the status of systemd-resolved, check the output of readlink -f /etc/resolv.conf, and review the NetworkManager configuration. I must decide the best way to address the DNS configuration changes that Tailscale might be enforcing. –> dig a confirmé que les serveurs DNS publics répondent. Le problème est que getent et curl consultent encore /etc/resolv.conf, qui pointe vers le DNS de Tailscale. Désactiver --accept-dns ne remplace pas forcément immédiatement le fichier déjà présent ; Tailscale recommande d’utiliser un gestionnaire DNS cohérent plutôt que de laisser plusieurs services gérer ce fichier. [1,2]

Vérifiez d’abord si la commande a bien laissé le fichier inchangé :

1
2
3

cat /etc/resolv.conf
readlink -f /etc/resolv.conf
nmcli -g IP4.DNS device show enp7s0

Si cat affiche toujours nameserver 100.100.100.100, essayez de faire utiliser à /etc/resolv.conf le fichier géré par NetworkManager :

1

ls -l /run/NetworkManager/resolv.conf

Si ce fichier existe, exécutez :

1
2

sudo ln -sf /run/NetworkManager/resolv.conf /etc/resolv.conf
sudo systemctl restart NetworkManager

Puis testez :

1
2
3

cat /etc/resolv.conf
getent hosts example.com
curl -4 -I --max-time 10 https://example.com

Si /run/NetworkManager/resolv.conf n’existe pas, ne créez pas le lien : envoyez plutôt les sorties des trois commandes de vérification, ainsi que :

1
2

systemctl is-active systemd-resolved
resolvectl status

Le DNS de Tailscale peut encore être nécessaire pour résoudre les noms privés de votre réseau Tailscale ; --accept-dns=false désactive leur prise en charge automatique par ce PC. [1]

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

Message 6 sur 11 de l’utilisateur - 27/10/2026 11:01:10: OK. Mais comment résoudre la cohabitation tailscale accept-dns true et et networkmanager. Localement (réseau local et tailscale), le dns est géré pa technitium

GPT-6 Luna: <!– Configuring Technitium DNS

I’m considering the use of Technitium as a DNS server for both local domains and upstream needs. The user’s focus seems to be on managing DNS for their local network and Tailscale environment. I can configure Technitium to serve requests over Tailscale IP, but there’s a challenge with boot and local DNS issues. It might help to ensure that Technitium’s IP is set properly in the LAN and advertised through the subnet for remote access. There are steps to outline, including setting up Technitium with a static IP and adjusting settings in Tailscale.Searching DNS Configuration

I’m looking into the Tailscale settings, specifically the “accept-dns true” configuration. There’s a mention that NetworkManager may not have manually set the resolv.conf file and is using systemd-resolved instead. To clarify, I think I should check the current official documentation for Tailscale and NetworkManager, as well as how they interact with systemd-resolved and Technitium. Doing a web search might be helpful to gather updated and relevant information on this setup. –> Oui, Tailscale et NetworkManager peuvent cohabiter. Le point important est d’éviter qu’ils écrivent tous deux directement dans /etc/resolv.conf. La solution la plus propre sur EndeavourOS est généralement : NetworkManager gère l’interface réseau, systemd-resolved gère la résolution DNS, et Tailscale lui transmet ses règles DNS. Tailscale recommande systemd-resolved sur Linux pour cette cohabitation. [1]

Configuration conseillée

  1. Réactivez l’acceptation des DNS Tailscale : 
    1

    sudo tailscale set --accept-dns=true
  2. Vérifiez si systemd-resolved est actif : 
    1

    systemctl is-active systemd-resolved

S’il répond inactive, activez-le :

1

sudo systemctl enable --now systemd-resolved
  1. Configurez NetworkManager pour utiliser systemd-resolved : 
    1
2
3
4
5

    sudo install -d /etc/NetworkManager/conf.d
sudo tee /etc/NetworkManager/conf.d/dns.conf >/dev/null <<'EOF'
[main]
dns=systemd-resolved
EOF
  2. Faites pointer /etc/resolv.conf vers le stub de systemd-resolved, puis relancez les services : 
    1
2
3

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

Vérifiez ensuite :

1
2
3

readlink -f /etc/resolv.conf
resolvectl status
getent hosts example.com

Le lien doit aboutir à /run/systemd/resolve/stub-resolv.conf. Dans resolvectl status, vérifiez les DNS de l’interface Ethernet et ceux fournis par Tailscale. NetworkManager fournit le DNS de la connexion locale ; Tailscale peut aussi appliquer ses DNS et ses domaines de recherche. [1]

Faire utiliser Technitium partout

Dans la console d’administration Tailscale, ajoutez l’adresse de Technitium comme Global nameserver. Activez Override DNS servers si vous voulez que les appareils Tailscale l’utilisent pour toutes leurs requêtes, même lorsqu’ils sont hors de chez vous. Il faut que les clients Tailscale puissent joindre cette adresse : si Technitium n’est accessible qu’à l’adresse LAN, configurez aussi l’accès à ce réseau par une route de sous-réseau Tailscale ; une adresse Tailscale du serveur DNS peut également convenir. [2]

Dans ce scénario, Technitium répond aux requêtes du réseau local et du tailnet, et peut faire suivre les requêtes Internet à ses serveurs amont. Gardez MagicDNS activé si vous souhaitez conserver les noms Tailscale des machines : il complète les noms gérés par Technitium. Pour que les mêmes noms d’hôtes renvoient une adresse LAN à la maison et une adresse Tailscale à distance, il faut une configuration DNS à horizon fractionné côté Technitium ; un DNS global unique ne choisit pas automatiquement la bonne adresse selon l’origine de la requête. [2,3]

Si une commande échoue, ne modifiez pas davantage /etc/resolv.conf à la main : envoyez les sorties de systemctl is-active systemd-resolved, readlink -f /etc/resolv.conf et resolvectl status.

Lire la suite [1] Why is resolv.conf being overwritten? — https://tailscale.com/docs/reference/faq/dns-resolv-conf [2] DNS in Tailscale — https://tailscale.com/docs/reference/dns-in-tailscale [3] Technitium DNS Server with Tailscale - James Brooks — https://blog.jamesbrooks.net/posts/technitium-dns-server-with-tailscale/

Message 7 sur 11 de l’utilisateur - 27/10/2026 11:08:29: Tout me paraît correct

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
32
33
34
35

[yann@pc1 ~]$ systemctl is-active systemd-resolved
active
[yann@pc1 ~]$ readlink -f /etc/resolv.conf
/run/systemd/resolve/stub-resolv.conf
[yann@pc1 ~]$ resolvectl status
Global
           Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: stub
Fallback DNS Servers: 9.9.9.9#dns.quad9.net 2620:fe::9#dns.quad9.net 1.1.1.1#cloudflare-dns.com
                      2606:4700:4700::1111#cloudflare-dns.com 8.8.8.8#dns.google
                      2001:4860:4860::8888#dns.google

Link 2 (enp7s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6
         Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.0.254
       DNS Servers: 192.168.0.254 1.1.1.1 fd0f:ee:b0::1
     Default Route: yes

Link 3 (enp8s0)
    Current Scopes: none
         Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
     Default Route: no

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

GPT-6 Luna: Cette sortie montre que systemd-resolved est bien en place et que Tailscale lui transmet ses règles DNS. Les domaines Tailscale sont routés vers 100.100.100.100; les requêtes DNS ordinaires devraient passer par l’interface Ethernet, vers 192.168.0.254 ou 1.1.1.1.

En revanche, Technitium n’apparaît pas dans la liste des DNS Ethernet. Il est utilisé seulement si 192.168.0.254 est votre routeur et que celui-ci transmet ses requêtes à Technitium.

Après le changement de resolv.conf, testez à nouveau :

1
2
3
4

sudo resolvectl flush-caches
resolvectl query example.com
getent hosts example.com
curl -4 -I --max-time 10 https://example.com

Si ces tests fonctionnent, la résolution DNS est rétablie. Si resolvectl query fonctionne mais que getent échoue, dites-le : ce serait alors un souci différent, au niveau de la résolution de noms utilisée par les applications.

Si vous voulez que Technitium soit directement le DNS du PC, configurez son adresse LAN comme DNS IPv4 de la connexion Ethernet dans NetworkManager. Pour connaître le nom de cette connexion :

1

nmcli connection show --active

Ne changez rien pour l’instant si 192.168.0.254 est bien votre serveur Technitium, ou si votre routeur lui transmet les requêtes.

Message 8 sur 11 de l’utilisateur - 27/10/2026 11:13:43: En résumé, la mise en place de systemd-resolved permet de garder la configuration tailscale intacte

GPT-6 Luna: Oui. Avec systemd-resolved actif et /etc/resolv.conf lié à son fichier stub, NetworkManager et Tailscale peuvent cohabiter sans écraser directement la configuration DNS l’un de l’autre.

Dans votre sortie, les requêtes DNS ordinaires passent par l’Ethernet (192.168.0.254, 1.1.1.1), tandis que les domaines Tailscale passent par 100.100.100.100. La configuration Tailscale est donc conservée, avec une précision : ce PC n’utilise directement Technitium que si 192.168.0.254 est Technitium ou lui transmet les requêtes.

Message 9 sur 11 de l’utilisateur - 27/10/2026 11:14:53: Possible de faire un rapport au format mardown sur cet incident?

GPT-6 Luna:

Rapport d’incident — panne DNS sur le PC fixe EndeavourOS

Date : 27 octobre 2026
Machine concernée : pc1, EndeavourOS avec KDE Plasma
Réseau : Ethernet, interface enp7s0
Symptôme : le PC fixe n’accédait pas aux sites Internet par leur nom de domaine. Le portable connecté en Wi-Fi avait accès à Internet.

Résumé

La connexion IP du PC fixe fonctionnait : la passerelle était présente et 1.1.1.1 répondait au ping. En revanche, les noms de domaine ne se résolvaient pas.

La cause était une configuration DNS conflictuelle : /etc/resolv.conf était géré par Tailscale et envoyait les requêtes au DNS local Tailscale (100.100.100.100). Le passage à systemd-resolved a rétabli une gestion commune du DNS par le système.

Diagnostic initial

La route vers Internet était présente :

1

1.1.1.1 via 192.168.0.254 dev enp7s0 src 192.168.0.20

La connectivité IP fonctionnait :

1

3 paquets transmis, 3 reçus, 0% packet loss

La résolution de noms échouait :

1

Could not resolve host: example.com

Des requêtes DNS directes vers 1.1.1.1 et 9.9.9.9 ont réussi. Cela a permis d’orienter le diagnostic vers la configuration DNS locale plutôt que vers la connexion Internet ou les serveurs DNS publics.

Cause identifiée

Le contenu initial de /etc/resolv.conf était :

1
2
3

# resolv.conf(5) file generated by tailscale
nameserver 100.100.100.100
nameserver fd7a:115c:a1e0::53

Les commandes getent et curl utilisaient ce fichier pour résoudre les noms. La présence de serveurs DNS configurés dans NetworkManager ne suffisait donc pas, à elle seule, à garantir que les applications les utilisaient.

Correction appliquée

Le service systemd-resolved a été activé et configuré pour servir d’intermédiaire DNS entre NetworkManager et Tailscale. Le lien /etc/resolv.conf pointe désormais vers le fichier stub de systemd-resolved :

1

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

L’état vérifié était :

1
2

systemd-resolved : active
resolv.conf mode : stub

resolvectl status montrait :

  • sur enp7s0, les DNS locaux 192.168.0.254 et 1.1.1.1 ;
  • sur tailscale0, le DNS Tailscale 100.100.100.100 et les domaines de recherche Tailscale.

Cela permet à systemd-resolved d’orienter les requêtes selon le domaine : DNS de l’interface Ethernet pour les noms ordinaires, DNS Tailscale pour les domaines Tailscale.

État après correction

La configuration observée est cohérente avec une cohabitation entre NetworkManager, systemd-resolved et Tailscale. Les tests finaux de résolution et d’accès HTTPS n’ont pas été communiqués dans la conversation ; il reste donc à confirmer le rétablissement complet avec :

1
2
3
4

sudo resolvectl flush-caches
resolvectl query example.com
getent hosts example.com
curl -4 -I --max-time 10 https://example.com

Point à vérifier concernant Technitium

resolvectl status indiquait 192.168.0.254 et 1.1.1.1 comme DNS sur l’interface Ethernet. Technitium n’y apparaissait pas directement.

Technitium est donc utilisé par le PC si :

  • il est lui-même accessible à l’adresse 192.168.0.254, ou
  • le routeur à cette adresse transmet les requêtes DNS à Technitium.

Sinon, il faut configurer son adresse comme DNS de la connexion Ethernet dans NetworkManager et, pour les appareils Tailscale distants, vérifier qu’ils peuvent joindre ce serveur DNS.

Conclusion

La panne ne venait pas d’une absence de connexion IP : elle venait du chemin de résolution DNS utilisé par les applications. L’intégration avec systemd-resolved permet à NetworkManager et Tailscale de conserver leurs réglages DNS sans qu’ils écrasent directement le même fichier.

Message 10 sur 11 de l’utilisateur - 27/10/2026 11:21:27: Une dernière question, est il préférable d’utiliser systemd-resolved sur les systèmes dont le réseau est géré par NetworkManager

GPT-6 Luna: Pas forcément. NetworkManager fonctionne très bien sans systemd-resolved ; ce n’est pas une obligation ni un choix universellement préférable.

Dans votre cas, en revanche, systemd-resolved est utile : il sert de point de coordination entre NetworkManager et Tailscale, qui ont tous deux des informations DNS à fournir. Il permet notamment d’associer certains domaines à des DNS spécifiques, comme les domaines Tailscale, sans remplacer les DNS de l’Ethernet pour toutes les requêtes.

En pratique :

  • NetworkManager seul convient si vous n’avez pas de VPN ou d’autre service qui modifie le DNS.
  • NetworkManager avec systemd-resolved est un bon choix lorsque vous utilisez Tailscale, des VPN ou du DNS à domaines séparés.
  • Il faut éviter que plusieurs services gèrent indépendamment /etc/resolv.conf.

Pour votre PC, gardez la configuration actuelle si les tests resolvectl query, getent et curl fonctionnent et que l’accès aux noms Tailscale est préservé.

Message 11 sur 11 de l’utilisateur - 27/10/2026 11:45:26: Des précisions sur les remarques suivantes Technitium est donc utilisé par le PC si :

1
2

il est lui-même accessible à l’adresse 192.168.0.254, ou
le routeur à cette adresse transmet les requêtes DNS à Technitium.

GPT-6 Luna: Précision : la sortie resolvectl status ne prouve pas que Technitium reçoit les requêtes. Elle indique que, pour le DNS ordinaire, systemd-resolved a comme serveurs 192.168.0.254 et 1.1.1.1. Tailscale gère séparément ses domaines, via 100.100.100.100.

Donc :

  • Si Technitium a l’adresse 192.168.0.254, le PC lui envoie directement ses requêtes — sous réserve que Technitium écoute bien sur le port DNS.
  • Si 192.168.0.254 est le routeur, le PC interroge d’abord le routeur. Il ne passe par Technitium que si le routeur lui transmet les requêtes DNS.
  • 1.1.1.1 est aussi configuré comme DNS Ethernet. Il constitue donc un chemin possible qui contourne Technitium pour certaines requêtes.

Pour vérifier le premier point, comparez l’adresse de Technitium à celles configurées :

1

resolvectl status

Pour tester séparément chaque serveur :

1
2

dig @192.168.0.254 example.com
dig @1.1.1.1 example.com

Ces commandes confirment qu’un serveur répond, mais ne montrent pas à elles seules si le routeur relaie sa requête à Technitium. Pour le savoir, lancez une requête et regardez si elle apparaît dans le tableau de bord ou les journaux de requêtes Technitium. Son tableau de bord expose des statistiques sur les requêtes traitées. [1]

Si vous voulez que le PC utilise Technitium de façon certaine, configurez l’adresse IP de Technitium comme DNS dans NetworkManager pour l’Ethernet et retirez 1.1.1.1 de cette connexion. Vérifiez aussi que les clients Tailscale peuvent joindre Technitium ; si son adresse est seulement sur le réseau local, il faut que ce réseau soit accessible depuis Tailscale. Technitium doit écouter sur l’interface concernée et accepter les requêtes DNS sur le port 53. [1]

Lire la suite [1] Help Topics | Technitium DNS Server — https://technitium.com/dns/help.html