☰

Bind9 - どのプログラムがどの DNS 検索を実行しているかを見つけるにはどうすればよいでしょうか?

tag-icon • tag-icon networking process dns monitoring bind
Bind9 - どのプログラムがどの DNS 検索を実行しているかを見つけるにはどうすればよいでしょうか?

ラップトップで 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 に 'debug' を追加しても何も起こらないようです (ラップトップは Arch Linux を実行しており、デバッグ サポート付きでコンパイルされていないようです)。

次のステップは、他にもっと良い方法がない限り、デバッグを有効にして libresolv をコンパイルすることです。

答え1

DNS の動作の性質を考えると、これは不可能だと思います。DNS は、どのアプリケーションがクエリを実行しているかは知りません。DNS は、サービスがホスト接続でポートを開いたか (TCP の場合)、またはバインド サーバーに UDP パケットを送信し、バインド サーバーが同じ接続を介してこの謎のアプリケーションに応答しただけです。

ネットワークスニファー

このような状況では、通常、アプリケーションを使用して、ネットワーク トラフィックが送受信されるときにそれをスニッフィングし、焦点を絞り込んで、特定のプロトコル (DNS) に関連するメッセージのみを表示したり、通常は IP アドレスを使用して 2 つのエンドポイント (PC とバインド サーバー) 間で流れるトラフィックのみを表示したりできます。

あなたの質問に興味をそそられたので、この機会を利用して Wireshark SE サイトでこの質問をしました。

抜粋どのアプリケーションが Bind サーバーに 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 など) を表示するにはどうすればよいでしょうか? ワイヤーシャークこれはこれを行うために使用するツールの 1 つですが、もちろん他にもツールはあります。

私は次のような答えを受け取りました:

通常のパケット キャプチャでは、パケットが送信されたポートしか確認できないため、パケットからアプリケーションまたは PID を識別する方法はありません。

通信を行っているホストでキャプチャする場合は、ホーンプロジェクトそのような情報を取得するには、Windowsではネットワークモニター同じことができます。

あるいは、名前解決を行うボックスで netstat を使用して、DNS クエリが使用するポート番号と一致させることもできますが、UDP 通信であるため、ポートはほぼ瞬時に開いたり閉じたりします。そのため、ポートが開いているそのミリ秒間に netstat を実行できる可能性は、宝くじに当たるようなものになります。

ホーンプロジェクト

このアプローチは非常に有望に思えました。これは、ネットワーク パケットとプロセス ID 間のリンクを作成すると思われる初めてのプロジェクトです。

Hone は、パケットとプロセスを関連付けてホストとネットワークの隔たりを埋める独自のツールです。

参考文献

答え2

もしあなたが容疑者プログラム、strace、recvfromおよびsendtoシステムコールを調べます。たとえば、radheengineering.info の検索が何千回も行われていましたが、exim4 のログにはその名前は何も表示されませんでしたが、プライマリ pid が 1813 であるため、これが最も可能性の高い原因でした。

そこで、 を使用してstrace -f -p1813 -erecvfrom,sendto、クエリを作成していたのは確かに exim4 であることがわかりました。次に、サーバーにアクセスしている /24 ネットワークをブラックホール化し、問題を解決しました。

関連情報