Perché /etc/resolv.conf punta a 127.0.0.53?

Probabilmente stai eseguendo systemd-resolved come servizio.

systemd-resolved genera due file di configurazione al volo, per l'uso facoltativo da parte delle librerie client DNS (come la libreria client DNS BIND nelle librerie C):

• /run/systemd/resolve/stub-resolv.conf dice alle librerie client DNS di inviare le loro query a 127.0.0.53. Qui è dove il systemd-resolved il processo ascolta le query DNS, che poi inoltra.
• /run/systemd/resolve/resolv.conf dice alle librerie client DNS di inviare le loro query agli indirizzi IP che systemd-resolved ha ottenuto al volo dai suoi file di configurazione e dalle informazioni sul server DNS contenute nei lease DHCP. In effetti, questo aggira il systemd-resolved passo di inoltro, a scapito di bypassare anche tutto il systemd-resolved logica per prendere decisioni complesse su cosa effettivamente inoltrare, per ogni data transazione.

In entrambi i casi, systemd-resolved configura un elenco di ricerca di suffissi di nomi di dominio, anch'esso derivato al volo dai suoi file di configurazione e lease DHCP (di cui viene informato tramite un meccanismo che va oltre lo scopo di questa risposta).

/etc/resolv.conf facoltativamente può essere:

• un collegamento simbolico a uno di questi;
• un collegamento simbolico a un static fornito dal pacchetto file in /usr/lib/systemd/resolv.conf , che specifica anche 127.0.0.53 ma nessun dominio di ricerca calcolato al volo;
• qualche altro file interamente.

È probabile che tu abbia un tale collegamento simbolico. In tal caso, la cosa che conosce l'impostazione 192.168.1.1, che è (presumibilmente) distribuita nei lease DHCP dal server DHCP sulla tua LAN, è systemd-resolved , che gli sta inoltrando il traffico di query come hai osservato. Le tue librerie client DNS, nei tuoi programmi applicativi, parlano esse stesse solo con systemd-resolved .

Ironia della sorte, anche se potrebbe sia che tu non abbia acquisito correttamente il traffico dell'interfaccia di loopback verso/da 127.0.0.53, è più probabile che tu non lo veda perché systemd-resolved inoltre (facoltativamente) bypassa il client DNS BIND nelle tue librerie C e non genera tale traffico da catturare.

C'è un modulo NSS fornito con systemd-resolved , denominato nss-resolve , che è un plug-in per le tue librerie C. In precedenza, le tue librerie C avrebbero usato un altro plug-in chiamato nss-dns che utilizza il client DNS BIND per effettuare query utilizzando il protocollo DNS ai server elencati in /etc/resolv.conf , applicando i suffissi di dominio ivi elencati.

nss-resolve viene elencato in anticipo di nss-dns nel tuo /etc/nsswitch.conf file, impedendo alle tue librerie C di utilizzare il client DNS BIND, o il protocollo DNS, per eseguire le ricerche nome→indirizzo. Invece, nss-resolve comunica un protocollo non standard e idiosincratico sul desktop bus (a livello di sistema) a systemd-resolved , che effettua di nuovo query back-end di 192.168.1.1 o qualunque cosa dicano i tuoi lease DHCP e i tuoi file di configurazione.

Per intercettare quello devi monitorare il traffico del Desktop Bus con dbus-monitor o qualche strumento del genere. Non è nemmeno traffico IP, figuriamoci traffico IP su un'interfaccia di rete loopback. poiché il Desktop Bus viene raggiunto tramite un AF_LOCAL presa.

Se desideri utilizzare un server DNS proxy di risoluzione di terze parti su 1.1.1.1 o qualche altro indirizzo IP, hai tre scelte:

• Configura il tuo server DHCP per distribuirlo invece di distribuire 192.168.1.1. systemd-resolved ne verrà a conoscenza tramite i lease DHCP e lo utilizzerà.
• Configura systemd-resolved tramite i propri meccanismi di configurazione per utilizzare quello invece di quello che vede nei lease DHCP.
• Crea il tuo /etc/resolv.conf file, un vero e proprio file normale invece di un collegamento simbolico, elenca lì 1.1.1.1 e ricorda di disattivare nss-resolve in modo da tornare a utilizzare nss-dns e il client DNS BIND.

Il systemd-resolved i file di configurazione sono un intero gruppo di file in varie directory che vengono combinati e come configurarli per la seconda scelta di cui sopra va oltre lo scopo di questa risposta. Leggi il resolved.conf (5) pagina di manuale per questo.

L'intero 127.0.0.0/8 Il blocco CIDR viene utilizzato per il routing looppack. Il tuo host sembra (o almeno sembra pensare che lo sia) eseguendo il proprio server DNS su quello specifico indirizzo di loopback.

Poiché il traffico di loopback (generalmente) non va mai in rete, non sorprende che non si veda il traffico TCP/53 in strumenti di snipping come Wireshark, poiché potrebbero non monitorare il traffico di loopback con le impostazioni predefinite. Utilizzando uno strumento come ss (ad es. ss -plnt | grep ':53' ti mostrerà quale processo, se esiste, è in ascolto su quella porta TCP per indagare ulteriormente.

Forse correlato è che Ubuntu sembra utilizzare un risolutore di loopback, systemd-resolved nelle versioni più recenti, come discusso in questa risposta su AskUbuntu.