El uso de bind9 en una computadora portátil muestra muchos dominios sin sentido cuando la conectividad de la red no funciona:
Oct 18 19:56:18 lap3 named[1536]: error (network unreachable) resolving './NS/IN': 128.63.2.53#53
Oct 18 19:56:18 lap3 named[1536]: error (network unreachable) resolving 'drgvlofubl/A/IN': 128.63.2.53#53
Oct 18 19:56:18 lap3 named[1536]: error (network unreachable) resolving 'gjpszynvcz/A/IN': 128.63.2.53#53
Oct 18 19:56:19 lap3 named[1536]: error (network unreachable) resolving 'iqgwbuxrbt/A/IN': 192.5.5.241#53
¿Cómo puedo saber qué programa está realizando estas consultas?
Agregar 'depurar' a /etc/resolv.conf no parece hacer nada (¿la computadora portátil ejecuta Arch Linux y parece no estar compilada con soporte de depuración?).
El siguiente paso es compilar libresolv con la depuración habilitada, a menos que haya algo mejor que hacer.
Respuesta1
No creo que esto sea posible dada la naturaleza de cómo funciona el DNS. DNS no sabe qué aplicaciones lo están consultando, solo que un servicio abrió un puerto en la conexión del host (asumiendo TCP) o envió un paquete UDP al servidor de enlace, y el servidor de enlace respondió con una respuesta a esta aplicación misteriosa. esa misma conexión.
Rastreadores de red
En situaciones como esta, generalmente se utiliza una aplicación para detectar el tráfico de red a medida que se transporta de un lado a otro y puede limitar su enfoque para que solo vea mensajes relacionados con un protocolo particular (DNS) en su caso o el tráfico que fluye entre 2 puntos finales. (su PC y el servidor de enlace), normalmente utilizando direcciones IP.
Dado que su pregunta despertó mi interés, aproveché la oportunidad para hacer esta pregunta en el sitio de Wireshark SE.
extracto¿Cómo puedo determinar qué aplicación envía consultas DNS a mi servidor Bind?
Estoy tratando de descubrir cómo se podría determinar qué aplicación en mi máquina Linux envía una consulta DNS particular a mi servidor Bind. He estado jugando con el siguiente comando:
$ tshark -i wlan0 -nn -e ip.src -e dns.qry.name -E separator=";" -T fields port 53 192.168.1.20;ajax.googleapis.com 192.168.1.101;ajax.googleapis.com 192.168.1.20;pop.bizmail.yahoo.com¿Cómo puedo hacer que esto me muestre la aplicación real (puerto y posiblemente PID)? Wiresharkes una de esas herramientas que usarías para hacer esto; por supuesto, hay otras.
A lo que recibí esta respuesta:
Con las capturas de paquetes normales no hay forma de identificar la aplicación o el PID de los paquetes, porque todo lo que se puede ver es desde qué puerto se envió el paquete.
Si captura en un host que está realizando la comunicación, puede intentar utilizar elPerfeccionar proyectopara obtener ese tipo de información. En Windows,Monitor de redpuede hacer lo mismo.
De lo contrario, podría intentar usar netstat en el cuadro que realiza la resolución de nombres y hacer coincidirlo con los números de puerto que usa la consulta DNS, pero como es una comunicación UDP, el puerto se abre y se cierra casi instantáneamente, por lo que las posibilidades de hacer netstat simplemente en ese milisegundo donde esté abierto va a ser como intentar ganarse la lotería.
Perfeccionar proyecto
Este enfoque parecía una pista muy prometedora. Este es el primer proyecto con el que me he encontrado que parece crear el vínculo entre los paquetes de red y los ID de procesos.
Hone es una herramienta única para correlacionar paquetes con procesos para cerrar la brecha HOst-NEtwork.
Referencias
Respuesta2
si tienes una probabilidadsospecharprograma, busque recvfromy sendtosyscalls. por ejemplo, recibí miles de búsquedas de radheengineering.info y, aunque nada en los registros de exim4 mostraba ese nombre, era el culpable más probable, con el pid principal de 1813.
entonces, usando strace -f -p1813 -erecvfrom,sendto, descubrí que, de hecho, era exim4 el que hacía las consultas. Luego bloqueé la red /24 que llegaba al servidor y eso resolvió el problema.