Vous utilisez probablement systemd-resolved en tant que service.
systemd-resolved génère deux fichiers de configuration à la volée, pour une utilisation facultative par les bibliothèques clientes DNS (telles que la bibliothèque cliente DNS BIND dans les bibliothèques C) :
/run/systemd/resolve/stub-resolv.confindique aux bibliothèques clientes DNS d'envoyer leurs requêtes à 127.0.0.53. C'est là que lesystemd-resolvedle processus écoute les requêtes DNS, qu'il transmet ensuite./run/systemd/resolve/resolv.confindique aux bibliothèques clientes DNS d'envoyer leurs requêtes aux adresses IP quisystemd-resolveda obtenu à la volée de ses fichiers de configuration et des informations de serveur DNS contenues dans les baux DHCP. Effectivement, cela contourne lesystemd-resolvedétape de transfert, au prix de contourner également tous lessystemd-resolvedpour prendre des décisions complexes sur ce vers quoi transférer, pour une transaction donnée.
Dans les deux cas, systemd-resolved configure une liste de recherche de suffixes de noms de domaine, à nouveau dérivée à la volée de ses fichiers de configuration et de ses baux DHCP (dont on lui parle via un mécanisme qui dépasse le cadre de cette réponse).
/etc/resolv.conf peut éventuellement être :
- un lien symbolique vers l'un ou l'autre ;
- un lien symbolique vers un élément statique fourni par le package fichier à
/usr/lib/systemd/resolv.conf, qui spécifie également 127.0.0.53 mais aucun domaine de recherche calculé à la volée ; - un autre fichier entièrement.
Il est probable que vous ayez un tel lien symbolique. Dans ce cas, la chose qui connaît le paramètre 192.168.1.1, qui est (probablement) remis dans les baux DHCP par le serveur DHCP sur votre réseau local, est systemd-resolved , qui lui transmet le trafic des requêtes comme vous l'avez observé. Vos bibliothèques clientes DNS, dans vos programmes d'application, ne parlent elles-mêmes qu'à systemd-resolved .
Ironiquement, même si cela pourrait que vous n'ayez pas correctement capturé le trafic de l'interface de bouclage vers/depuis 127.0.0.53, il est plus probable que vous ne le voyiez pas parce que systemd-resolved contourne également (éventuellement) le client DNS BIND dans vos bibliothèques C et ne génère aucun trafic de ce type à capturer.
Il y a un module NSS fourni avec systemd-resolved , nommé nss-resolve , qui est un plug-in pour vos bibliothèques C. Auparavant, vos bibliothèques C auraient utilisé un autre plug-in nommé nss-dns qui utilise le client DNS BIND pour effectuer des requêtes à l'aide du protocole DNS vers le(s) serveur(s) répertorié(s) dans /etc/resolv.conf , en appliquant les suffixes de domaine qui y sont répertoriés.
nss-resolve est listé devant de nss-dns dans votre /etc/nsswitch.conf , ce qui empêche vos bibliothèques C d'utiliser le client DNS BIND ou le protocole DNS pour effectuer des recherches de nom → adresse. Au lieu de cela, nss-resolve parle un protocole non standard et idiosyncratique sur le bus de bureau (à l'échelle du système) vers systemd-resolved , qui effectue à nouveau des requêtes principales sur 192.168.1.1 ou tout ce que disent vos baux DHCP et vos fichiers de configuration.
Pour intercepter ça vous devez surveiller le trafic Desktop Bus avec dbus-monitor ou un outil de ce type. Ce n'est même pas du trafic IP, encore moins du trafic IP sur une interface réseau en boucle. car le bus de bureau est atteint via un AF_LOCAL prise.
Si vous souhaitez utiliser un serveur DNS proxy de résolution tiers à 1.1.1.1, ou une autre adresse IP, vous avez trois choix :
- Configurez votre serveur DHCP pour distribuer cela au lieu de distribuer 192.168.1.1.
systemd-resolvedapprendra cela via les baux DHCP et l'utilisera. - Configurer
systemd-resolvedvia ses propres mécanismes de configuration pour l'utiliser au lieu de ce qu'il voit dans les baux DHCP. - Créez votre propre
/etc/resolv.conffile, un fichier normal réel au lieu d'un lien symbolique, indiquez 1.1.1.1 ici et n'oubliez pas de désactivernss-resolvepour que vous reveniez à l'utilisation denss-dnset le client DNS BIND.
Le systemd-resolved les fichiers de configuration sont tout un tas de fichiers dans divers répertoires qui sont combinés, et comment les configurer pour le deuxième choix susmentionné dépasse le cadre de cette réponse. Lisez le resolved.conf (5) page de manuel pour cela.
L'ensemble 127.0.0.0/8 Le bloc CIDR est utilisé pour le routage en boucle. Votre hôte semble (ou du moins semble penser qu'il exécute) son propre serveur DNS sur cette adresse de bouclage spécifique.
Étant donné que le trafic de bouclage ne passe (généralement) jamais sur le réseau, il n'est pas surprenant que vous ne voyiez pas de trafic TCP/53 dans les outils de capture tels que Wireshark, car ils peuvent ne pas surveiller le trafic de bouclage avec les paramètres par défaut. Utiliser un outil tel que ss (ex. ss -plnt | grep ':53' vous montrera quel processus, le cas échéant, écoute sur ce port TCP pour une enquête plus approfondie.
Peut-être est qu'Ubuntu semble utiliser un résolveur de bouclage, systemd-resolved dans les versions plus récentes, comme indiqué dans cette réponse sur AskUbuntu.