※2019年5月7日　ある程度改訂しました

最近、とあるDNSサーバのゾーン情報取れないかなーってコマンド叩いたら取れてしまって、おいおいおいおいおいっていうのをたまたま見つけてしまいました。
師匠に相談したらJPCERTに報告したら？とご助言をいただき、JPCERTに報告して数日後確認したら直ってたってことがありました。

余計な情報を公開する必要はないので、ちゃんと設定したほうがいいよ！という備忘録です。

DNSサーバ建てたことない方や、「うちの公開DNS大丈夫？」って不安な方などにお役立ちできれば。

#1.ゾーン転送の設定を明示的に設定する

BINDの設定ファイル(named.conf)でゾーン転送について明示的に設定していない場合、ゾーン転送の制限がつきません。
なので、明示的に設定する必要があるんですね！

###スレーブサーバがない場合

「ゾーン転送を許さない」と、明示的に設定します。

named.conf

allow-transfer { none; };

###スレーブサーバがある場合

「こいつにはゾーン転送を許す」と、明示的に設定します。

named.conf

allow-transfer { スレーブサーバのIPアドレス等; };

例として

named.conf

allow-transfer { 192.168.0.2; };

といった感じです。

#2.ゾーン転送の設定状況ってどうやって確認するの？

##※下記コマンドをむやみに叩くとお国によってはアウトだったりします。
あくまで構築後の検証用のコマンドと取っていただきたく。

私の場合、Linux上でdigを叩いています。
入ってない方は、まずdigを使えるようにします。
インストールのコマンド等はここでは割愛しますので、各自環境に合わせていただきたく。

インストール後、以下のコマンドを叩きます。

$ dig @DNSサーバのIPアドレス等 対象のドメイン axfr

具体的なコマンド例も含めて、ゾーン転送ができる状態とできない状態を見ていきましょう。
我が家の内部ネットワークにはusamin-planet.localというドメインの親になるDNSサーバがありますので、これを直接いじって試してみます。

###ゾーン転送が可能な状態な場合

実験台として、我が家の内部DNSサーバを使ってコマンドと結果を記載します。

我が自宅の内部DNS宛に明示的な設定をしない状態でゾーンを取りに行くと、こんな感じで結果が返ってきます。

haruka-minazuki@Usamin-Net ~ $ dig @192.168.0.200 usamin-planet.local axfr

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.168.0.200 usamin-planet.local axfr
; (1 server found)
;; global options: +cmd
usamin-planet.local.    150     IN      SOA     usamin-planet.local. kure-admiral.usamin-planet.local.usamin-planet.local. 2019032502 300 3600 600 150
以下略

ゾーン転送が不要なのにもかかわらず、上記のように取れてしまうとよろしくないです。
ゾーン転送？なにそれおいしいの？って方はゾーン転送を許さない設定をnamed.confに書いてください。

逆に、ゾーン転送を許可するべきであるスレーブサーバからマスターサーバ宛に実行して、この情報が取れないと機能しない状態と言えます。
その状態においても、スレーブサーバ以外から取れてしまうのは設定を見直したほうが良いです。

スレーブサーバでも明示的にゾーンの転送を拒否しないとゾーンデータが取れちゃいます。スレーブサーバ宛にも同じような確認をすることで、不用意なゾーン転送を確実に阻止できます。

###ゾーン転送が不可能な状態の場合

同じく我が自宅の内部DNS宛に、明示的にゾーン転送を許可しない設定をした場合は、以下のように返ってきます。

haruka-minazuki@Usamin-Net ~ $ dig @192.168.0.200 usamin-planet.local axfr

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.168.0.200 usamin-planet.local axfr
; (1 server found)
;; global options: +cmd
; Transfer failed.

ゾーン転送が拒否されている旨のメッセージが返ってきます。
ゾーン転送が不要な場合はこの応答で正常です。なにそれおいしいの？って方も基本的にこうなるように拒否するべきと思います。

逆にスレーブサーバ側でこのようなメッセージが出る場合は、転送の設定がうまくいっていない状態と言えます。
マスターサーバ側の設定を見直し、__スレーブサーバにゾーン転送ができること__を確認してください。

合わせて、スレーブサーバ以外のホストで同じコマンドを実行して__スレーブサーバ以外へのゾーン転送が拒否されていること__を確認してください。
スレーブサーバでも必要以上にゾーン転送を許可していないことを確認してくださいね。

#3.で、ゾーン転送の設定を明示的にしないと何が悪いのさ

実は自分も師匠の教えで__この設定についてたまたま知っていたから知ってた__がとりあえずの入り口でした。

普通にネットサーフィンをしている時もdigコマンド同様、ドメインからIPアドレスを解決するためにDNSサーバへ問い合わせてホストのIPを取得しているので、問題ないんじゃね？と疑問に思ったことがあります。

が、よくよく考えるとこれを利用してあんなことやこんなことができてしまうので、セキュリティを考慮して必要以上の情報を公開するべきではないと考えています。

ビクッとしたあなたは、下記のコマンドを例にして設定を見直すことをお勧めします。

cat /etc/named.conf

#4.じゃあ、そんなDNSサーバを偶然見つけたらどうするの？

たまたま見つけた場合、JPCERTに報告することで教えてあげることができます。

__JPCERT/CCに依頼する＞インシデント対応依頼＞Webフォームでのインシデント報告＞インシデントの報告__と進むと報告フォームにたどり着きます。

お名前とメールアドレスは必須入力となっていますが、必須以外の項目を入力しても相手との直接のやり取りも一切ありませんでしたので、相手に名前が知られたり等のリスクはないと考えていいと思います。

情報等に実行したコマンド等を入力してあげると、JPCERTの中の人に親切じゃないかな？と思います。

登録フォーム入力後、受付メールが届きますがその後も特にやりとりはありませんでした。

#5.報告しても直ってないんだけど！教えてあげたら損した！(激おこ)

JPCERTの受付メールに以下のような内容のメールがありました。

とりあえず警告するけど、それ以降は通知を受け取った側の対応次第なのです。
という旨の内容でした。

悪用するような脳みそがない自分ですので、こうできるけどアカン！っていうような方々はJPCERTをご活用いただき、一緒に安全性を高めることができればと、幻想を抱いていたりします。

#6.最後に

DNSの設定については、明示的な設定をしなくても、一見意図した通りに動いてしまいますのでご覧になった方の参考になれば幸いです。

セキュリティインシデントを発見したけど、どうしたらいいんだろう？という方は、ぜひJPCERTに報告してください。
個人的な意見ですが、インシデントとして報告しないより、きちんとインシデントとして報告して、きちんとした機関から通知をしてもらうことはとっても大事だと考えています。

DNSについては自分もまだまだ未熟な部分はありますが、ナレッジを共有してより安全なインフラを構築したいですね。