Bind9 - Como descobrir quais programas estão fazendo quais pesquisas de dns?

Question

Usar o bind9 em um laptop mostra muitos domínios sem sentido quando a conectividade de rede está inativa:

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

Como descubro qual programa está fazendo essas consultas?

Adicionar 'debug' ao /etc/resolv.conf não parece fazer nada (laptop está rodando Arch linux e parece não estar compilado com suporte a depuração?).

O próximo passo é compilar a libresolv com a depuração ativada, a menos que haja algo melhor para fazer.

    

Answer 1

Eu não acho que isso será possível, dada a natureza de como o DNS funciona. O DNS não sabe nada de quais aplicativos o estão consultando, apenas que um serviço abriu uma porta na conexão do host a ele (assumindo o TCP) ou enviou um pacote UDP ao servidor de ligação e o servidor de ligação respondeu com uma resposta a esse aplicativo misterioso. essa mesma conexão.

Sniffers de Rede

Em situações como essa, geralmente você usa um aplicativo para farejar o tráfego de rede à medida que ele é transportado e pode restringir seu foco para que você veja apenas mensagens relacionadas a um protocolo específico (DNS) no seu caso ou fluxo de tráfego entre 2 terminais (seu PC e o servidor de ligação), geralmente usando endereços IP.

Como sua pergunta atingiu meu interesse, aproveitei a oportunidade para fazer essa pergunta no site do Wireshark SE.

excerto Como posso determinar qual aplicativo está enviando consultas DNS para o meu servidor Bind?

I'm trying to figure out how one would go about determining which application on my Linux box is sending a particular DNS query to my Bind server. I've been toying with the following command:

$ 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

How can I get this to show me the actual application (port and possibly PID)? Wireshark is one such tool that you'd use to do this, there are of course others.

Para o qual recebi esta resposta:

With normal packet captures there is no way of identifying the application or PID from the packets, because all you can see is what port the packet was sent from.

If you capture on a host that is doing the communication you could try to use the Hone Project to get that kind of information. On Windows, Network Monitor can do the same.

Otherwise you could try to use netstat on the box that does the name resolution and match it to the port numbers the DNS query uses, but since it is a UDP communication the port is open and closed almost instantly - so chances to do the netstat just in that millisecond where it is open is going to be like trying to win the lottery.

Projeto Hone

Essa abordagem parecia uma vantagem muito promissora. Este é o primeiro projeto que eu já vi que criaria a ligação entre pacotes de rede e IDs de processo.

Hone is a unique tool for correlating packets to processes to bridge the HOst-NEtwork divide.

Referências

• filtros tshark
• Projeto Hone
• ask.wireshark.org

Answer 2

Se você tiver um provável programa suspeito , marque-o para recvfrom e sendto syscalls. por exemplo, eu estava recebendo milhares de pesquisas para o radheengineering.info e, embora nada nos registros do exim4 mostrasse esse nome, foi o culpado mais provável, com o pid primário de 1813.

então, usando strace -f -p1813 -erecvfrom,sendto , descobri que era, de fato, o exim4 fazendo as consultas. Eu então enterrei a rede / 24 atingindo o servidor e isso resolveu o problema.