
Par défaut, Debian utilise un résolveur DNS simple basé sur /etc/resolv.conf.
Pour des environnements plus modernes (DNS sécurisé, DNS-over-TLS, cache DNS, gestion multi-interface), systemd-resolved est une solution beaucoup plus complète.
Dans ce tutoriel, nous allons voir comment installer, activer et configurer systemd-resolved sur Debian.
Sommaire
Présentation de systemd-resolved
systemd-resolved est un service fourni par systemd qui permet de gérer la résolution DNS de manière centralisée.
Il apporte plusieurs fonctionnalités intéressantes :
- Cache DNS local
- Support du DNS-over-TLS
- Gestion DNS par interface réseau
- Support DNSSEC
- Résolution multicast (mDNS / LLMNR)
Le service expose généralement un résolveur local sur : 127.0.0.53.
Vérifier si systemd-resolved est installé
Avant de lancer dans l’installation et la configuration, vous pouvez vérifier si le service est présent à l’aide de la commande suivant ;
systemctl status systemd-resolvedConfigurer systemd-resolved avant son installation
Afin d’éviter tout problème de résolution DNS après l’installation de systemd-resolved, nous allons commencer par configurer le service avant son activation.
Sous Linux, il est généralement possible de modifier la configuration d’un service en utilisant un mécanisme de surcharge de configuration (override). Cette méthode permet d’ajouter ou modifier certains paramètres sans altérer le fichier de configuration principal, ce qui facilite la maintenance et évite que les modifications soient écrasées lors d’une mise à jour du paquet.
On commence par créer le dossier :
mkdir /etc/systemd/resolved.conf.dEnsuite nous allons créer le fichier de configuration avec la configuration minimum :
nano /etc/systemd/resolved.conf.d/dns-config.confVoici un exemple de configuration de base :
[Resolve]
DNS=192.168.1.1,192.168.1.2
FallbackDNS=1.1.1.1DNS=192.168.1.1,192.168.1.2 : Ce sont les serveurs DNS principaux que
systemd-resolvedutilisera pour résoudre les noms de domaine. La syntaxe permet d’en mettre plusieurs, séparés par des virgules.FallbackDNS=1.1.1.1 : Ce serveur DNS sera utilisé uniquement si les serveurs principaux ne répondent pas.
La configuration de base est terminée.
Installation systemd-resolved sur Debian
Pour installer systemd-resolved entrer la commande suivante :
apt install systemd-resolved -yUne fois l’installation terminée vérifier le service :
systemctl status systemd-resolved
Comment on peut le voir, le service est démarré et configurer pour démarrer automatique (
enabled)Pour activer le service au démarrage si ce n’est pas le cas, entrer la commande suivante :
systemctl enable systemd-resolved
On peut aussi tester le statut avec la commande suivante : resolvectl status, cela vous permet également de voir les protocoles de résolution et les serveurs DNS configurés.

Tester la résolution de DNS et afficher les statiques
Pour valider le fonctionnement, on va tester la résolution de nom à l’aide de la commande dig qui donne plus d’information qu’il simple ping.
dig rdr-it.com
Si vous regardez bien, on peut voir que le résolveur est 127.0.0.53. C’est un résolveur DNS local : ton système lui envoie les requêtes, et il les relaie vers les vrais serveurs DNS configurés, un peu comme un proxy.
Pour afficher les statistiques, on utilise la commande resolvectl statistics qui va nous permettre d’avoir des informations sur le nombre de requêtes DNS et l’utilisation du cache.

Voir et gérer le cache de systemd-resolved
Pour voir le cache DNS entrer la commande suivante :
resolvectl show-cache
Si vous avez besoin de vider le cache utiliser la commande :
resolvectl flush-cachesConfiguration pour utiliser systemd-resolved avec Docker
Comme on l’a vu plus haut, le résolveur du serveur écoute sur 127.0.0.53, une adresse locale propre à la machine (gérée par systemd-resolved).
Par défaut, Docker s’appuie sur le fichier /etc/resolv.conf de l’hôte. Le problème, c’est que cette adresse est une loopback : dans un conteneur, 127.0.0.53 pointe vers lui-même → impossible de résoudre les DNS.
Plusieurs solutions existent. Si tes conteneurs n’ont pas besoin de résoudre des noms internes, Docker bascule automatiquement sur les DNS publics de Google. Inconvénient : pas de cache DNS, donc un peu moins performant.
La solution recommandé va être de faire un lien symbolique de /etc/resolv.conf vers le fichier /run/systemd/resolve/resolv.conf qui est généré par systemd-resolved qui a la syntaxe du fichier /etc/resolv.conf avec les serveurs DNS que vous avez configuré.
Commencer par créer le lien symbolique :
ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.confEnsuite redémarrer le service Docker :
systemctl restart dockerSi vous êtes curieux, je vous laisse regarde le contenu du fichier :
cat /run/systemd/resolve/resolv.conf
Vous pouvez aussi configurer le deamon Docker pour utiliser des serveurs DNS déclarés en configuration dans le fichier /etc/docker/daemon.json.
{
"dns": ["192.168.1.1", "1.1.1.1"]
}Configuration avancée de systemd-resolved
Je vais maintenant passer à une configuration un peu plus avancée du résolveur, avec un focus sécurité et bonnes pratiques.
- Désactivation de la résolution multicast (LLMNR / mDNS), souvent inutile en environnement serveur et pouvant représenter un risque
- Mise en place d’un DNS sécurisé via DoH (DNS over HTTPS), pour chiffrer les requêtes DNS et éviter leur interception
Voici un exemple de configuration commenté :
[Resolve]
# Serveurs interne en DoH et 53
DNS=192.168.1.1 192.168.1.2
# Fallback vers DoH
FallbackDNS=1.1.1.1 1.0.0.1
# Désactiver LLMNR et mDNS
LLMNR=no
MulticastDNS=no
# Activer DNSSEC pour valider les zones DNS
DNSSEC=yes
# Forcer DNS over TLS (DoH si serveur compatible)
DNSOverTLS=yes
# Cache local active
Cache=yesPour finir, on va voir une configuration split-DNS où l’on va utiliser des serveurs DNS pour des domaines locaux et utiliser des serveurs DNS publics pour le reste.
Le fichier de configuration globale :
[Resolve]
# Fallback externe
FallbackDNS=1.1.1.1 1.0.0.1 8.8.8.8
# Securite
LLMNR=no
MulticastDNS=no
DNSSEC=yes
Cache=yesOn ne déclare plus les DNS interne dans le fichier de configuration global, on va le faire dans un fichier .network.
Commencer par créer un nouveau fichier :
nano /etc/systemd/network/10-interne.networkExemple de configuration :
[Match]
Name=eth1
[Network]
# DNS internes
DNS=192.168.1.1 192.168.1.2
# Domaine interne a resoudre
Domains=intra.local corp.local dev.local
DNSOverTLS=yesConclusion
En résumé, la bonne pratique pour Debian avec systemd-resolved est de séparer la configuration globale et la configuration par interface :
[Resolve]→ DNS globaux, sécurité (LLMNR/mDNS off, DNSSEC), cache et fallback public[Network]→ DNS internes par interface, split-DNS multi-domaines, DoH si disponible- Docker et conteneurs n’utilisent pas
127.0.0.53mais lisent/run/systemd/resolve/resolv.conf→ toutes tes règles DNS s’appliquent automatiquement - DoH interne + fallback public te permet de sécuriser le trafic DNS tout en gardant la résolution interne fonctionnelle
FAQ
Pourquoi Docker ne peut pas utiliser 127.0.0.53 ?
nc dans le conteneur 127.0.0.53 pointe vers lui-même. Il faut exposer les vrais DNS via /run/systemd/resolve/resolv.conf ou config --dns.
Peut-on faire du split-DNS avec plusieurs domaines sur le même serveur ?
Oui. Dans [Network], il suffit de lister tous les domaines dans Domains=. Pas besoin de fichier par domaine.
DoH et DNS interne, c’est compatible
Oui, tant que tes serveurs internes supportent DoH/DoT. systemd-resolved peut chiffrer les requêtes internes et tomber sur DNS classique si le DoH échoue.
Faut-il désactiver LLMNR/mDNS ?
Oui, surtout sur serveur. Ce sont des protocoles multicast qui peuvent exposer des noms internes à des attaquants.
Comment combiner DNS interne + fallback public ?
DNS internes → [Network] (split-DNS par interface)
Fallback public → [Resolve] global (FallbackDNS)
systemd-resolved choisit automatiquement le meilleur serveur selon la requête
