ノートブックでBind9を使用すると、ネットワークが切断されたときに意味のないドメインがたくさん表示されます。
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ネットワークをブロックし、問題を解決しました。