¿Por qué /etc/resolv.conf apunta a 127.0.0.53?

Es probable que esté ejecutando systemd-resolved como un servicio.

systemd-resolved genera dos archivos de configuración sobre la marcha, para uso opcional de las bibliotecas de cliente DNS (como la biblioteca de cliente BIND DNS en las bibliotecas C):

• /run/systemd/resolve/stub-resolv.conf le dice a las bibliotecas de clientes DNS que envíen sus consultas a 127.0.0.53. Aquí es donde el systemd-resolved el proceso escucha las consultas de DNS, que luego reenvía.
• /run/systemd/resolve/resolv.conf le dice a las bibliotecas de clientes DNS que envíen sus consultas a las direcciones IP que systemd-resolved ha obtenido sobre la marcha de sus archivos de configuración y la información del servidor DNS contenida en las concesiones de DHCP. Efectivamente, esto pasa por alto el systemd-resolved paso de reenvío, a expensas de omitir también todo systemd-resolved La lógica de para tomar decisiones complejas sobre qué reenviar realmente, para cualquier transacción dada.

En ambos casos, systemd-resolved configura una lista de búsqueda de sufijos de nombres de dominio, nuevamente derivados sobre la marcha de sus archivos de configuración y arrendamientos de DHCP (sobre los cuales se informa a través de un mecanismo que está más allá del alcance de esta respuesta).

/etc/resolv.conf puede ser opcionalmente:

• un enlace simbólico a cualquiera de estos;
• un enlace simbólico a un paquete estático proporcionado archivo en /usr/lib/systemd/resolv.conf , que también especifica 127.0.0.53 pero no se calculan dominios de búsqueda sobre la marcha;
• algún otro archivo por completo.

Es probable que tenga un enlace tan simbólico. En cuyo caso, lo que sabe sobre la configuración 192.168.1.1, que (presuntamente) se entrega en arrendamientos DHCP por parte del servidor DHCP en su LAN, es systemd-resolved , que le está reenviando el tráfico de consultas como ha observado. Sus bibliotecas de clientes DNS, en sus programas de aplicaciones, solo están hablando con systemd-resolved .

Irónicamente, aunque podría sea ​​que no ha capturado correctamente el tráfico de la interfaz loopback hacia/desde 127.0.0.53, es más probable que no lo esté viendo porque systemd-resolved también (opcionalmente) pasa por alto el Cliente DNS BIND en sus bibliotecas C y no genera tal tráfico para ser capturado.

Se proporciona un módulo NSS con systemd-resolved , llamado nss-resolve , ese es un complemento para sus bibliotecas C. Anteriormente, sus bibliotecas C habrían usado otro complemento llamado nss-dns que utiliza el cliente BIND DNS para realizar consultas utilizando el protocolo DNS a los servidores enumerados en /etc/resolv.conf , aplicando los sufijos de dominio enumerados en el mismo.

nss-resolve aparece por delante de nss-dns en tu /etc/nsswitch.conf archivo, lo que hace que sus bibliotecas C no usen el cliente BIND DNS, o el protocolo DNS, para realizar búsquedas de nombre→dirección en absoluto. En su lugar, nss-resolve habla un protocolo no estándar e idiosincrásico a través del bus de escritorio (en todo el sistema) a systemd-resolved , que nuevamente realiza consultas de back-end de 192.168.1.1 o lo que digan sus arrendamientos de DHCP y archivos de configuración.

Para interceptar eso debe monitorear el tráfico de Desktop Bus con dbus-monitor o alguna herramienta similar. Ni siquiera es tráfico IP, y mucho menos tráfico IP a través de una interfaz de red de bucle invertido. ya que se llega al Desktop Bus a través de un AF_LOCAL enchufe.

Si desea utilizar un servidor DNS proxy de resolución de terceros en 1.1.1.1, o alguna otra dirección IP, tiene tres opciones:

• Configure su servidor DHCP para entregar eso en lugar de entregar 192.168.1.1. systemd-resolved se enterará de eso a través de los arrendamientos de DHCP y lo usará.
• Configurar systemd-resolved a través de sus propios mecanismos de configuración para usar eso en lugar de lo que está viendo en las concesiones de DHCP.
• Haz tu propio /etc/resolv.conf archivo, un archivo normal real en lugar de un enlace simbólico, enumere 1.1.1.1 allí y recuerde desactivar nss-resolve para que vuelvas a usar nss-dns y el Cliente DNS BIND.

El systemd-resolved los archivos de configuración son un montón de archivos en varios directorios que se combinan, y cómo configurarlos para la segunda opción antes mencionada está más allá del alcance de esta respuesta. Lea el resolved.conf (5) página de manual para eso.

Todo el 127.0.0.0/8 El bloque CIDR se utiliza para el enrutamiento de looppack. Su host parece estar (o al menos parece pensar que lo está) ejecutando su propio servidor DNS en esa dirección de loopback específica.

Debido a que el tráfico de bucle invertido (generalmente) nunca pasa por el cable, no es sorprendente que no vea el tráfico TCP/53 en herramientas de corte como Wireshark, ya que es posible que no controlen el tráfico de bucle invertido con la configuración predeterminada. Usando una herramienta como ss (por ejemplo, ss -plnt | grep ':53' le mostrará qué proceso, si lo hay, está escuchando en ese puerto TCP para investigar más.

Posiblemente relacionado es que Ubuntu parece usar un solucionador de loopback, systemd-resolved en versiones más recientes, como se explica en esta respuesta en AskUbuntu.