노트북에서 바인드9을 사용하면 네트워크 연결이 끊어졌을 때 의미 없는 도메인이 많이 표시됩니다.
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
어떤 프로그램이 이러한 쿼리를 발행하는지 어떻게 알 수 있나요?
/etc/resolv.conf에 "디버그"를 추가해도 아무 일도 하지 않는 것 같습니다(노트북이 Arch Linux를 실행하고 있는데 디버그 지원으로 컴파일되지 않는 것 같나요?).
다음 단계는 더 나은 방법이 없는 한 디버깅을 활성화한 상태에서 libresolv를 컴파일하는 것입니다.
답변1
DNS 작동 방식의 특성을 고려할 때 이것이 가능하다고 생각하지 않습니다. DNS는 어떤 애플리케이션이 쿼리하고 있는지 알지 못하며 서비스가 호스트 연결(TCP로 가정)에서 포트를 열었거나 바인딩 서버에 UDP 패킷을 보냈으며 바인딩 서버가 이 신비한 애플리케이션을 통해 응답했다는 것만 알고 있습니다. 같은 연결.
네트워크 스니퍼
이 경우 일반적으로 애플리케이션을 사용하여 앞뒤로 이동하는 네트워크 트래픽을 스니핑하고 해당 사례 또는 2 엔드포인트 간 트래픽 흐름에서 특정 프로토콜(DNS)과 관련된 메시지만 볼 수 있도록 범위를 좁힐 수 있습니다. (PC 및 바인딩 서버), 일반적으로 IP 주소를 사용합니다.
귀하의 질문이 저의 관심을 불러일으켰기 때문에 저는 Wireshark SE 웹사이트에서 이 질문을 할 기회를 얻었습니다.
발췌어떤 애플리케이션이 내 바인딩 서버에 DNS 쿼리를 보내는지 어떻게 확인하나요?
Linux 시스템의 어떤 응용 프로그램이 내 Bind 서버에 특정 DNS 쿼리를 보내는지 확인하는 방법을 알아내려고 합니다. 나는 다음 명령을 가지고 놀았습니다.
$ 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실제 애플리케이션(포트 및 PID)을 표시하려면 어떻게 해야 합니까? 와이어샤크이를 수행하는 데 사용하는 것은 이러한 유형의 도구이며 물론 다른 도구도 있습니다.
나는 다음과 같은 답변을 받았습니다.
일반적인 패킷 캡처를 사용하면 패킷이 전송된 포트만 볼 수 있으므로 패킷에서 애플리케이션이나 PID를 식별할 방법이 없습니다.
통신 중인 호스트에서 캡처하는 경우 다음을 사용해 볼 수 있습니다.프로젝트를 연마하다그러한 정보를 얻으려면. 윈도우에서는,네트워크 모니터같은 일을 할 수 있습니다.
그렇지 않으면 이름 확인을 수행하는 상자에서 netstat를 사용하여 DNS 쿼리에 사용되는 포트 번호와 일치시킬 수 있지만 UDP 트래픽이므로 포트가 거의 즉시 열리고 닫힙니다. 따라서 netstat를 수행할 수 있는 기회가 있습니다. 1000분의 1초 동안은 복권에 당첨되려고 노력하는 것과 같습니다.
프로젝트를 연마하다
이 접근 방식은 매우 유망한 리드처럼 보입니다. 이것은 네트워크 패킷과 프로세스 ID 사이에 링크를 생성하는 것처럼 보이는 첫 번째 프로젝트입니다.
Hone은 호스트와 네트워크 사이의 격차를 해소하기 위해 프로세스와 패킷의 상관관계를 지정하는 고유한 도구입니다.
인용하다
답변2
가능성이 있다면의심하다프로그램을 추적 recvfrom하고 sendto시스템 호출을 수행합니다. 예를 들어, 나는 radheengineering.info에 대해 수천 번의 조회를 수행했으며 해당 이름이 exim4에 대한 로그에 표시되지 않지만 기본 pid가 1813인 범인일 가능성이 가장 높습니다.
그래서 쿼리를 사용하여 strace -f -p1813 -erecvfrom,sendto실제로 exim4라는 것을 알았습니다. 그런 다음 서버에 연결된 /24 네트워크를 차단하고 문제가 해결되었습니다.