systemd-resolved (Français)

État de la traduction:
Cet article est la version francophone de
systemd-resolved
. Date de la dernière traduction: 2022-12-22. Vous pouvez aider à synchroniser la traduction s'il y a eu des
changements
dans la version anglaise.
Related articles
systemd-networkd (Français)
Domain name resolution (Français)
Avahi (Français)
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
. Consultez
systemd-resolved(8)
pour son utilisation.
Installation
systemd-resolved
fait parti du paquet
systemd
qui est installé par défaut.
Configuration
systemd-resolved
fournit un service de résolution pour le
Domain Name System (DNS)
(ce qui inclut
DNSSEC
et
DNS over TLS
),
Multicast DNS (mDNS)
et
Link-Local Multicast Name Resolution (LLMNR)
.
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/
. Voir
resolved.conf(5)
.
Pour utiliser
systemd-resolved
démarrez
et
activez
systemd-resolved.service
.
Tip
Pour mieux comprendre le fonctionnement de
systemd-resolved
on peut activer les informations de debug comme indiqué dans
Systemd (Français)#Diagnostic d'un service
.
DNS
Les logiciels qui se basent sur
getaddrinfo(3)
de glibc (ou équivalent) fonctionneront tel quel, puisque, par défaut,
/etc/nsswitch.conf
est configuré pour utiliser
nss-resolve(8)
quand il est disponible.
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 mode pour manipuler le fichier—stub, static, uplink et foreign. Ils sont décrit dans
systemd-resolved(8) § /ETC/RESOLV.CONF
. Nous allons, ici, nous concentrer sur le mode recommandé, i.e. le mode "stub" qui utilise
/run/systemd/resolve/stub-resolv.conf
.
/run/systemd/resolve/stub-resolv.conf
contient une référence au programme local
127.0.0.53
comme étant le seul serveur DNS et une liste de domaine de recherche. C'est le mode opératoire recommandé pour propager la configuration de
systemd-resolved
vers tous les clients. Pour l'utiliser, il suffit de remplacer
/etc/resolv.conf
avec un lien symbolique vers le fichier dont nous parlons:
# ln -rsf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
Note
Ne pas configurer correctement
/etc/resolv.conf
mènera à des erreurs de résolution DNS.
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.
# ln -sf /run/systemd/resolve/stub-resolv.conf
/mnt
/etc/resolv.conf
Affecter les serveurs DNS
Tip
Pour vérifier la configuration actuellement utilisée par
systemd-resolved
, lancez
resolvectl status
.
Automatiquement
systemd-resolved
fonctionnera tel quel avec un
network manager
utilisant
/etc/resolv.conf
. Aucune configuration particulière n'est requise puisque
systemd-resolved
sera détecté en suivant le lien symbolique
/etc/resolv.conf
. Ce sera le cas avec
systemd-networkd
,
NetworkManager
, et
iwd
.
Cependant, si le client
DHCP
et
VPN
utilise le programme
resolvconf
pour affecter les serveurs et les domaine de recherche (Voir
openresolv#Users
pour une liste de programme qui utilsent
resolvconf
), alors le paquet additionnel
systemd-resolvconf
est requis pour fournir le lien symbolique
/usr/bin/resolvconf
.
Note
systemd-resolved
a une interface limitée avec
resolvconf
et peut ne pas fonctionner avec tout les clients, voir
resolvectl(1) § COMPATIBILITY WITH RESOLVCONF(8)
pour plus d'informations.
systemd-resolvconf
fonctionne seuleument quand
systemd-resolved.service
est démarré. Si vous n'utilisez pas
systemd-resolved
, alors assurez vous que le paquet
systemd-resolvconf
est
désinstallé
, autrement il va causer des problèmes avec les logiciels de réseau qui attendent un binaire
/usr/bin/resolvconf
fonctionnel.
Manuellement
Dans le mode stub et static, des serveurs DNS particuliers peuvent être placé dans le fichier de configuration
resolved.conf(5)
:
/etc/systemd/resolved.conf.d/dns_servers.conf
[Resolve]
DNS=192.168.35.1 fd7b:d0bd:7a6e::1
Domains=~.
Note
Sans l'option
Domains=~.
dans
resolved.conf(5)
,
systemd-resolved
pourrait utiliser le serveur DNS par lien, si n'importe lequel affecte le
Domains=~.
dans la configuration d'un lien.
Cette option n'affectera pas les requêtes de nom de domaine qui correspondent au nom de domaine spécifique spécifié dans la configuration d'un lien. Elles seront toujours résolu en utilisant le serveur DNS respectif au lien.
Pour d'avantage d'informations sur la configuration des liens consultez
Systemd-networkd (Français)#Fichiers network
.
Serveurs de secours
Si
systemd-resolved
ne reçoit pas d'addresses de serveurs DNS depuis le
network manager
et qu'aucune addresse de serveurs n'est configurée
manuellement
alors
systemd-resolved
se repli sur les adresses DNS de secours pour s'assurer que la résolution DNS fonctionne toujours.
Note
Les serveurs DNS de secours sont dans cet ordre: Cloudflare, Quad9 et Google; consultez le
PKGBUILD de systemd
où les serveurs sont définis.
Les adresses peuvent être changées en définissant
FallbackDNS
dans
resolved.conf(5)
. E.g.:
/etc/systemd/resolved.conf.d/fallback_dns.conf
[Resolve]
FallbackDNS=127.0.0.1 ::1
Pour supprimer la fonctionnalité de serveurs de secours, activez l'option
FallbackDNS
en ne spécifiant aucune adresse:
/etc/systemd/resolved.conf.d/fallback_dns.conf
[Resolve]
FallbackDNS=
DNSSEC
La validation
DNSSEC
peut être activée en changeant l'option
DNSSEC
dans
resolved.conf(5)
.
Affectez
DNSSEC=allow-downgrade
pour valider DNSSEC seuleument quand le serveur en amont prend en charge la fonctionnalité.
Affectez
DNSSEC=true
pour toujours valider DNSSEC, ce qui va casser la résolution DNS avec les serveurs de nom de domaines qui ne prend pas en charge la fonctionnalité. E.g:
/etc/systemd/resolved.conf.d/dnssec.conf
[Resolve]
DNSSEC=true
Note
Si votre serveurs DNS ne prend pas en charge DNSSEC et vous observez des problèmes avec la valeurs par défaut "allow-downgrade" (e.g.
systemd issue 10579
), vous pouvez explicitement désactiver le support DNSSEC de systemd-resolved en affectant
DNSSEC=false
.
systemd-resolved peut désactiver DNSSEC après quelques validations infructueuses . Si l'option
DNSSEC
est affectée à
true
, alors la résolution DNS stoppera de fonctionner complétement. Voir
systemd issue 9867
.
Vous pouvez tester la validation en requêtant un nom de domaine avec une signature invalide:
$ resolvectl query sigfail.verteiltesysteme.net
sigfail.verteiltesysteme.net: resolve call failed: DNSSEC validation failed: invalid
Ensuite testez un nom de domaine avec une signature valide:
$ resolvectl query sigok.verteiltesysteme.net
sigok.verteiltesysteme.net: 134.91.78.139

-- Information acquired via protocol DNS in 266.3ms.
-- Data is authenticated: yes
DNS via TLS
DNS via TLS est désactivé par défaut. Pour l'activer, changez l'option
DNSOverTLS
dans la section
[Resolve]
dans
resolved.conf(5)
. Pour activer la validation du certificat du serveurs DNS de votre fournisseur, incluez leur nom d'hôte dans l'option
DNS
avec le format
ip_address
#
hostname
. E.g:
/etc/systemd/resolved.conf.d/dns_over_tls.conf
[Resolve]
DNS=9.9.9.9#dns.quad9.net
DNSOverTLS=yes
Note
Le serveurs DNS utilisé doit prendre en charge DNS via TLS. Autrement toute les requêtes DNS vont échouer.
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. La commande
ngrep port 53
ne doit produire aucune sortie quand le nom de domaine est résolu via TLS et
ngrep port 853
doit produire un contenu chiffré.
Wireshark
peut aussi être utilisé pour plus de détails sur l'inspection des paquets DNS via TLS.
mDNS
systemd-resolved
est capable de fonctionner comme un résolveur et un répondeur
multicast DNS
.
Le résolveur fournit une résolution de
hostname
en utilisant un schénma de nom "
hostname
.local".
mDNS ne sera activé seuleument pour une connexion si le support mDNS de systemd-resolved a été activé, et si la configuration du
network manager
en vigueur active mDNS pour la connexion.
Le support mDNS de
systemd-resolved
peut être activé par son option
MulticastDNS
(Voir
resolved.conf(5) § OPTIONS
).
Activer mDNS pour chaque connexion indépendamment les unes des autres, dépends du
network manager
:
Pour
systemd-networkd
, affectez l'option
MulticastDNS
dans la section
[Network]
dans le fichier de configuration de la connexion. Vous pourriez aussi avoir à affecter l'option
Multicast=yes
dans la section
[Link]
. Voir
systemd.network(5)
.
Autrement, pour
NetworkManager
, affectez l'option
mdns
dans la section
[connection]
du fichier de configuration de la connexion. Lancez la commande
nmcli connection modify
interface_name
connection.mdns
{yes|no|resolve}
qui fera cela pour vous. Voir
nm-settings(5)
.
Note
Si
Avahi
a été installé, vous devriez envisager de
désactiver
ou
masquer
avahi-daemon.service
et
avahi-daemon.socket
pour éviter des conflits avec
systemd-resolved
.
Si vous avez l'intention d'utiliser mDNS et un
firewall
, assurez vous d'ouvrir les ports UDP
5353
.
Tip
Le défaut pour toutes les connexion de
NetworkManager
peut être affecté en créant un fichier de configuration dans
/etc/NetworkManager/conf.d/
et en affectant
connection.mdns=2
dans la section
[connection]
. Voir
NetworkManager.conf(5) § CONNECTION SECTION
et
[1]
.
LLMNR
Link-Local Multicast Name Resolution
est un protocole de résolution de
hostname
créé par Microsoft.
LLMNR ne sera activé pour la connexion si l'option global
LLMNR
de systemd-resolved dans
resolved.conf(5) § OPTIONS
et l'option de la connexion du
network manager
est activé. Par défaut
systemd-resolved
active le répondeur LLMNR;
systemd-networkd
et
NetworkManager
[2]
l'active pour les connexion.
Pour
systemd-networkd
l'option est
LLMNR
dans la section
[Network]
. Voir
systemd.network(5) § [NETWORK] SECTION OPTIONS
.
Pour
NetworkManager
l'option est
llmnr
dans la section
[connection]
. Voir
nm-settings(5) § connection setting
.
Tip
La valeur par défaut pour chaque connexion dans
NetworkManager
peut être affecté en créant un fichier de configuration dans
/etc/NetworkManager/conf.d/
et en affectant
connection.llmnr
dans la section
[connection]
. Voir
NetworkManager.conf(5) § CONNECTION SECTION
.
Si vous avez l'intention d'utiliser LLMNR et un
firewall
, assurez vous d'ouvrir les ports UDP et TCP
5355
.
Requêtes
Pour requêter les entrées DNS, mDNS ou LLMNR vous pouvez utiliser l'utilitaire
resolvectl
.
Par exemple, pour requêter une entrée DNS:
$ resolvectl query archlinux.org
archlinux.org: 2a01:4f8:172:1d86::1
               138.201.81.199

-- Information acquired via protocol DNS in 48.4ms.
-- Data is authenticated: no
Dépannage
systemd-resolved ne cherche pas le domaine local
systemd-resolved
peut ne pas chercher le domaine local quand 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
systemd-networkd
.network
approprié, et que ce fichier produit la bonne
search [domain-list]
dans
resolv.conf
. Vous pouvez lancer
networkctl status
ou
resolvectl status
pour vérifier que les domaines de recherche sont en fait bien lu.
Contournements possible:
Désactivez
LLMNR
pour laisser
systemd-resolved
continuer immédiatement en concaténant le suffixe DNS.
Supprimer le
hosts
de la base de donnée
/etc/nsswitch.conf
(e.g., en supprimant l'option
[!UNAVAIL=return]
après le service
resolve
)
Pencher pour utiliser les nom de domaines totalement qualifiés.
Uitilsez
/etc/hosts
pour résoudre les noms de domaines.
Replier vous sur le
dns
de glibc au lieu d'utiliser le
resolve
de systemd.
systemd-resolved ne résout pas les nom d'hôte sans suffix
Pour faire en sort que systemd-resolved resolve les nom d'hôte qui ne sont pas des nom de domaines totalement qualifié, ajoutez
ResolveUnicastSingleLabel=yes
à
/etc/systemd/resolved.conf
.
Warning
Cela va envoyer les noms seuls vers les serveurs DNS globaux qui peuvent ne pas être sous votre contrôle. Ce comportement est non standard, ni conforme, et peut créer des risques de sécurité et de vie privée. Voir
resolved.conf(5)
pour les détails.
Cela semble ne marcher qu'avec LLMNR désactivé (
LLMNR=no
).
Si vous utilisez
systemd-networkd
, vous pourriez vouloir que le nom de domaine fournit par le serveur DHCP ou l'IPV6 RA soit utilisé comme nom de domaine de recherche. C'est désactivé par défaut, pour l'activer il faut l'ajouter dans le fichier
.network
de l'interface:
[DHCPv4]
UseDomains=true

[IPv6AcceptRA]
UseDomains=yes
Vous pouvez vérifier ce que systemd-resolved possède pour chaque interface avec:
$ resolvectl domain
Voir aussi
Un problème de résolution de nom avec systemd-resolved que nous avont trouvé dans la nature par Francisco Ros
Voir
resolvectl(1) § EXAMPLES
pour plus d'exemples.