みなさんこんばんわ。

ある日検証環境を構築しているときに思いついた事を実装し、そこから得た気付きを記載します。
検証環境のルーターがNECのIXシリーズでネットワーク内にローカルDNSサーバなく、DNSサーバがあると進めやすい検証を行わなければならないといった状況が有り、思い付きで試してみたところうまくいったので少し深堀りして調べてみました。

普段はhostsファイルにFQDNを書いて対応していたのですが、あえてDNSサーバを使う、という構築にこだわった結果です。

Azure DNSの仕様

なんと、Azure DNSにローカルIPアドレスを設定しても問題なく返してくれます。
YAMAHAのRTXシリーズだとip hostコマンドがありAレコードの登録が可能ですが、NECのIXシリーズにはこういったコマンドが存在しないため、検証環境やSOHO、ラボ環境などでDNSサーバが無い場合にAzure DNSを利用すると非常に便利です。

でもそれってたまたまローカルIPアドレス返してくれるだけで、RFC違反じゃないの？

私もそう思ったので調べてみたのですが、RFC 1537では定義されておらずRFC 1912でも禁止とは書かれていませんでした。

RFC違反ではなかったとしても何か問題起きないの？

はい。
早速問題が起きました。
UQ WiMAXに接続するとAzure DNSに登録されているローカルIPアドレスは返してくれませんでした。
恐らくUQ WiMAXの仕様で、DNSのレスポンスにローカルIPアドレスが入っていると返さない仕様なのだと思います。

そりゃインターネット上のDNSに問い合わせしてローカルIPアドレスが返ってきたらおかしくなりそうですよね？

そうなんですよ。
おかしくなる、というか、攻撃に利用されます。

え？どんな攻撃なの？

はい。
DNS Rebinding
という攻撃です。

DNS Rebindingって何？

1. 攻撃者がJavaScript(など)で一定時間に再読み込みを行うWebページを用意します
2. 被害者(一般ユーザー)が攻撃者のWebページにアクセスします
3. WebページのAレコードは元々グローバルIPアドレスを設定しており、TTLを1秒などの短い間隔にし、被害者が次にWebページを読み込む際にDNSサーバが返すAレコードをローカルIPアドレス(例えば192.168.0.1などルーター)にする
4. 攻撃者のJavaScriptで構成されたページは被害者のブラウザのキャッシュ内で動き続けるので、192.168.0.1で読み込みなおしたページ(192.168.0.1がルーターのログイン画面だった場合)にログインID、パスワードで総当たり攻撃を仕掛ける
5. ログインIDとパスワードを探り当てたらログインしルーターを乗っ取る

こういった攻撃手法をDNS Rebinding攻撃と言います。

え？何それマズいじゃないですか

はい。
マズいですね。
なので本当に存在するドメインをAzure DNSで保持し、クラスA、B、CのIPアドレスを返すようにすればAzure DNSを攻撃ツールの一部として利用することは可能かもしれません。
しかしこの本当に存在するドメインをAzure DNSで保持という部分が非常に難しいため、実際に攻撃ツールの一部としてAzure DNSが利用される可能性は低いと思います。

攻撃ツールとして利用が難しいにしても、なるべくそういうイレギュラー設定は行わないほうが良いんじゃないの？

はい。
私もそう思います。
ですのであくまで検証目的、非常に短い期間でのみの利用が良いのではないか？と考えています。

まとめ

1. パブリックのAzure DNSにクラスA、B、CのローカルIPアドレスを登録できる
2. DNSサーバが内部に無い場合の代替手段としてAzure DNSを利用するというアイデアは良いかもしれませんが、恒久対応ではなくあくまで一時しのぎとして利用する
3. クラスA、B、Cにしていた場合DNS Rebinding攻撃の踏み台に使われる可能性がある
4. Azure DNSに「本当に存在するが自身が所有者ではないドメイン」を含めようと思った場合に敷居が高い
5. Azure DNSにクラスA、B、Cのセグメントを作るときは検証、実験目的に絞り、設定している時間もなるべく短くする

本日はここまで。