Verificamos exhaustivamente cada noticias en nuestra página web con el objetivo de mostrarte siempre información más veraz y certera.
Solución:
Es probable que estés corriendo systemd-resolved como servicio.
systemd-resolved genera dos archivos de configuración sobre la marcha, para uso opcional de las bibliotecas cliente DNS (como la biblioteca cliente BIND DNS en las bibliotecas C):
/run/systemd/resolve/stub-resolv.confle dice a las bibliotecas de cliente DNS que envíen sus consultas a 127.0.0.53. Aquí es donde elsystemd-resolvedEl proceso escucha las consultas de DNS, que luego reenvía./run/systemd/resolve/resolv.confle dice a las bibliotecas de cliente DNS que envíen sus consultas a direcciones IP quesystemd-resolvedha obtenido sobre la marcha de sus archivos de configuración y la información del servidor DNS contenida en los arrendamientos DHCP. Efectivamente, esto pasa por alto elsystemd-resolvedpaso de avance, a expensas de también eludir todos lossystemd-resolvedEs la lógica para tomar decisiones complejas sobre a 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 DHCP (de los cuales se informa a través de un mecanismo que está más allá del alcance de esta respuesta).
/etc/resolv.conf opcionalmente puede ser:
- un enlace simbólico a cualquiera de estos;
- un enlace simbólico a un paquete suministrado static archivar en
/usr/lib/systemd/resolv.conf, que también especifica 127.0.0.53 pero sin dominios de búsqueda calculados sobre la marcha; - algún otro archivo por completo.
Es probable que tengas un vínculo tan simbólico. En cuyo caso, lo que sabe acerca de la configuración 192.168.1.1, que (presumiblemente) se entrega en concesiones DHCP por el servidor DHCP en su LAN, es systemd-resolved, que le reenvía el tráfico de consultas como ha observado. Sus bibliotecas de cliente DNS, en sus programas de aplicaciones, solo están hablando con systemd-resolved.
Irónicamente, aunque podría ya que no ha capturado el tráfico de la interfaz de bucle invertido hacia / desde 127.0.0.53 correctamente, es más probable que no lo esté viendo porque systemd-resolved también (opcionalmente) omite el BIND DNS Client en sus bibliotecas C y no genera ese tráfico para ser capturado.
Hay un módulo NSS provisto con systemd-resolved, llamado nss-resolve, que es un complemento para sus bibliotecas C. Anteriormente, sus bibliotecas de C habrían usado otro complemento llamado nss-dns que utiliza BIND DNS Client para realizar consultas utilizando el protocolo DNS a los servidores enumerados en /etc/resolv.conf, aplicando los sufijos de dominio allí enumerados.
nss-resolve se enumera adelante de nss-dns en tus /etc/nsswitch.conf archivo, lo que hace que sus bibliotecas C no utilicen BIND DNS Client, o el protocolo DNS, para realizar búsquedas de nombre → dirección en absoluto. En lugar de, nss-resolve habla un protocolo no estándar e idiosincrásico sobre el bus de escritorio (en todo el sistema) para systemd-resolved, que nuevamente realiza consultas de back-end de 192.168.1.1 o lo que digan sus arrendamientos DHCP y archivos de configuración.
Para interceptar ese tienes que monitorear el tráfico de Desktop Bus con dbus-monitor o alguna herramienta de este tipo. 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 el bus de escritorio se alcanza 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 distribuir eso en lugar de distribuir 192.168.1.1.
systemd-resolvedaprenderá de eso a través de los arrendamientos de DHCP y lo usará. - Configurar
systemd-resolveda través de sus propios mecanismos de configuración para usar eso en lugar de lo que está viendo en los arrendamientos DHCP. - Haz lo tuyo
/etc/resolv.confarchivo, un archivo normal real en lugar de un enlace simbólico, enumere 1.1.1.1 allí y recuerde apagarnss-resolvepara que vuelvas a usarnss-dnsy el cliente BIND DNS.
los 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 mencionada anteriormente está más allá del alcance de esta respuesta. Leer el resolved.conf(5) página de manual para eso.
La totalidad 127.0.0.0/8 El bloque CIDR se utiliza para el enrutamiento de loopack. 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 recorte 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 (p.ej ss -plnt | grep ':53' le mostrará qué proceso, si lo hay, está escuchando en ese puerto TCP para investigar más a fondo.
Posiblemente releated es que Ubuntu parece usar un solucionador de loopback, systemd-resolved en versiones más recientes, como se discutió en esta respuesta en AskUbuntu.