【入門編】 DNSキャッシュポイズニングやスプーフィングのdigを用いた簡易検証 – トラブルシューティング＆ネットワーク運用監視実践ガイド

DNSという「住所案内」を狙う悪意。その正体を dig で暴こう

ネットワークエンジニアという仕事をしていると、深夜3時に叩き起こされる悪夢の多くは「名前解決ができない」という叫びから始まります。

皆さんが普段、ブラウザのアドレスバーに example.com と打ち込んでWebサイトにたどり着けるのは、裏で必死に「住所案内係（DNSサーバー）」が働いてくれているからです。しかし、この案内係、実は悪意ある第三者から「偽の住所」を教え込まれるというリスクを抱えています。これが、いわゆる「DNSキャッシュポイズニング」と呼ばれる手口です。

今日は、教科書に載っている小難しい理屈は一旦置いておいて、この「偽の手紙」をどうやって見破るか、現場で愛用している dig コマンドを使った検証術を紐解いていきましょう。

—

DNSの仕組みを「郵便配達」でイメージしてみる

まずは、DNSのやり取りを「郵便」に例えてみましょう。

1. あなた（クライアント）： 「example.com の住所を教えて！」という手紙（クエリ）を送る。
2. DNSサーバー（郵便局）： 「はい、ここですよ」という返事（レスポンス）をくれる。

ここで重要なのは、「あなたが送った手紙と、返ってきた手紙が本当にペアなのか？」という点です。もし誰か悪いやつが、あなたが返事を待っている隙に、郵便局よりも先に偽の返事をポストに投げ込んだらどうなるでしょう？そう、あなたは偽の住所（詐欺サイトなど）へ誘導されてしまうわけですね。

これを防ぐために、DNSの世界では「トランザクションID（合言葉）」と「ソースポート（差し出し窓口）」という2つの鍵を使っています。

—

現場でチェック！ dig でランダム性を確かめる

DNSサーバーがしっかり仕事をしているか、そして悪意ある攻撃者が推測しにくい「ランダムな工夫」がされているかを確認するには、dig コマンドが一番の近道です。

さっそく、ターミナルを開いて以下のコマンドを叩いてみてください。

# googleのパブリックDNSに対して、example.comの情報を問い合わせる
# +shortは結果を短く表示、+multilineは詳細を構造化して表示するオプションです
dig @8.8.8.8 example.com +multiline

これだけだと、単にIPアドレスが返ってくるだけですよね。ここで注目したいのが、「毎回同じIDが使われていないか？」という点です。

トランザクションIDのランダム性を確認する

DNSの通信には、必ず id という16ビットの番号が振られます。これが毎回「1, 2, 3…」と予測可能だったら、攻撃者は簡単に偽の返事を差し込めますよね。

以下のコマンドを数回繰り返して、id の値に注目してみてください。

# 繰り返し実行して、idが変わるか確認する
dig @8.8.8.8 example.com | grep "id"

もし、毎回違う数字（例えば 12345 が 54321 になるなど）が出ていれば、そのDNSサーバーはちゃんと「予測できない合言葉」を使っている証拠です。これがランダムであればあるほど、攻撃者は「正解の合言葉」を当てるのが難しくなります。

—

「ポート番号」という隠し扉

もう一つ、現場で非常に重視されるのが「ソースポートのランダム化」です。

DNSのクエリは、通常 53 番ポートという決まった窓口を使って送られますが、返事を受け取る側の窓口（ソースポート）は、毎回ランダムな番号（1024〜65535の間）を使うのが鉄則です。

これを確認するには、tcpdump などのツールを併用するのが一番確実ですが、まずは「DNSサーバーがちゃんとランダムなポートで喋っているか」を確認する感覚を養いましょう。

攻撃者はなぜポート番号を狙うのか？

もし、あなたが毎回「右側のポスト（固定ポート）」で手紙を待っていたら、悪いやつはそのポストだけを監視して偽手紙をねじ込めますよね。でも、毎回「今日は左のポスト、明日は裏口のポスト」というふうに、受け取り場所がランダムなら、悪いやつはどこに偽手紙を投げればいいか分かりません。

最近のDNSサーバーは、この「受け取り場所（ソースポート）」を徹底的にランダムにしています。

—

初学者がまずやるべき「守りの一歩」

ネットワーク運用監視の現場では、自分たちが管理するDNSサーバーや、社内で使っているキャッシュDNSサーバーに対して、以下のことを意識しています。

1. 「IDはちゃんとランダムか？」 → dig で何度も叩いて確認する。
2. 「古いDNSソフトを使っていないか？」 → dig のレスポンスヘッダーを見て、サーバーのバージョンが露出していないかチェックする（version.bind などの特殊なクエリで見える場合があります）。
3. 「信頼できるDNSを使っているか？」 → 訳の分からないDNSサーバーは使わず、信頼できるプロバイダーや公開DNSを活用する。

最初は難しく感じるかもしれませんが、まずは「dig を叩いて、返ってきた数字の変化を観察する」という遊びから始めてみてください。パケットの向こう側で繰り広げられる「合言葉の駆け引き」が見えてくると、ネットワークトラブルシューティングがぐっと面白くなりますよ。

「なぜ？」を追いかける姿勢こそが、最強のエンジニアへの第一歩です。また現場でお会いしましょう！