Installer et configurer systemd-resolved sur Debian

Debian 13

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.

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-resolved

Configurer 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.d

Ensuite nous allons créer le fichier de configuration avec la configuration minimum :

nano /etc/systemd/resolved.conf.d/dns-config.conf

Voici un exemple de configuration de base :

[Resolve]
DNS=192.168.1.1,192.168.1.2
FallbackDNS=1.1.1.1

DNS=192.168.1.1,192.168.1.2 : Ce sont les serveurs DNS principaux que systemd-resolved utilisera 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 -y

Une 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-caches

Configuration 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.conf

Ensuite redémarrer le service Docker :

systemctl restart docker

Si 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=yes

Pour 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=yes

On 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.network

Exemple 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=yes

Conclusion

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.53 mais 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

Romain Drouche
Romain Drouche
Architecte Système | MCSE: Core Infrastructure
Expert en infrastructures IT avec plus de 15 ans d’expérience sur le terrain. Actuellement Chef de projet Systèmes et Réseaux et Référent SSI (Sécurité des Systèmes d’Information), je mets mon expertise au service de la fiabilité et de la sécurité des environnements technologiques.

Laisser un commentaire