Cache dnsmasq + DHCP : une configuration propre qui ne s’oppose pas à votre système

Le modèle mental : qui gère le DNS, qui gère le DHCP

Un déploiement « propre » de dnsmasq concerne principalement les frontières. DNS et DHCP sont des protocoles séparés, mais opérationnellement ils sont liés :
le DHCP distribue des adresses (et des serveurs DNS), et le DNS répond aux questions que vos clients posent lorsqu’ils essaient d’utiliser ces adresses.

Votre principale source de douleur est que deux composants différents croient être le chef :
un démon réécrivant /etc/resolv.conf, un autre démon se liant sur le port 53, le DHCP du routeur toujours actif en arrière-plan,
et un client VPN bien intentionné qui insère des règles de split DNS dans le mélange.

Ce que signifie « ne pas se battre avec votre système »

• Autorité unique pour le DHCP sur un segment L2 donné. Aucune exception. Pas « à peu près ».
• Propriété claire de la résolution stub sur les clients : soit systemd-resolved est le stub local, soit dnsmasq l’est.
• Un seul endroit pour définir les DNS en amont (ou au moins un par classe de clients), avec des remplacements prévisibles.
• Journalisation activable en cas de besoin, sans devenir un monument permanent dévorant le disque par curiosité.

dnsmasq peut jouer plusieurs rôles : il peut être un forwarder/cache DNS, un serveur DNS autoritaire pour des zones locales, un serveur DHCP,
un serveur TFTP pour PXE, et plus encore. Le mode d’échec survient lorsqu’il fait la moitié de chaque rôle pendant que quelque chose d’autre fait l’autre moitié.
C’est là que vous obtenez « ça marche sur le Wi‑Fi mais pas sur Ethernet » et « ça ne tombe en panne que le mardi ».

Faits intéressants et petite histoire qui importe réellement

• Le design de dnsmasq visait les petits réseaux : un seul démon, faible mémoire, dépendances minimales, comportement prévisible sous charge.
• Le port 53 est un champ de bataille depuis les années 1990 : les « resolveurs cache locaux » sont devenus populaires parce que la récursion amont était lente et fragile.
• Le vrai super-pouvoir du DHCP est de centraliser la politique — pas seulement les adresses, mais la passerelle par défaut, les serveurs DNS, NTP, et les options spécifiques au fournisseur.
• systemd-resolved a normalisé le modèle du « stub resolver » : les applications interrogent un écouteur local (127.0.0.53) qui relaie en amont avec de la politique.
• Le cache DNS peut masquer des pannes en amont temporairement, ce qui est bien jusqu’à ce que les TTL expirent et que votre système « stable » tombe d’un coup.
• La mise en cache négative (NXDOMAIN) existe : mettre en cache « ce nom n’existe pas » peut accélérer les échecs — et aussi les prolonger.
• Le split DNS est antérieur à la plupart des clients VPN : les entreprises font « les zones internes se résolvent en interne » depuis avant que les portables ne soient à la mode.
• La durée des baux DHCP est un levier : trop courte surcharge votre serveur ; trop longue retarde la récupération après de mauvaises attributions et modifications.
• Les domaines de recherche DNS sont une arme à double tranchant : une seule liste de recherche incorrecte peut transformer une requête en six et faire ressembler la latence à une perte de paquet.

Une idée paraphrasée qui devrait être épinglée à votre moniteur : la fiabilité vient de la compréhension des modes de défaillance des systèmes, pas du fait de prétendre qu’ils n’en auront pas — John Allspaw. Le DNS est un système qui échoue de façons créatives.

Choisir une architecture (et s’y tenir)

Architecture A : dnsmasq gère le cache DNS du LAN + DHCP ; les clients l’utilisent directement

C’est le plus propre pour les laboratoires domestiques et les petits bureaux : les clients obtiennent le DHCP de dnsmasq et utilisent dnsmasq comme serveur DNS.
dnsmasq relaie vers des résolveurs en amont (votre FAI, des résolveurs publics, ou un résolveur récursif interne).

Le gain opérationnel : une machine est la source de vérité pour « ce qui est sur mon LAN », et vous pouvez lui apprendre des noms locaux.
Le risque opérationnel : si vous le placez sur un portable, vous assumez les conséquences. Placez-le sur quelque chose d’ennuyeux.

Architecture B : systemd-resolved sur les clients ; dnsmasq seulement DHCP (ou seulement DNS)

Cela fonctionne quand vous êtes dans une flotte d’entreprise où systemd-resolved est standard et où les clients VPN s’intègrent à lui.
Dans ce mode, dnsmasq peut servir le DHCP et distribuer des serveurs DNS, mais les clients utilisent toujours leur stub resolver local.

C’est viable, mais c’est aussi comme ça que vous vous retrouvez avec « le DNS est différent selon qui s’est connecté en dernier ». Vous pouvez le faire.
Il faut juste de la discipline.

Architecture C : dnsmasq comme cache local sur chaque machine

Habituellement pas rentable. Si vous le faites, vous créez essentiellement N petits caches avec N ensembles de règles en amont.
Le débogage devient une danse interprétative.

Opinion : Pour la plupart des petits réseaux, choisissez l’Architecture A. C’est plus simple, débogable, et vous pouvez la rendre très fiable avec presque aucun effort.

Blague #1 : Le DNS, c’est comme la politique de bureau — tout le monde jure que « ce n’est pas leur département », et pourtant il décide si quelque chose se fait.

La configuration dnsmasq propre (cache DNS + DHCP) pour un LAN

Hypothèses pour cette configuration :

• Serveur Linux exécutant dnsmasq
• Interface LAN : eth0
• Plage du LAN : 192.168.50.0/24
• IP de dnsmasq sur le LAN : 192.168.50.1
• Domaine local : lan
• DNS en amont : 1.1.1.1 et 9.9.9.9 (remplacez si nécessaire)

Principes de base intégrés à la configuration

• Se lier explicitement à l’interface/IP LAN afin de ne pas devenir accidentellement « DNS pour l’univers ».
• Ne pas lire l’état aléatoire du résolveur sauf si vous le voulez. Si vous dépendez de /etc/resolv.conf, vous héritez de son chaos.
• Être explicite sur votre domaine local et vos noms locaux.
• Journaliser seulement ce dont vous avez besoin, et savoir comment l’activer pendant un incident.

dnsmasq.conf (base propre)

cr0x@server:~$ sudo tee /etc/dnsmasq.d/lan.conf >/dev/null <<'EOF'
# ---- Identity & safety rails ----
domain-needed
bogus-priv
no-hosts
no-resolv

# Bind only where we intend to serve
interface=eth0
listen-address=192.168.50.1
bind-interfaces

# ---- Upstream DNS ----
server=1.1.1.1
server=9.9.9.9

# ---- Local DNS behavior ----
domain=lan
local=/lan/
expand-hosts
cache-size=10000
neg-ttl=60

# If you want local names from /etc/hosts, do it intentionally:
addn-hosts=/etc/dnsmasq.hosts

# ---- DHCPv4 ----
dhcp-authoritative
dhcp-range=192.168.50.50,192.168.50.199,255.255.255.0,12h
dhcp-option=option:router,192.168.50.1
dhcp-option=option:dns-server,192.168.50.1
dhcp-option=option:domain-name,lan
dhcp-option=option:ntp-server,192.168.50.1

# Example static lease: MAC,IP,hostname,lease-time
dhcp-host=AA:BB:CC:DD:EE:FF,192.168.50.10,nas,24h

# ---- Logging (keep default quiet; enable when diagnosing) ----
log-async=20
#log-queries
#log-dhcp
EOF

Quelques notes qui vous feront gagner du temps :

• no-resolv signifie « je ne fais pas confiance à /etc/resolv.conf ». Bon. Vous ne devriez pas non plus, sauf si vous le contrôlez.
• bind-interfaces plus listen-address évitent une exposition accidentelle sur des interfaces VPN ou des ponts docker.
• dhcp-authoritative est la façon d’empêcher les clients de s’accrocher à des baux obsolètes après une reconfiguration. Utilisez-le seulement si vous êtes vraiment l’autorité DHCP pour ce sous-réseau.
• cache-size=10000 est raisonnable sur le matériel moderne. De petits caches transforment le DNS en amplificateur de latence.

Enregistrements d’hôtes locaux (séparés intentionnellement)

cr0x@server:~$ sudo tee /etc/dnsmasq.hosts >/dev/null <<'EOF'
192.168.50.1   gw gw.lan
192.168.50.10  nas nas.lan
192.168.50.20  build build.lan
EOF

Garder les noms locaux de dnsmasq en dehors de /etc/hosts est un choix opérationnel : cela réduit les couplages accidentels avec le comportement du résolveur système.
Quand vous déboguez à 2 h du matin, vous voulez moins d’éléments en mouvement, pas plus.

Activer et redémarrer

cr0x@server:~$ sudo systemctl enable --now dnsmasq
...output...

Si vous voyez « failed », ne devinez pas. Passez à la section tâches et vérifiez la liaison de port, la syntaxe de la config et les services concurrents.

Cesser de se battre avec l’OS : systemd-resolved, NetworkManager, resolvconf

La racine de la plupart des conflits : le port 53 et /etc/resolv.conf

Sur de nombreuses distributions Linux modernes, systemd-resolved exécute un stub resolver sur 127.0.0.53:53.
C’est acceptable — jusqu’à ce que vous essayiez d’exécuter dnsmasq sur la même machine et de lier aussi le port 53 sur 0.0.0.0 ou sur localhost.

Le second conflit concerne /etc/resolv.conf. Il peut être :

• un fichier simple géré par vous,
• un lien symbolique vers le fichier stub de systemd-resolved,
• géré par resolvconf,
• réécrit par NetworkManager,
• ou tout cela à la fois, brièvement, pendant le démarrage.

Schéma recommandé pour un hôte serveur dnsmasq

Si ce serveur est votre boîte DNS/DHCP du LAN, l’approche la plus propre est :

• dnsmasq écoute sur l’IP LAN (par ex. 192.168.50.1) pour les clients
• le serveur lui-même peut utiliser soit :
  • dnsmasq (pointez son résolveur vers 127.0.0.1 ou 192.168.50.1), ou
  • systemd-resolved (et dnsmasq ne se lie jamais sur 127.0.0.1:53)

Ma préférence : laisser le serveur utiliser dnsmasq aussi, mais le faire délibérément. Si vous voulez systemd-resolved, gardez dnsmasq hors de localhost.
Choisissez-en un, documentez-le, et passez à autre chose.

Comment coexister avec systemd-resolved (sans drame)

Option 1 (courante) : dnsmasq sert le LAN sur 192.168.50.1 ; systemd-resolved reste le stub local. Aucun conflit si dnsmasq ne se lie pas sur 127.0.0.1.
C’est ce que réalise listen-address=192.168.50.1.

Option 2 (si vous voulez dnsmasq comme résolveur local) : désactivez systemd-resolved et gérez /etc/resolv.conf vous-même.
C’est acceptable sur un serveur dédié. C’est une mauvaise idée sur un portable avec des logiciels VPN qui s’attendent à systemd-resolved.

Piège NetworkManager

NetworkManager peut exécuter sa propre instance de dnsmasq pour le caching sur le client. Ce n’est pas la même chose que votre dnsmasq serveur,
mais cela peut compliquer le débogage parce que « dnsmasq tourne » peut désigner le mauvais processus.

Si votre serveur utilise NetworkManager, soyez explicite sur la gestion du DNS (soit laissez NM le gérer, soit ne le laissez pas).
Ne le laissez pas le gérer à moitié.

Blague #2 : Le moyen le plus simple de tester le DNS est de demander à trois personnes comment ça marche — puis de les voir toutes désaccordées avec confiance.

Tâches pratiques : commandes, sorties attendues et la décision que vous prenez

Ce sont de vraies tâches opérationnelles. Chacune inclut : une commande, ce que signifie la sortie, et la décision suivante.
Exécutez-les sur l’hôte dnsmasq sauf indication contraire.

Tâche 1 : Confirmer que dnsmasq tourne et n’est pas en train de redémarrer

cr0x@server:~$ systemctl status dnsmasq --no-pager
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
     Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2025-12-31 09:12:01 UTC; 2h 10min ago
   Main PID: 1324 (dnsmasq)
      Tasks: 1 (limit: 18956)
     Memory: 6.4M
     CGroup: /system.slice/dnsmasq.service
             └─1324 /usr/sbin/dnsmasq -k

Signification : « active (running) » avec un uptime stable signifie que le démon ne plante pas/ne redémarre pas.
Décision : Si l’uptime est de quelques secondes/minutes, allez directement à journalctl (Tâche 2) et au test de config (Tâche 3).

Tâche 2 : Lire les dernières erreurs de dnsmasq

cr0x@server:~$ sudo journalctl -u dnsmasq -n 80 --no-pager
Dec 31 09:11:59 server dnsmasq[1312]: failed to bind DHCP server socket: Address already in use
Dec 31 09:12:00 server systemd[1]: dnsmasq.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Dec 31 09:12:00 server systemd[1]: dnsmasq.service: Failed with result 'exit-code'.

Signification : Un autre serveur DHCP est déjà lié (souvent isc-dhcp-server ou votre routeur qui tourne encore sur ce segment).
Décision : Identifiez ce qui possède UDP/67 (Tâche 4) et tuez/désactivez le DHCP concurrent sur ce réseau. Ne « bricolez » pas autour.

Tâche 3 : Valider la syntaxe de la config dnsmasq avant le redémarrage

cr0x@server:~$ sudo dnsmasq --test
dnsmasq: syntax check OK.

Signification : La syntaxe est correcte ; les échecs à l’exécution sont probablement liés à la liaison des ports, aux permissions ou à l’environnement.
Décision : Si vous obtenez « bad option » ou une erreur de parsing, corrigez avant de redémarrer — ne faites pas de roulette russe en production.

Tâche 4 : Vérifier qui écoute sur les ports DNS et DHCP

cr0x@server:~$ sudo ss -ulpn | egrep ':(53|67)\s'
udp   UNCONN 0      0             192.168.50.1:53        0.0.0.0:*    users:(("dnsmasq",pid=1324,fd=6))
udp   UNCONN 0      0               0.0.0.0:67        0.0.0.0:*    users:(("dnsmasq",pid=1324,fd=4))

Signification : dnsmasq possède UDP/53 sur l’IP LAN et UDP/67 pour le DHCP.
Décision : Si vous voyez systemd-resolved sur 0.0.0.0:53 ou un autre processus sur :67, vous avez un conflit à résoudre avant toute chose.

Tâche 5 : Confirmer que /etc/resolv.conf est ce que vous pensez

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Dec 31 08:58 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Signification : Cet hôte utilise le stub resolver de systemd-resolved.
Décision : C’est acceptable si dnsmasq sert uniquement le LAN sur 192.168.50.1. Si vous voulez que l’hôte lui-même utilise dnsmasq, changez la stratégie de résolveur délibérément.

Tâche 6 : Vérifier la joignabilité des DNS en amont depuis le serveur

cr0x@server:~$ dig +time=1 +tries=1 @1.1.1.1 example.com A
; <<>> DiG 9.18.24 <<>> +time=1 +tries=1 @1.1.1.1 example.com A
;; ANSWER SECTION:
example.com.        86400   IN      A       93.184.216.34
;; Query time: 18 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)

Signification : L’amont est joignable et répond rapidement.
Décision : Si ceci expire, votre problème n’est pas dnsmasq — c’est le routage, le pare-feu ou une panne en amont. Corrigez cela d’abord.

Tâche 7 : Vérifier que dnsmasq répond localement (côté serveur)

cr0x@server:~$ dig +short @192.168.50.1 nas.lan
192.168.50.10

Signification : La résolution de noms locaux fonctionne.
Décision : Si les noms locaux échouent, vérifiez local=/lan/, domain=lan, et que votre fichier addn-hosts est lisible.

Tâche 8 : Vérifier que la mise en cache a lieu

cr0x@server:~$ sudo kill -USR1 $(pidof dnsmasq)
cr0x@server:~$ sudo journalctl -u dnsmasq -n 30 --no-pager
Dec 31 11:18:10 server dnsmasq[1324]: cache size 10000, 8121/10000 cache insertions re-used unexpired cache entries.

Signification : Les entrées du cache sont réutilisées ; dnsmasq accomplit son rôle de cache.
Décision : Si la réutilisation est proche de zéro, les clients peuvent contourner dnsmasq, ou les TTL sont trop bas, ou vous ne servez pas réellement les clients que vous croyez servir.

Tâche 9 : Surveiller les baux DHCP en direct

cr0x@server:~$ sudo tail -n 20 /var/lib/misc/dnsmasq.leases
1735643551 11:22:33:44:55:66 192.168.50.73 laptop *
1735644012 aa:bb:cc:dd:ee:ff 192.168.50.10 nas *

Signification : Des baux sont attribués. Les champs sont : epoch d’expiration, MAC, IP, hostname, client-id.
Décision : Si un client ne reçoit pas d’adresse et qu’il n’est pas ici, vous avez un problème de reachabilité DHCP (VLAN, pare-feu, DHCP concurrent).

Tâche 10 : Confirmer que le client a reçu le bon serveur DNS via DHCP

cr0x@server:~$ ipconfig getpacket en0
...output...

Signification : Sur macOS, cela montre l’offre/ack DHCP incluant les serveurs DNS. Sur Linux, utilisez la Tâche 11.
Décision : Si le serveur DNS n’est pas 192.168.50.1, vos options DHCP sont incorrectes ou un autre serveur DHCP gagne.

Tâche 11 : Sur un client Linux, vérifier quel DNS est utilisé

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (eth0)
    Current Scopes: DNS
         DNS Servers: 192.168.50.1
          DNS Domain: lan

Signification : systemd-resolved est actif, mais il utilise dnsmasq comme serveur en amont pour cette interface. C’est normal et sain.
Décision : Si cela montre seulement 127.0.0.53 sans amont, il vous manque les DNS fournis par DHCP ou la configuration de NM.

Tâche 12 : Vérifier qu’un client peut résoudre via dnsmasq et mesurer la latence

cr0x@server:~$ dig @192.168.50.1 example.com A +stats
...output...
;; Query time: 3 msec

Signification : Un temps de requête bas suggère un hit de cache ou un amont rapide. Si vous l’exécutez deux fois, la seconde devrait typiquement être plus rapide (cache hit).
Décision : Si le temps est de plusieurs centaines de ms ou des timeouts se produisent, vérifiez la santé de l’amont, la perte de paquets, le MTU/VPN, et si le DNS est intercepté.

Tâche 13 : Vérifier si vous fuyez des requêtes DNS sur la mauvaise interface

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 53 -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
10 packets captured

Signification : Vous voyez le trafic DNS sur l’interface LAN. Si vous n’en voyez aucun alors que les clients se plaignent, ils ne vous interrogent pas du tout.
Décision : Corrigez les options DHCP ou les paramètres du résolveur client. Ne modifiez pas dnsmasq pour un trafic qu’il ne voit jamais.

Tâche 14 : Trouver un serveur DHCP rogue sur le LAN

cr0x@server:~$ sudo nmap --script broadcast-dhcp-discover -e eth0
Starting Nmap 7.94 ( https://nmap.org ) at 2025-12-31 11:41 UTC
Pre-scan script results:
| broadcast-dhcp-discover:
|   Response 1 of 2:
|     IP Offered: 192.168.50.120
|     DHCP Server Identifier: 192.168.50.1
|   Response 2 of 2:
|     IP Offered: 192.168.50.210
|     DHCP Server Identifier: 192.168.50.254

Signification : Deux serveurs DHCP ont répondu. C’est votre histoire de panne avant d’être un incident de panne.
Décision : Désactivez le DHCP sur le routeur (192.168.50.254) ou déplacez dnsmasq vers un autre VLAN/sous-réseau. Ne faites pas fonctionner deux DHCP en duel.

Tâche 15 : Confirmer que le pare-feu autorise DHCP et DNS

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0;
    policy drop;
    iif "lo" accept
    ct state established,related accept
    iif "eth0" udp dport { 53, 67 } accept
    iif "eth0" tcp dport 53 accept
  }
}

Signification : DNS et DHCP sont autorisés sur l’interface LAN.
Décision : Si UDP/67 est bloqué, le DHCP ne fonctionnera pas. Si UDP/53 est bloqué, la plupart des DNS ne fonctionneront pas. Corrigez les règles avant de toucher dnsmasq.

Tâche 16 : Tester le chemin de requête DHCP depuis un client (Linux)

cr0x@server:~$ sudo dhclient -v -r eth0
...output...
cr0x@server:~$ sudo dhclient -v eth0
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPOFFER of 192.168.50.73 from 192.168.50.1
DHCPREQUEST for 192.168.50.73 on eth0 to 255.255.255.255 port 67
DHCPACK of 192.168.50.73 from 192.168.50.1
bound to 192.168.50.73 -- renewal in 19958 seconds.

Signification : Le client reçoit des offres/acks de votre serveur dnsmasq.
Décision : Si vous voyez des offres d’un autre serveur, vous avez un DHCP concurrent. Si vous ne voyez aucune offre, c’est L2/VLAN/pare-feu.

Playbook de diagnostic rapide

Quand DNS/DHCP est en panne, vous ne voulez pas d’un débat philosophique. Vous voulez une boucle serrée : vérifier l’autorité, vérifier la joignabilité, vérifier le chemin client.
Voici l’ordre qui trouve le goulot d’étranglement le plus rapidement.

Première étape : établir qui est aux commandes

1. Exécutez la Tâche 14 (broadcast DHCP discover). S’il y a deux serveurs DHCP, arrêtez-vous. Réglez ça en premier.
2. Sur l’hôte dnsmasq, exécutez la Tâche 4 (qui possède les ports 53 et 67). Si dnsmasq n’est pas lié comme prévu, arrêtez-vous. Corrigez les conflits de liaison.
3. Sur un client, exécutez la Tâche 11 (resolvectl status ou équivalent) pour voir quel serveur DNS il utilise réellement.

Deuxième étape : vérifier que le serveur est sain

1. Tâche 1 + Tâche 2 : état du service et logs. S’il oscille, ne touchez pas encore aux clients.
2. Tâche 3 : vérification syntaxe. Cela attrape les « j’ai changé une ligne à minuit ».
3. Tâche 6 : joignabilité DNS en amont. Si l’amont est down, la mise en cache peut le masquer brièvement ; ne vous laissez pas tromper.

Troisième étape : vérifier le chemin des paquets

1. Tâche 13 : tcpdump sur l’interface LAN pour le trafic DNS. Aucun paquet signifie que les clients ne vous interrogent pas.
2. Tâche 16 : handshake DHCP depuis un client. Si pas de DHCPOFFER, c’est L2/VLAN/pare-feu.
3. Tâche 15 : vérifier la bonne santé du jeu de règles du pare-feu.

Quatrième étape : isoler « lent » de « cassé »

1. Tâche 12 : dig +stats deux fois. Le premier appel teste l’amont ; le second teste le cache.
2. Tâche 8 : stats du cache via USR1. Confirme que le cache est utilisé.

Ce playbook est volontairement ennuyeux. C’est le but : il évite de perdre du temps au mauvais niveau.

Erreurs courantes : symptôme → cause racine → correctif

1) « Le DHCP fonctionne, mais DNS tombe en panne aléatoirement »

Symptôme : Les clients obtiennent une IP, mais la résolution de noms est intermittente ou lente.

Cause racine : Les clients n’utilisent pas dnsmasq pour le DNS (option DHCP erronée) ou utilisent un résolveur amont défaillant via une politique VPN.

Correction : Vérifiez que le DHCP a distribué option:dns-server,192.168.50.1 (Tâche 10/11). Puis vérifiez que le trafic atteint dnsmasq (Tâche 13). Si un split DNS VPN intervient, décidez si le VPN doit écraser le DNS LAN et configurez le split forwarding explicitement.

2) « dnsmasq ne démarre pas : address already in use »

Symptôme : systemd indique que dnsmasq a échoué ; les logs mentionnent des erreurs de bind.

Cause racine : systemd-resolved (ou un autre serveur DNS) occupe le port 53, ou un autre serveur DHCP occupe le port 67.

Correction : Utilisez la Tâche 4 pour identifier le processus. Si vous n’avez besoin que de dnsmasq sur l’IP LAN, définissez listen-address=192.168.50.1 et évitez localhost. Si vous avez besoin de localhost aussi, désactivez le service concurrent de manière intentionnelle.

3) « Les clients obtiennent la mauvaise passerelle par défaut »

Symptôme : Certains clients résolvent des noms mais ne peuvent pas atteindre Internet ou d’autres VLANs.

Cause racine : dhcp-option=option:router incorrecte, ou un serveur DHCP concurrent distribue une option de route différente.

Correction : Exécutez la Tâche 14 pour localiser le DHCP rogue. Puis corrigez option:router. Confirmez sur le client en inspectant son paquet DHCP (Tâche 10/16).

4) « Les noms locaux ne se résolvent pas, mais les noms externes oui »

Symptôme : example.com se résout correctement ; nas.lan non.

Cause racine : local=/lan/ manquant ou domain=lan incorrect ; le fichier hosts local n’est pas lu ; ou le domaine de recherche client n’est pas défini.

Correction : Validez les réponses locales de dnsmasq (Tâche 7). Assurez-vous que le DHCP distribue option:domain-name,lan. Si vous ne voulez pas de domaines de recherche, apprenez aux utilisateurs à utiliser des FQDN comme nas.lan et passez à autre chose.

5) « Après un changement, rien ne se met à jour pendant des heures »

Symptôme : Vous avez changé un enregistrement ou l’amont, mais les clients obtiennent toujours d’anciennes réponses.

Cause racine : TTLs et mise en cache (cache dnsmasq, caches clients, caches de navigateur), plus des durées de bail DHCP longues pour les changements de serveur DNS.

Correction : Réduisez les TTL pour les enregistrements que vous comptez déplacer. En urgence, redémarrez dnsmasq (efface le cache) et renouvelez les baux DHCP côté client. Ne faites pas des baux de 5 minutes en permanence pour « corriger » la gestion des changements.

6) « Le DNS a l’air correct depuis le serveur, cassé depuis les clients »

Symptôme : dig @192.168.50.1 fonctionne sur le serveur, mais les clients ont des timeouts.

Cause racine : Pare-feu bloquant UDP/53, mauvaise liaison d’interface, isolation VLAN, ou le client ne pointe pas vers le serveur.

Correction : Tâche 15 (pare-feu), Tâche 4 (liaison), Tâche 13 (tcpdump), puis vérifiez les options DHCP sur le client.

7) « Le DNS casse seulement quand le VPN est connecté »

Symptôme : Les noms internes de l’entreprise se résolvent, mais les noms LAN cessent (ou l’inverse).

Cause racine : Les politiques de split DNS écrasent, ou le client VPN modifie l’ordre des résolveurs/domaine de recherche.

Correction : Décidez de la politique : le VPN doit-il tout écraser, ou seulement certains domaines ? Implémentez le split forwarding dans dnsmasq en utilisant des directives domaine-spécifiques server=/corp.example/10.0.0.53, ou laissez systemd-resolved le gérer et gardez dnsmasq purement pour les clients LAN.

Trois mini-récits d’entreprise issus du terrain

Incident causé par une mauvaise hypothèse : « Le routeur n’est qu’un routeur »

Un bureau de taille moyenne a emménagé dans un nouvel espace. L’entrepreneur réseau a laissé un appareil routeur/firewall brillant.
L’équipe interne a démarré une petite VM Linux pour exécuter dnsmasq parce qu’ils voulaient des noms d’hôtes cohérents pour des kits de développement et des imprimantes.
Ils ont supposé que l’appliance était « juste du routage » et que l’ancien service DHCP avait été désactivé lors de la bascule.

Tout fonctionnait le matin. L’après-midi, les écrans de la salle de conférence ont commencé à disparaître du réseau.
Certains portables ont obtenu le serveur DNS attendu. D’autres ont reçu les paramètres DNS par défaut de l’appliance.
Les gens ont blâmé le Wi‑Fi. Les gens blâment toujours le Wi‑Fi.

L’indice était ennuyeux : deux passerelles par défaut différentes apparaissaient dans les configs clients, selon qui avait renouvelé un bail en dernier.
L’appliance tournait encore en DHCP sur le même VLAN, distribuant sa propre passerelle et ses propres options DNS.

La correction n’était pas brillante. Ils ont lancé un broadcast DHCP discover, confirmé deux réponses, et désactivé le DHCP sur l’appliance.
Puis ils ont forcé un renouvellement de bail sur les appareils problématiques. L’« aléatoire » a disparu instantanément.

La leçon : ne supposez jamais que l’appliance de bord n’exécute pas de DHCP. Vérifiez-le. Les appliances aiment les fonctionnalités comme les tout-petits aiment les marqueurs.

Optimisation qui s’est retournée contre eux : « Réduisons les requêtes upstream à presque zéro »

Dans une autre organisation, une équipe a modifié agressivement le cache de dnsmasq et ajouté des listes de domaines de recherche pour « améliorer l’utilisabilité ».
Leur idée était simple : gros cache, comportements TTL longs, et un domaine de recherche pour que les gens tapent des noms courts.
Ils ont aussi activé la journalisation des requêtes en permanence parce que « c’est utile ». Ça l’était.

Deux semaines plus tard, des incidents ont commencé : connexions lentes à des applications SaaS, échecs intermittents de résolution de certains domaines,
et périodiquement des temps d’attente IO élevés sur la VM. Le CPU allait bien. La carte réseau allait bien. Le disque était triste.

La journalisation permanente des requêtes a produit un fort taux de churn dans journald et le stockage sous-jacent.
La liste de domaines de recherche a multiplié les requêtes : fautes de frappe et noms courts se sont étendus en plusieurs requêtes échouées par tentative.
La mise en cache négative a fini le travail — des réponses NXDOMAIN temporaires sont restées plus longtemps que l’équipe ne l’avait prévu.

Ils se sont « optimisés » vers un goulot : le système passait du temps à écrire des logs sur des requêtes qui n’auraient pas dû exister.
Le serveur DNS était exact. Il était juste occupé à raconter sa propre vie.

La correction : désactiver la log-queries permanente, la garder comme levier pour les incidents, et réduire les domaines de recherche.
Ils ont conservé une taille de cache raisonnable, mais ont arrêté d’essayer de rendre le DNS invisible par de la « cleverness ».

Pratique ennuyeuse mais correcte qui a sauvé la mise : « Binder explicitement, documenter la propriété »

Une entreprise financière gérait une petite flotte de serveurs de succursales. Chaque succursale avait un dnsmasq local fournissant DHCP et cache DNS
parce que les liens WAN étaient peu fiables et que des applications sensibles à la latence étaient partout.
La norme de configuration était terne : dnsmasq lié uniquement à l’interface LAN, résolveurs en amont explicites,
et DHCP autoritaire sur exactement un VLAN par succursale.

Un jour, un déploiement d’urgence de VPN a ajouté une nouvelle interface tunnel à chaque serveur. Soudain, beaucoup de services ont commencé à se lier
à des interfaces supplémentaires. C’est comme ça que « interne seulement » devient « accessible depuis des endroits que vous n’imaginiez pas ».

dnsmasq s’en est moqué. Il était déjà épinglé à l’IP LAN avec listen-address et bind-interfaces.
Il n’a pas commencé à répondre au DNS sur l’interface VPN, et il n’a pas divulgué de noms locaux dans le mauvais endroit.

D’autres services ont mal fonctionné et ont dû être corrigés rapidement. DNS et DHCP ont continué à fonctionner, discrètement, en arrière-plan.
Les succursales ont remarqué les changements VPN ; elles n’ont pas remarqué que leurs services réseaux centraux restaient stables.
C’est un compliment que l’on ne reçoit pas dans un système de tickets.

La leçon : la pratique ennuyeuse — binds explicites, upstreams explicites, propriété explicite — rapporte exactement quand votre environnement change sous vous.

Listes de vérification / plan pas à pas

Plan A : Déployer dnsmasq comme cache DNS LAN + serveur DHCP (recommandé)

1. Choisir la frontière d’autorité.
   Décidez quels sous-réseaux dnsmasq servira pour le DHCP. Désactivez le DHCP ailleurs sur ce segment.
2. Choisir la portée d’écoute.
   Choisissez l’IP et l’interface LAN. Utilisez listen-address et bind-interfaces.
3. Écrire une configuration minimale.
   Commencez avec la configuration de base présentée dans cet article. Évitez la prolifération de fonctionnalités.
4. Tester la syntaxe.
   Exécutez dnsmasq --test avant de redémarrer.
5. Démarrer le service et vérifier les ports.
   Utilisez ss -ulpn pour confirmer que dnsmasq possède UDP/53 et UDP/67 comme prévu.
6. Vérifier les offres DHCP.
   Utilisez un client avec dhclient -v ou lancez un scan broadcast DHCP discover.
7. Vérifier les réponses DNS.
   Testez les noms locaux (par ex. nas.lan) et les noms externes.
8. Activer la journalisation seulement quand nécessaire.
   Gardez log-queries commenté par défaut ; activez-le pendant les incidents, puis désactivez-le.
9. Documentez comme si vous alliez oublier.
   Une page : quels sous-réseaux sont servis, où la config vit, qui possède les DNS en amont, et comment détecter un DHCP rogue.

Plan B : Migrer du « DHCP du routeur » vers dnsmasq sans surprise

1. Réduisez temporairement le temps de bail DHCP du routeur (par ex. quelques heures) un jour avant la migration.
2. Montez dnsmasq en mode « DNS only » d’abord (n’activez pas encore le DHCP). Validez le comportement DNS.
3. Planifiez une courte fenêtre de bascule.
4. Désactivez le DHCP sur le routeur.
5. Activez le DHCP dnsmasq avec dhcp-authoritative et les options correctes.
6. Sur quelques clients test, renouvelez les baux et vérifiez DNS/passerelle.
7. Surveillez le fichier de baux et les logs pendant la première heure. Attendez-vous à ce que certains clients collent à des baux obsolètes ; forcez le renouvellement si nécessaire.
8. Rétablissez des temps de bail raisonnables (par ex. 12h ou 24h) après stabilisation.

Plan C : Rendre ça résilient (sans en faire un projet)

• Placez dnsmasq sur un hôte stable (petite VM, NUC, ou serveur basse consommation) avec une alimentation onduleur si cela vous importe.
• Conservez la configuration dans un repo. Même un dépôt git privé sur la machine vaut mieux que « je crois que je l’ai changé le mois dernier ».
• Sauvegardez /etc/dnsmasq.d et les fichiers de baux si les mappings statiques comptent.
• Surveillez : état du service, latence des requêtes (dig synthétique), et perte de paquets sur le LAN.

FAQ

1) Dois-je désactiver systemd-resolved sur les clients ?

Généralement non. Dans des flottes gérées et sur des portables avec clients VPN, systemd-resolved est souvent le point d’intégration.
Laissez-le tourner, et assurez-vous simplement qu’il utilise votre dnsmasq comme serveur en amont pour le lien LAN.

2) Dois-je désactiver systemd-resolved sur le serveur dnsmasq ?

Si dnsmasq est dédié et que vous voulez qu’il soit aussi le résolveur de la machine elle-même, désactiver systemd-resolved peut simplifier les choses.
Mais ce n’est pas obligatoire — assurez-vous simplement que dnsmasq ne se lie pas sur localhost si systemd-resolved le possède.

3) Pourquoi utiliser no-resolv et des entrées server= explicites ?

Parce que /etc/resolv.conf est fréquemment géré par d’autres composants et peut changer pendant le démarrage, la connexion VPN ou un changement de lien.
Des upstream explicites rendent le comportement prévisible et le débogage plus rapide.

4) Quelle taille de cache devrais-je utiliser ?

Pour les petits réseaux, 5 000–20 000 est généralement suffisant. Si vous êtes contraint en RAM, une taille plus petite fonctionne aussi — n’attendez juste pas des miracles.
Mesurez avec les stats USR1 et la latence des requêtes avant et après.

5) dnsmasq peut-il faire du split DNS ?

Oui. Vous pouvez rediriger des domaines spécifiques vers des résolveurs en amont spécifiques avec server=/corp.example/10.0.0.53.
Restez explicite et documentez-le, car le futur vous n’oubliera pas pourquoi un seul domaine se comporte différemment.

6) Comment savoir si les clients contournent dnsmasq ?

Lancez tcpdump sur l’interface serveur pour UDP/53 (Tâche 13). Si les clients se plaignent et que vous ne voyez aucun trafic, ils ne vous interrogent pas.
Ensuite vérifiez les paramètres DNS du client (Tâche 11) et les options DHCP.

7) Est-il sûr d’exécuter dnsmasq sur un hôte qui exécute aussi Docker ou Kubernetes ?

C’est possible, mais vous devez lier dnsmasq à l’interface/IP prévue. Les piles de conteneurs créent des interfaces supplémentaires,
et « écouter partout » devient « répondre au DNS là où vous ne devriez pas ». Utilisez listen-address et bind-interfaces.

8) Qu’en est-il d’IPv6 (SLAAC, RA, DHCPv6) ?

dnsmasq peut aider avec IPv6, mais IPv6 introduit plus de pièces mobiles (annonces de routeur, DHCPv6, DNS via RDNSS).
Si vous commencez, stabilisez IPv4 d’abord. Ensuite ajoutez IPv6 délibérément et testez avec des captures de paquets.

9) Dois-je activer la validation DNSSEC dans dnsmasq ?

Seulement si vous comprenez les modes d’échec et avez le temps de les déboguer. DNSSEC peut améliorer l’intégrité,
mais les mauvaises configurations et des amonts cassés peuvent créer des incidents « tout est down » qui ressemblent à des pannes réseau.

10) Puis-je exécuter deux serveurs dnsmasq pour la redondance ?

Pour le cache/forwarding DNS, oui — les clients peuvent avoir plusieurs serveurs DNS. Pour le DHCP, la redondance est plus délicate.
Vous pouvez scinder les plages ou utiliser des mécanismes de basculement DHCP avec d’autres logiciels, mais dnsmasq seul n’est pas une solution HA DHCP d’entreprise complète.
Pour les petits réseaux, une seconde machine de secours froide et de bonnes sauvegardes sont souvent la réponse pragmatique.

Étapes suivantes que vous pouvez faire aujourd’hui

Si vous voulez que dnsmasq se comporte, cessez de le laisser négocier l’autorité avec ce qui est installé autour.
Choisissez l’architecture, liez-vous à la bonne interface, rendez explicites les DNS en amont, et assurez-vous qu’un seul service possède le DHCP.
Voilà 80 % de l’histoire de la fiabilité.

1. Exécutez la vérification de DHCP rogue (Tâche 14) sur votre LAN et éliminez tout double-serveur.
2. Implémentez la configuration de base et validez les ports (Tâche 4) et la syntaxe (Tâche 3).
3. Vérifiez le chemin client : handshake DHCP (Tâche 16) et serveur DNS actif (Tâche 11).
4. Gardez la journalisation comme outil à la demande, pas comme style de vie.
5. Notez la propriété : quelle machine fait DHCP, quelle machine fait DNS, et à quoi ressemble le « normal ».

Vous n’avez pas besoin d’une pile sophistiquée pour avoir des noms et des adresses fiables. Vous avez besoin d’une machine ennuyeuse qui fait son travail, et d’un système qui ne la combat pas.