Usar o bind9 em um laptop mostra muitos domínios sem sentido quando a conectividade de rede está inoperante:
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 (o laptop está executando o Arch Linux e parece não ter sido compilado com suporte para depuração?).
O próximo passo é compilar o libresolv com a depuração habilitada, a menos que haja algo melhor para fazer.
Responder1
Não acho que isso seja possível dada a natureza de como o DNS funciona. O DNS não sabe nada sobre quais aplicativos o estão consultando, apenas que um serviço abriu uma porta na conexão do host a ele (assumindo TCP) ou enviou um pacote UDP para o servidor de ligação, e o servidor de ligação respondeu com uma resposta a esse aplicativo misterioso. essa mesma conexão.
Farejadores de rede
Em situações como essa, geralmente você usa um aplicativo para detectar o tráfego de rede enquanto ele é transportado para frente e para trás e pode restringir seu foco para ver apenas mensagens relacionadas a um protocolo específico (DNS) no seu caso ou tráfego fluindo entre 2 pontos de extremidade (seu PC e o servidor de ligação), normalmente usando endereços IP.
Como sua pergunta despertou meu interesse, aproveitei a oportunidade para fazer esta pergunta no site Wireshark SE.
excertoComo posso determinar qual aplicativo está enviando consultas DNS para meu servidor Bind?
Estou tentando descobrir como determinar qual aplicativo em minha caixa Linux está enviando uma consulta DNS específica para meu servidor Bind. Estou brincando com o seguinte 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.comComo posso fazer com que isso me mostre o aplicativo real (porta e possivelmente PID)? Wiresharké uma ferramenta que você usaria para fazer isso, é claro que existem outras.
Ao que recebi esta resposta:
Com capturas normais de pacotes, não há como identificar o aplicativo ou o PID dos pacotes, porque tudo o que você pode ver é de qual porta o pacote foi enviado.
Se você capturar em um host que está fazendo a comunicação, você pode tentar usar oAprimorar Projetopara obter esse tipo de informação. No Windows,Monitor de redepode fazer o mesmo.
Caso contrário, você pode tentar usar o netstat na caixa que faz a resolução do nome e combiná-lo com os números das portas que a consulta DNS usa, mas como é uma comunicação UDP, a porta é aberta e fechada quase instantaneamente - então as chances de fazer o netstat são apenas naquele milissegundo em que está aberto será como tentar ganhar na loteria.
Aprimorar Projeto
Essa abordagem parecia uma pista muito promissora. Este é o primeiro projeto que encontrei que parece criar a ligação entre pacotes de rede e IDs de processo.
Hone é uma ferramenta exclusiva para correlacionar pacotes a processos para preencher a divisão HOst-NETwork.
Referências
Responder2
se você tem uma probabilidadesuspeitoprograma, rastreie-o recvfrome sendtosyscalls. por exemplo, eu estava recebendo milhares de pesquisas por radheengineering.info e, embora nada nos logs do exim4 mostrasse esse nome, era o culpado mais provável, com o pid principal de 1813.
então, usando strace -f -p1813 -erecvfrom,sendto, descobri que era, de fato, o exim4 fazendo as consultas. Em seguida, bloqueei a rede /24 que atingiu o servidor e isso resolveu o problema.