Japanese translation （http://www.isc.org/files/BIND98_web_event-2011-03-02.pdf）

1. BIND 9.8
Feature Overview
Michael Graff, Barry Greene,
Larissa Shapiro
http://www.isc.org/files/BIND98_we
b_event-2011-03-02.pdf
を訳してみた
訳：qt.takada

2. アジェンダ
• ISCの概要
• BIND 9.8の機能
• BIND9のロードマップ
• ISCサービス
• 質疑応答

3. ISCとはどんな組織か
• Internet Systems Consortium, Inc. (ISC) は、
非営利の公益増進法人であり、自立シス
テムであるインターネットへの普遍的な接
続基盤や、主要で高品質なソフトウェア、
プロトコルの開発・保守、運用を通して、イ
ンターネットへの参加者の自治を支援する
組織

4. DNS Response Policy Zone
(DNS RPZ)

5. DNS Response Policy Zone
(DNS RPZ)
• DNS RPZは、特定のDNSゾーン内に定義される
ポリシ情報である
• ドメインの評価データの製作者と運用者を連携さ
せ、リアルタイムのDNS応答を操作することを可
能にする。
• DNS RPZは、 キャッシュDNSサーバをセキュリティ
機器化する
– アンチスパム、DNSBL(DNSブラックリスト)や
RHSBL(Right Hand Side Block List)と類似の機能を
付与
– 規模とスピードを高めた状態での提供が可能

6. DNSの通常の挙動
Master/
Primary DNS .org
isc.orgの管理はどのサーバ?
AXFR
IXFR
TSIG
TSIG
isc.org
Slave/ www.isc.org
Secondary キャッシュ
DNS DNS www.isc.org は 149.20.64.42
AXFR – フルゾーン転送
IXFR – 増分ゾーン転送 www.isc.org のIPはなんだ？
TSIG - Transaction SIGnature
AXFR/IXFRの保護のため署名処理

7. セキュリティ企業 DNS RPZ
Master DNS
RPZ .org
isc.orgの管理はどのサーバ?
AXFR
isc.org
IXFR
RPZ www.isc.org
キャッシュ
DNS www.isc.org は 149.20.64.42
キャシュDNSサーバ上のRPZ機能は、
数秒以内に www.isc.org のIPはなんだ？
ゾーン転送を受けることを可能にする。.

8. DNS RPZの動作
セキュリティ企業
Master DNS 評価が
評価が低い
RPZ ドメインであることを
であることを検知
ドメインであることを検知 xyzbadness.com
AXFR
IXFR
RPZ
キャッシュ
DNS
xyzbadness.comのIPはなんだ？ コンピュー
SPAMコンピュー
タが
xyzbadness.com
を引く

9. 考えられるDNS RPZの
利用シーン
• URLに使用されるドメイン名を用いて、悪意のある
サイトをブロッキングやリダイレクトする
• ボッドで使われるC&Cサーバ（Command and
Control Server）機能への接続をブロックする
• 感染の疑いがあるクライアントへ、囲い込みを通知
する
• PTRの逆引きを使うサービス（IPレピュテーションは
DNS RPZにマッピングすることが可能）

10. DNS RPZ & SURBL
• SURBL RPZとは何か
– SURBLとは、DNS RPZを利用した高精度のアンチスパム、フィッシング、
マルウェアのデータ一形態である。
• SURBL RPZを使うメリット
– 悪意があり危険なスパムやフィッシング、マルウェアサイトへの訪問から
ユーザを守るために使われる。このことで、IDの漏洩やフィッシング攻撃、
マルウェアへの感染、スパムサイトに訪問することによる時間の浪費な
ど防止が可能となる。これは、SURBLの高評価かつ複数のソースをもち、
リアルタイム性がある情報により実現されている。
• SURBL RPZの利用方法
– SURBL RPZはBIND9の最新版のゾーン転送を使い利用することができ
る。SURBLにヒットした問い合わせへの回答をキャッシュDNSサーバに
よって、独自の応答を返すことができる。デフォルトの動作では、
NXDOMAINを返し名前解決を拒否する。また例えば、危険なドメインが
引かれた場合、ローカルの特定アドレスに誘導することも可能である。
管理者の運用状況に応じて、応答の値を任意に変更することで他の挙
動をとらせることもできる。SURBL RPZのデータは、差分ゾーン転送で
入手することができる。

11. DNS RPZ のその他諸々
• DNSブラックリストの常連には事前通知を行った
方がよい。（前向きなフィードバック）
• 管理者は自信のRPZと、他のRPZを混合して管
理することができる。
• セキュリティベンダに対して新たな市場と分野を
提供する
• 悪意の攻撃者に対して、DNSを使う限り、攻撃は
無駄ということを言えるまでになるのか？

12. DNS RPZにおけるISCの役割
• セキュリティツールとして新しく強力な武器である
DNS RPZに対して、ISCは3つの役割を担う
– すべてのキャッシュDNSソフトベンダと共に、共通の
フォーマットで適応できようBINDを開発する
– ブラックリスト提供者になりうる団体との協力
– DNS RPZを適応していく運用者との協力
• ISCがブラックリストを提供することは絶対にない。
ISCの役割は、セキュリティツールとしてのDNS
RPZの設計・構築・適応を支援していくのみであ
る

13. 参考Link
• Discussion List
• https://lists.isc.org/mailman/listinfo/dnsrpz-interest
• Taking back the DNS, Paul Vixie, 29th July 2010
•http://www.isc.org/community/blog/201007/takingb
ack-dns-0
• Google “taking back the dns”
• Draft Specification
• ftp://ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt
• BIND 9.8

14. BIND 9.8の新機能

15. BIND 9.8の新機能
• DNS64
• RPZ
• GOST
• DNSSEC Root Key
• GSSAPI and LDAP
• Improved Stub Zones
• Dynamic ACLs
• Client Query Timeout
• RTT Banding Removal
• Defects Repaired

16. DNS64
• DNS64は、ISP内でIPv6のみ保持している
ユーザのための変換機構である
• DNS64はNAT64と連動して動作する
• DNS64とNAT64は、IPv6のみ保持してい
るユーザや機器をIPv4のネットワークと疎
通させることができる

17. DNS64 (and NAT64)
• NAT64を介して、IPv4アドレスとマッピングするた
め、IPv6のプレフィックスが使われる
• このプレフィックスは特定のネットワークか、
64:FF9B::/96が使われる
• NAT64ルータはIPv6ネットワークに対して、この
プレフィックスをアドバタイズする

18. DNS64の例
IPv4のみのサービスの場合
• ゾーンはAレコードのみが記載されている
• NAT64プレフィックスを使って、Aレコードを
AAAAレコードに変換する
• クライアントは、 AレコードとAAAAレコード
の両方を取得できる

19. DNS64の例
IPv4/IPv6サービスの場合
• ゾーンはAレコードとAAAAレコードが記載
されている
• DNS64は何も動作しない
• クライアントは、 ゾーンに記載されていると
おり、AレコードとAAAAレコードを取得で
きる

20. DNSSECアルゴリズムとして
GOSTをサポート
• GOSTはロシアで作成された公開鍵方式のアル
ゴリズムである
– GOST R 34.10-2001 と GOST R 34.11-94
• RSAがいつも利用できるとは限らない
• GOSTはゾーンへの署名に利用できる
(RSASHA1,RSASHA256などと同様の)DNSSEC
アルゴリズムである。
• ほとんどの場合、RSAを使ったほうがよい。。。

21. DNSSEC Root Key
• ルートDNSが署名された！！
• BINDにルートDNSの鍵が組み込まれてリ
リースされるようになっている
• RFC5011方式での鍵の更新に対応

22. 組み込まれている
ルート鍵の使用方法
Options {
dnssec-validation auto;
};

23. GSSAPIとDLZ/LDAP
• Sambaとの連携機能
• BIND9がAcitve Directoryのように振舞う
• SambaはSMB/CIFSを実装したオープンソー
スであり、UNIXベースのホストをWindows
クライアントを管理するドメインコントローラ
として動作させることができる。

24. GSSAPIの設定
• クライアントからの更新要求に依存して、っ
keytabの中から自動的に最適なKerberos
鍵が選択される
• ほとんどのケースでは、Keytabの中には１
つの鍵を指定する
• 複数のWindowsドメインを管理可能

25. DLZとDLZ ドライバ
• “dlopen”ドライバ
– DLZは、BIND9で直接サポートされていないフォーマッ
トでゾーンデータを保存するための方法を提供する
– 多くのドライバが“contrib”ディレクトリに置かれている
– “dlopen”ドライバはBind9.8ではデフォルトでコンパイ
ル済である。
– このことにより、他のドライバを動的にロードすること
ができる
• DLZドライバは書き込み可能（ダイナミックDNS
アップデート）

26. LDAP DLZドライバ
• BIND9とSambaの連携方法はSamba4のド
キュントを参照のこと
• 動的ロードが可能であることにより、各種
ゾーンデータの生成にBIND9.8を柔軟に対
応させることができる
• 今のところ、設定は容易にはできない

27. スタブゾーン機能の改善
• “type stub”ゾーンは、いつも期待どおりに
動作するわけではなかった
• 新しく設けられた“type static-stub”ゾーンは
期待どおりに動作する

28. “type stub”

29. “type static-stub”

30. “type stub”
• NSレコードをキャッシュに保持するだけ
• キャッシュしているNSレコードを応答
• プライベートアドレスや、委任されていない
ドメインをリゾルバへの応答に追加するこ
とが可能
• リゾルバの管理者が既存のドメイン情報を
上書きすることを許容する

31. “type static-stub”
• 指定のドメインに関する問い合わせを、特定のサー
バにリダイレクトする
• キャッシュや応答データはそのまま
• プライベートアドレスや、委任されていないドメイ
ンをリゾルバへの応答に追加することが可能
• リゾルバの管理者が既存のドメイン情報を上書
きすることを許容する

32. static-stubの使いどころ
• “type static-stub”は、通常のDNS検索の
ショーットカットといえる
• すべてのクエリを特定のサーバに向けた
いが、そのリダイレクトの挙動をクライアン
トに意識させたくない場合に有効
• DNSSECのテスト環境に最適

33. DNSSECテスト環境その１

34. DNSSECテスト環境その２

35. 動的ACL
• 外部プロセスが、ダイナミックアップデート
のポリシを決定できるようにする機能であ
り、BIND9.8からデフォルトでコンパイルさ
れている
• ダイナミックアップデート機能でのみ有効
• 使用方法や設定については、“contrib”ディ
レクトリの使用例を参照のこと

36. Client Query Timeout
• デフォルトのタイムアウト値は30秒
– 30秒経過したら、クライアントはあきらめる設定
– しかし、多くのクライアントは4秒程しか待たない
– あるCPEルータではサーバあたり5秒待つ
• Bind9.8ではこの値を調整可能
• SERVFAIL応答を指定時間で返すことが可能
– クライアントはこのSERVFAIL応答を、クライアント側
のタイムアウトより前に受け取ることになる

37. Client Query Timeoutの推奨値
• 4秒から10秒の間での設定を推奨
• BIND9.8では、タイムアウトの発生とともに
処理を停止する
• 追加でSERVFAIL応答が生成されるケー
スがある
– 権威サーバからの応答自体が遅い、ネットワー
クの経路の遅延など
• チューニング前後でのモニタリングを推奨

38. RTT Banding の廃止
• RTT Banding は、ある種のキャッシュポイ
ズニング攻撃を2倍～4倍困難にすること
ができるセキュリティ技術である
• 一方、 RTT Banding は時に致命的になる
ような問い合わせの遅延を引き起こすこと
もある
• RTT Banding はローカルベースのロードバ
ランスを無効にしてしまう

39. RTT Banding

40. RTT Bandingなし

41. 使われない理由
われない理由
• セキュリティ強化については、遅延を発生
させない代替手法がでてきている
• 遅延は様々な面で重大な問題を引き起こ
す、特にブラウザのようなユーザドリブン型
のアプリケーションでは顕著である。
• ISCはbanding機能がよくないと判断した

42. 廃止された理由
• コンテンツプロバイダから廃止要望
• リゾルバ運用者からの廃止要望
• プロバイダおよびDNSユーザから、エンド
ユーザの利点の面からも廃止要望があがっ
ていた
• Banding機能をもつ他プロダクトのdnsサー
バは一つだけだったから

43. 期待された仕様変更
• BIND9の挙動は事前banding方式へ戻る
– 応答時間が一番短いサーバが選択される
– 選択されなかったサーバは定期的に試される

44. 廃止までのタイムライム
• 9.8系では廃止され、有効化できない
• 9.4系ではbandingを使わない
• 9.6.4、9.7.4ではbandingの無効オプション
が提供される予定。9.6.5と9.7.5はオプショ
ンはそのままだが、デフォルト設定はoff

45. サーバ選択機能
• BIND9におけるサーバ選択技術は完全で
はない
• 代替の選択手法がよい結果を生み出すと
いう研究もある

46. サーバ選択機能

47. BIND9.8での改善事項
• 性能
– Address Database(ADB)の拡張
• 信頼性
– 再帰問い合わせクライントのリストが重複により溢れ
るフローを修正
– “nsuupdate”コマンドの名前のcaseを保存
– ゾーン情報が正しいcaseと一緒にディスクに保存され
る
– 自動署名とダイナミックアップデートの一部を修正

48. BIND9のロードマップ
• BIND9.9
– DNSSEC処理の改善
– NXDOMAINのリダイレクト
– 起動時間およびメモリの使用の改善
– SERVFAILのキャッシュ
– 全応答のキャッシュ
• BIND9.10
– マルチマスタ機能
– 内部ヘルスモニタ機能
– 大規模サーバの設定