DNSの再帰問い合わせ
■ DNS の再帰的な問合せを使った DDoS 攻撃の対策について
日本レジストリサービス(JPRS)からDNS関連技術情報としてDNSの再帰的な問い合わせに関する注意喚起がなされた。これは非常に困った問題だ。私は仕事でセキュリティ検査サービスを行っており、これまで多数の企業の検査に携わってきた。検査対象にはもちろんDNSサーバも含まれることが多いのだが、検査をした「ほとんど全て」のDNSサーバで外部からの再帰的な問い合わせを有効にしている。
Luis Grangeia氏によって2004年2月に行われたDNS Cache Snoopingの問題についての調査報告書では、世界中の約20万台のDNSサーバのうち約半分が RecursiveとNon-Recursiveどちらの問い合わせにも応答する"Open DNS Cache"サーバだったらしい。多分今でも状況はあまり変わってないのだろう。なぜこんなことになっているのか。一番大きな理由は、DNSの実装として最も広く普及しているBINDがデフォルトでコンテンツサーバ機能とキャッシュサーバ機能を兼用でき、しかも明示的にアクセス制御の設定を行わないと全ての問い合わせを受け付ける設定になっているからだと思われる。つまり管理者がきちんと設定してこれらの機能を分離しない限り兼用型のサーバになってしまい、その結果として再帰と非再帰の両方の問い合わせに答えることになる。
JPRSから推奨されている対策をばっさり要約するとこういうことになる。
- コンテンツサーバとキャッシュサーバはなるべく分離すること
- これらを兼用するなら（しない場合でも）アクセス制御をきちんと設定すること
まあ分離できるならそれが一番だが、兼用する場合でも再帰問い合わせを許可するネットワークをちゃんと制限しましょうね、ということ。ちなみに djbdnsはコンテンツサーバとキャッシュサーバの実装がもともと別になっており、アクセス制御もデフォルト拒否になっているので、BINDよりはかなり安全といえる。（もっともdjbdnsは使ったことがないので、その他の点についてはよく知らない。）
ちなみにDNSサーバが再帰的な問い合わせに応答するかどうかは簡単に調べられる。それには digなどのDNS Query Toolを利用する。例えば調べたいDNSサーバが a.example.jpだとした場合、以下のようにして適当に問い合わせてみればいい。
（例) dig @a.example.jp www.example.com
もし再帰的問い合わせが有効なら、こんな感じの結果が得られるはずだ。4行目の"flags"のところに"ra"と表示されていれば、再帰問い合わせが有効(recursion available)になっている。
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 421
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2;; QUESTION SECTION:
;www.example.com. IN A;; ANSWER SECTION:
www.example.com. 172800 IN A 192.0.34.166;; AUTHORITY SECTION:
example.com. 21600 IN NS a.iana-servers.net.
example.com. 21600 IN NS b.iana-servers.net.;; ADDITIONAL SECTION:
a.iana-servers.net. 21600 IN A 192.0.34.43
b.iana-servers.net. 21600 IN A 193.0.0.236
