質問と回答の両方を含むクエリログのサポートは、最善でもまちまちです。最も広くデプロイされている DNS サーバの 1 つである BIND は、まったくサポートしていません。Windows DNS のような他のサーバは、非常に扱いにくいログ形式を持っています。さらに、ネットワークベースのログ記録では、クライアントからリモートサーバ（例：Google DNS）に直接送信されたクエリもキャプチャできます。

使用方法

設定オプションは、環境変数、.env ファイル、またはコマンドラインで指定できます。優先順位は、コマンドラインフラグ、.env ファイル、最後に既に環境に定義されている変数の順です。設定オプションは以下の通りです。

• -dev [デバイス] キャプチャ用のネットワークデバイス (ENV: PDNS_DEV)
• -fluentd_socket [ソケット] messagepack 形式でログを出力する Fluentd Unix ソケットのパス (ENV: PDNS_FLUENTD_SOCKET)
• -bpf [BPF フィルタ] キャプチャ用の BPF フィルタ (デフォルト: port 53) (ENV: PDNS_BPF)
• -pcap [ファイル] 処理する pcap ファイル (ENV: PDNS_PCAP_FILE)
• -logfile [ファイル] DNS ルックアップのログファイル (小規模なデプロイやデバッグのみ推奨) (ENV: PDNS_LOG_FILE)
• -logMaxAge ログファイルの最大保存期間（ローテーション前）、日数 (デフォルト: 28) (ENV: PDNS_LOG_AGE)
• -logMaxBackups ローテーション後に保持する最大ファイル数 (デフォルト: 3) (ENV: PDNS_LOG_BACKUP)
• -logMaxSize ローテーション前のログファイルの最大サイズ、MB (デフォルト: 100) (ENV: PDNS_LOG_SIZE)
• -quiet DNS ルックアップを STDOUT にログ出力しない (ENV: PDNS_QUIET)
• -debug デバッグログを STDOUT に有効にする (ENV: PDNS_DEBUG)
• -gc_age [数値] 不完全な接続をガベージコレクションする基準となる経過時間 (デフォルト: -1m) (ENV: PDNS_GC_AGE)
• -gc_interval [数値] 接続テーブルでガベージコレクションを実行する間隔 (デフォルト: 3m) (ENV: PDNS_GC_INTERVAL)
• -kafka_brokers [ブローカ] カンマ区切りの Kafka ブローカリスト (ENV: PDNS_KAFKA_PEERS)
• -kafka_topic [トピック] ログ出力用の Kafka トピック (ENV: PDNS_KAFKA_TOPIC)
• -cpuprofile [ファイル] CPU プロファイリングを有効にする (ENV: PDNS_PROFILE_FILE)
• -numprocs [数値] パケットデータの解析に使用する goroutine の数 (デフォルト: 8) (ENV: PDNS_THREADS)
• -pfring パケットキャプチャに PF_RING を使用する (ENV: PDNS_PFRING)
• -statsd_host statsd サーバのホストとポート (例: localhost:8125) (ENV: PDNS_STATSD_HOST)
• -statsd_interval statsd への送信間隔（秒）(ENV: PDNS_STATSD_INTERVAL)
• -statsd_prefix 使用するメトリック名のプレフィックス（デフォルト: gopassivedns）(ENV: PDNS_STATSD_PREFIX)
• -snaplen [整数] pcap バッファに使用する snaplen
• -name 統計やログメッセージで使用するこのセンサーの名前（デフォルトはホスト名）(ENV: PDNS_NAME)
• -syslog_facility syslog ファシリティ (ENV: PDNS_SYSLOG_FACILITY)
• -syslog_priority syslog プライオリティ (ENV: PDNS_SYSLOG_PRIORITY)

-dev または -pcap のいずれかを指定する必要があります。

goroutine と標準のデーモン化プロセスには既知の問題があるため（https://github.com/golang/go/issues/227）、http://stackoverflow.com/questions/10067295/how-to-start-a-go-program-as-a-daemon-in-ubuntu で説明されている方法のいずれかを使用して、システムツールでこのプロセスをデーモンとして実行することを強くお勧めします。

syslog ログを選択した場合、golang の "log/syslog" を使用します。これには、syslog と通信するための Unix ソケットが /dev/log、/var/run/log、または /var/run/syslog のいずれかに存在する必要があります。

導入ガイド

どこに導入すべきか？

3 つの選択肢があります: リゾルバに導入する、ゲートウェイに導入する、またはその両方です。リゾルバに導入する利点は、元のリクエストを送信したクライアントの IP アドレスを取得できることです。BPF フィルタで上流のレッグを無視しない限り、リクエストの上流レッグ（リゾルバからチェーン内の次のリゾルバへ）も確認できます。ゲートウェイに導入する場合、クライアントから内部リゾルバへのレッグは見えないため、リクエストを特定のクライアントに結びつけるのが難しくなります。その代わり、内部リゾルバをバイパスするリクエストを確認できます。また、リゾルバが使用する上流のリゾルバへのクエリも確認できます。理想的な世界では、このツールを各内部リゾルバとゲートウェイのタップに導入します。内部リゾルバでは、クエリの上流レッグを無視する BPF フィルタを設定し、ゲートウェイでは何も無視しません。

結果をどう処理すべきか？

現時点では、logstash を使用してログを elasticsearch クラスタに転送することをお勧めします。すべてのログは JSON 形式なので、これは非常に簡単です。長期保存やバルク分析には HDFS のようなものを使用することも提案します。DNS クエリは内部データの素晴らしい情報源です！

ビルドとインストール

• このリポジトリをクローンします。
• libpcap、libpcap-dev をインストールします。
• 'go get' を実行します。
• 'go build -o gopassivedns' を実行します（-o は念のためのもので、リポジトリをクローンした場合は不要です）。
• 'cp gopassivedns /some/path/to/gopassivedns' を実行します。