dnsmasq がプライベート DNS 応答を捨てる：原因は rebinding 保護か？

社内の DNS サーバーは想定どおりのプライベートアドレスを返しているのに、ローカルの転送リゾルバー経由の問い合わせは失敗する。応答は存在するので、上流のゾーンとレコード自体は除外できる。残るのは、リゾルバーがその応答をクライアントに返すかどうかを決める段階だ。そのリゾルバーが dnsmasq なら、拒否はすでにログにある可能性が高い。

応答を受け取ることと、それを返すと決めることは別の段階である。

両方のリゾルバーで同じ名前を比べる

アプリが実際にどのリゾルバーを使い、どのホスト名を問い合わせているのかを記録する。そのうえで上流の結果と、転送リゾルバーの同じ名前のイベントを比べる。上流の応答がない場合、キャッシュされた否定応答、ログにある拒否では、必要な対処が三つとも違う。

直接の診断クエリで見えたアドレスは、アプリがいつもの経路で受け取った証拠にはならない。二つのクエリは別のリゾルバーから出ることも、同じリゾルバーでも別のポリシーで出ることもある。推測する前に両方の結果を書いておく。この段階で人は一方を他方ですり替えてしまう。比較そのものが診断のすべてだ。

症状ではなく拒否を読む

dnsmasq の stop-dns-rebind オプションは、上流から届いた条件に該当するプライベートアドレスの応答を拒否し、そのときログに残す。この保護には正当な理由がある。公開名がある日突然プライベートアドレスを返すのは、古典的な rebinding 攻撃だからだ。ただし、意図的にプライベートなサービスともぶつかる。それが今回の事例である。

何かを変える前にログで拒否を探す。メッセージが仕組みの名前を示してくれる。

拒否も上流の応答もなければ、rebinding 保護は原因ではない。切っても何も直らず、露出だけが広がる。これは元の不具合より悪い。防御を一つ外したまま欠陥を残すからだ。まず具体的なログ行を確認する。それから決める。

例外を一つのドメインに絞る

検証済みのドメインには、dnsmasq のマニュアルは全体スイッチではなくドメイン限定の例外を用意している。

rebind-domain-ok=corp.example

上のドメインはあくまで例だ。実際に運用している管理ドメインを使い、適用前にこのオプションの一致範囲を理解しておく。サフィックス規則は試した一台より広くかかる。ルーターの設定生成器なら、生のディレクティブではなく独自の画面から同じ設定を出せるかもしれない。最終的な範囲が意図どおりなら、どちらの道でもよい。

rebinding 検出への例外がすることは一つだけだ。そのドメインの応答を通す。

それは split-DNS フォワーダーを設定するわけでも、到達できない上流を到達可能にするわけでも、返されたアドレスへの経路を作るわけでもない。どれも別々の要件で、それぞれ固有の故障の兆候があり、クライアントでの現れ方も違う。

境界を外さずに検証する

ホスト名を転送経路でもう一度引き、そのうえでサービスに通常の身元確認を付けて接続する。DNS の例外は想定外の証明書を受け入れる理由にはならないし、どちらもブラウザーのエラーとして出ると混同しやすい。名前とサービスを別々に試す。DNS の問題だったのは片方だけだ。

例外の理由は設定のそばに、日付と担当者とともに残す。

プライベートなサービスが移転したりドメインが変わったら見直す。保護を全体で切ると、無関係な応答の扱いまで変わり、rebinding が原因でなかった場合には経路やサービスの不具合をそのまま残すことになる。