systemd-resolved est un service de résolution de noms qui fait partie de l'écosystème systemd. En pratique, /etc/resolv.conf devient donc un simple lien symbolique géré par systemd-resolved, généralement pointé vers /run/systemd/resolve/stub-resolv.conf. On va avoir des informations intéressantes dans cette sortie … La gestion des résolutions DNS est déléguée à ce gestionnaire réseau externe (NetworkManager, systemd-networkd, netplan, etc.).
Fondements et fonctionnement général
DNS (Domain Name System) est un système qui traduit les noms de domaine en adresses IP. En résumé, la fonction du service de résolution DNS est de convertir les noms de domaine en adresses IP. Le processus de résolution DNS implique les rôles suivants : Le nom de domaine à résoudre, Le client DNS, Le serveur DNS, L'adresse IP correspondant au nom de domaine. Le résolveur peut être configuré en éditant /etc/systemd/resolved.conf et/ou les fichiers de configuration .conf de substitution dans /etc/systemd/resolved.conf.d/. Pour fournir la résolution de nom de domaine pour les logiciels qui lisent /etc/resolv.conf directement, comme les navigateurs et GnuPG, systemd-resolved a quatre différents modes pour manipuler le fichier-stub, static, uplink et foreign. Ils sont décrits dans systemd-resolved(8) § /ETC/RESOLV.CONF.
Nous allons, ici, nous concentrer sur le mode recommandé, c'est-à-dire /run/systemd/resolve/stub-resolv.conf qui contient une référence au programme local 127.0.0.53 comme étant le seul serveur DNS et une liste de domaines de recherche. C'est le mode opératoire recommandé pour propager la configuration de systemd-resolved vers tous les clients.
Structure et configuration
systemd-resolved est un service systemd qui fournit la résolution de nom de réseau aux applications locales via une interface D-Bus, le service NSS resolve (nss-resolve(8)), et une interface locale 127.0.0.53. Le résolveur peut être configuré en éditant /etc/systemd/resolved.conf et/ou les fichiers de configuration .conf de substitution dans /etc/systemd/resolved.conf.d/. Pour les navigateurs ou outils qui lisent directement /etc/resolv.conf, le fichier est souvent lié dynamiquement comme un résolveur de stub.
Le fichier /etc/resolv.conf est généralement un lien symbolique pointant vers /run/systemd/resolve/stub-resolv.conf et /run/systemd/resolve/resolv.conf est lié symboliquement à ce dernier. Le fichier pointe vers /run/systemd/resolve/stub-resolv.conf, qui sera expliqué plus tard. Aucune configuration particulière n'est requise puisque systemd-resolved sera détecté en suivant le lien symbolique /etc/resolv.conf.
Modes et gestion du fichier resolv.conf
Pour fournir la résolution de nom de domaine pour les logiciels lisant /etc/resolv.conf, systemd-resolved propose quatre modes: stub, static, uplink et foreign. Ils permettent de manipuler le fichier afin que les clients locaux accèdent au résolveur local tout en conservant une configuration adaptée. Le mode recommandé est le stub, qui utilise le serveur local 127.0.0.53 et une liste de domaines de recherche. Créer le lien symbolique /etc/resolv.conf ne sera pas possible tant que vous êtes en arch-chroot, puisque le fichier est lié avec un fichier à l'extérieur de votre système. Au lieu de faire cela, il vous faut créer le lien symbolique depuis l'extérieur du chroot. E.g. systemd-resolved fonctionnera tel quel avec un network manager utilisant /etc/resolv.conf.
Interopérabilité et compatibilité
Aucune configuration particulière n'est requise puisque systemd-resolved sera détecté en suivant le lien symbolique /etc/resolv.conf. systemd-resolved peut ne pas chercher le domaine local lorsque l'on lui donne juste le nom de l'hôte, même si UseDomains=yes ou Domains=[domain-list] est présent dans le fichier de configuration du réseau, et que ce fichier produit la bonne search [domain-list] dans resolv.conf. Les adresses peuvent être changées en définissant FallbackDNS dans resolved.conf(5). Affectez DNSSEC=true pour toujours valider DNSSEC, ce qui va casser la résolution DNS avec les serveurs de noms de domaines qui ne prennent pas en charge la fonctionnalité. DNS via TLS est désactivé par défaut et peut être activé en modifiant DNSOverTLS dans [Resolve].
Pour activer la validation du certificat du serveur DNS de votre fournisseur, incluez leur nom d'hôte dans l'option DNS avec le format ip_address#hostname. Le serveur DNS utilisé doit prendre en charge DNS via TLS. ngrep peut être utile pour tester si DNS via TLS fonctionne puisque DNS via TLS utilise toujours les ports 853 et jamais le port 53.
Gestion et outils associés
systemd-resolved peut être utilisé avec différents gestionnaires de réseau: NetworkManager, systemd-networkd, netplan, etc. Pour systemd-networkd, affectez l'option MulticastDNS dans la section [Network] et Multicast=yes dans [Link]. Pour NetworkManager, utilisez l'option mdns dans [connection] et lancez la commande nmcli connection modify interface_name connection.mdns {yes|no|resolve}. Le défaut pour toutes les connexions NetworkManager peut être configuré via /etc/NetworkManager/conf.d/ et en affectant connection.mdns=2 dans la section [connection]. Le comportement LLMNR dépend des paramètres globaux et des paramètres par connexion.
Pour Voir et gérer le cache de systemd-resolved, on peut utiliser resolvectl show-cache et resolvectl flush-caches pour afficher et vider le cache DNS. Résoudre des noms de domaine peut être testé avec des outils comme dig, qui révèle que le résolveur est 127.0.0.53, un résolveur local qui relaie vers les serveurs DNS configurés.
Intégration avec Docker et environnement conteneurisé
Par défaut, Docker s'appuie sur /etc/resolv.conf de l'hôte, ce qui pose problème quand 127.0.0.53 pointe vers le conteneur lui-même. Plusieurs solutions existent: si les conteneurs n'ont pas besoin de noms internes, Docker peut utiliser les DNS publics; sinon, il faut exposer les vrais DNS via /run/systemd/resolve/resolv.conf ou config --dns afin que les conteneurs puissent résoudre les noms internes.
Bonnes pratiques et répartition des rôles
En Debian et systèmes similaires, il est recommandé de séparer configuration globale et configuration par interface: [Resolve] pour DNS globaux, sécurité (LLMNR/mDNS off, DNSSEC), cache et fallback public; [Network] pour DNS internes par interface, split-DNS multi-domaines, DoH si disponible. DoH interne + fallback public permet de sécuriser le trafic DNS tout en conservant la résolution interne fonctionnelle.
LLMNR et DoH restent des fonctionnalités optionnelles et leur activation dépend des besoins et des environnements. Le mode stub reste la solution simplifiée et efficace pour la plupart des postes de travail et serveurs modernes, en particulier lorsqu'un gestionnaire réseau centralisé contrôle les paramètres DNS.
En résumé, la fonction du service de résolution DNS est de convertir les noms de domaine en adresses IP et d'apporter une résolution fiable et centralisée via une interface locale. Les clients locaux pointent vers le résolveur local et délèguent les requêtes vers les serveurs configurés, avec la possibilité d'activer DNSSEC, DNS via TLS et le split-DNS pour répondre à des besoins spécifiques de sécurité et de confidentialité.