
랩톱에서 바인딩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 패킷을 보냈고 바인드 서버가 이 미스터리 응용 프로그램에 대한 응답으로 응답했다는 사실만 알 수 있습니다. 그 같은 연결.
네트워크 스니퍼
이와 같은 상황에서는 일반적으로 애플리케이션을 사용하여 네트워크 트래픽이 앞뒤로 전송될 때 이를 스니핑하고 해당 사례의 특정 프로토콜(DNS)과 관련된 메시지나 두 끝점 사이의 트래픽만 볼 수 있도록 범위를 좁힐 수 있습니다. (PC 및 바인드 서버), 일반적으로 IP 주소를 사용합니다.
귀하의 질문이 내 관심을 최고조에 달했기 때문에 저는 Wireshark SE 사이트에서 이 Q에 대해 질문할 기회를 가졌습니다.
발췌어떤 애플리케이션이 내 바인드 서버에 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은 HOst-NEtwork 분할을 연결하기 위해 패킷을 프로세스와 연관시키는 고유한 도구입니다.
참고자료
답변2
가능성이 있다면의심하다프로그램, strace recvfrom
및 sendto
syscalls. 예를 들어, 나는 radheengineering.info에 대해 수천 번의 조회를 받았고 exim4의 로그에는 해당 이름이 표시되지 않았지만 기본 pid가 1813인 가장 가능성이 높은 범인이었습니다.
그래서 를 사용하여 strace -f -p1813 -erecvfrom,sendto
실제로 쿼리를 수행하는 것은 exim4라는 것을 알았습니다. 그런 다음 서버에 도달하는 /24 네트워크를 블랙홀화하여 문제를 해결했습니다.