Bind 9.8 feature overview
1 like2,242 views
Japanese translation （http://www.isc.org/files/BIND98_web_event-2011-03-02.pdf）
Bind 9.8 feature overview
- 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”
- 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 – マルチマスタ機能 – 内部ヘルスモニタ機能 – 大規模サーバの設定