Linux / Commande resolvectl : DNS de systemd-resolved et règles par lien

resolvectl consulte et pilote la résolution de noms fournie par systemd-resolved : serveurs DNS, paramètres par interface et résultats de recherche. Utilisez status pour lire la configuration et query pour observer une résolution par ce service. Si la machine utilise un autre gestionnaire de résolution, ces résultats ne décrivent pas nécessairement le chemin de votre application.

Vérifier le service et lire les paramètres DNS

DNS signifie Domain Name System. systemd-resolved est un service de résolution et de cache ; la présence de systemd ne signifie pas que ce composant est utilisé. Vérifiez resolvectl --version, man resolvectl et le service réellement configuré dans la distribution.

resolvectl status
resolvectl status enp1s0

La première commande affiche les réglages globaux et ceux des interfaces. La seconde limite l’affichage à un lien, dont le nom doit être remplacé par le nom réel. Si la commande manque ou ne joint pas le service, commencez par identifier la gestion DNS effective plutôt que d’activer un nouveau service pour obtenir une sortie.

Extrait fictif, abrégé et dépendant de la version :

Global
    Current DNS Server: 192.0.2.53
Link 2 (eth0)
    DNS Servers: 192.0.2.53

192.0.2.53 est une adresse d’exemple, pas un serveur à configurer. Le serveur courant d’un contexte ne devient pas nécessairement celui de tous les noms. Les serveurs globaux, les domaines de recherche et les règles des liens participent au choix effectué pour chaque requête.

Un VPN, Virtual Private Network, peut définir un DNS pour certains domaines seulement : c’est une forme de DNS réparti, souvent appelée split DNS. Une ligne de /etc/resolv.conf ne suffit pas à représenter toute cette politique par interface.

Comprendre domaines de recherche et routage DNS

Un domaine de recherche peut compléter un nom court. Un domaine de routage indique vers quel contexte DNS orienter une question. Dans les informations de resolved, le préfixe ~ désigne un domaine servant uniquement au routage : il n’est pas ajouté comme suffixe de recherche.

Par exemple, ~corp.example sur un lien VPN fictif indique une règle pour les noms de ce domaine. Cette mention ne crée ni les enregistrements du domaine ni une route IP vers le serveur ; elle doit correspondre à une configuration DNS et réseau fonctionnelle.

Pour les requêtes DNS concernées, resolved choisit la correspondance de domaine la plus précise. Plusieurs liens peuvent posséder la même correspondance et être sollicités. La règle ~. couvre la racine et peut diriger les noms sans règle plus précise vers un lien ; ce n’est pas une raison pour remplacer arbitrairement les domaines d’un VPN.

La documentation systemd-resolved sur la résolution et le routage explique ces choix et les modes de connexion à /etc/resolv.conf. Les noms locaux et certaines entrées de /etc/hosts peuvent aussi être résolus sans interroger un serveur distant.

Interroger un nom et examiner les statistiques

resolvectl query example.com
resolvectl statistics

query demande la résolution par resolved et peut indiquer le protocole et l’interface associés au résultat. La réponse peut provenir d’un cache ou d’une source locale. Selon le nom et la configuration, resolved peut aussi utiliser des mécanismes locaux de noms : ne supposez pas que chaque succès représente un échange DNS externe à cet instant.

statistics affiche les compteurs de résolution et de validation disponibles. Un nombre de réponses en cache n’est pas une mesure du fonctionnement d’une application. Relevez les valeurs avant et après une observation comparable et gardez les conditions ; changer les caches entre deux relevés modifie l’expérience.

Pour comparer avec une requête adressée directement à un serveur DNS, utilisez la commande dig et le choix explicite du serveur. Les deux résultats peuvent différer avec les caches, les règles de routage ou les sources locales. Une application possédant son propre résolveur peut encore suivre un autre chemin.

Si un nom public fonctionne mais qu’un nom interne échoue après connexion au VPN, comparez le lien du VPN, ses serveurs et domaines avec ceux attendus. Vérifiez ensuite que le serveur DNS est joignable et que le nom demandé correspond au domaine prévu. Ne videz pas immédiatement tous les caches avant d’avoir relevé ces informations.

Séparer lecture, cache et modification des réglages

Les formes suivantes sont des consultations pour un lien réel à substituer à enp1s0 :

resolvectl dns enp1s0
resolvectl domain enp1s0

Ajouter une adresse après dns ou un domaine après domain n’est plus une simple lecture. Un changement peut perturber les noms internes et votre accès distant. Relevez les valeurs et leur origine, préparez le rétablissement et intervenez dans le gestionnaire qui possède réellement la configuration.

Des paramètres provenant de NetworkManager, d’un client DHCP, Dynamic Host Configuration Protocol, ou d’un profil VPN peuvent être réappliqués. Un changement ponctuel via resolvectl ne constitue donc pas automatiquement un réglage persistant. La commande revert remet les paramètres du lien à leurs valeurs par défaut ; elle ne restaure pas une photographie arbitraire de vos anciens réglages.

flush-caches concerne les caches maintenus par resolved ; il ne vide pas ceux d’un navigateur ni ceux du DNS de l’entreprise. Il change les conditions de diagnostic et ne corrige pas une règle de domaine erronée. Le manuel resolvectl précise les commandes et leur portée selon la version.