Bind 9.8 feature overview

4,448 views

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
4,448
On SlideShare
0
From Embeds
0
Number of Embeds
916
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Bind 9.8 feature overview

  1. 1. BIND 9.8 Feature OverviewMichael Graff, Barry Greene, Larissa Shapiro http://www.isc.org/files/BIND98_we b_event-2011-03-02.pdf を訳してみた 訳:qt.takada
  2. 2. アジェンダ• ISCの概要• BIND 9.8の機能• BIND9のロードマップ• ISCサービス• 質疑応答
  3. 3. ISCとはどんな組織か• Internet Systems Consortium, Inc. (ISC) は、 非営利の公益増進法人であり、自立シス テムであるインターネットへの普遍的な接 続基盤や、主要で高品質なソフトウェア、 プロトコルの開発・保守、運用を通して、イ ンターネットへの参加者の自治を支援する 組織
  4. 4. DNS Response Policy Zone (DNS RPZ)
  5. 5. DNS Response Policy Zone (DNS RPZ)• DNS RPZは、特定のDNSゾーン内に定義される ポリシ情報である• ドメインの評価データの製作者と運用者を連携さ せ、リアルタイムのDNS応答を操作することを可 能にする。• DNS RPZは、 キャッシュDNSサーバをセキュリティ 機器化する – アンチスパム、DNSBL(DNSブラックリスト)や RHSBL(Right Hand Side Block List)と類似の機能を 付与 – 規模とスピードを高めた状態での提供が可能
  6. 6. DNSの通常の挙動 Master/ Primary DNS .org isc.orgの管理はどのサーバ?AXFRIXFR TSIGTSIG isc.org Slave/ www.isc.org Secondary キャッシュ DNS DNS www.isc.org は 149.20.64.42AXFR – フルゾーン転送IXFR – 増分ゾーン転送 www.isc.org のIPはなんだ?TSIG - Transaction SIGnatureAXFR/IXFRの保護のため署名処理
  7. 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. 8. DNS RPZの動作セキュリティ企業 Master DNS 評価が 評価が低い RPZ ドメインであることを であることを検知 ドメインであることを検知 xyzbadness.com AXFR IXFR RPZ キャッシュ DNS xyzbadness.comのIPはなんだ? コンピュー SPAMコンピュー タが xyzbadness.com を引く
  9. 9. 考えられるDNS RPZの 利用シーン• URLに使用されるドメイン名を用いて、悪意のある サイトをブロッキングやリダイレクトする• ボッドで使われるC&Cサーバ(Command and Control Server)機能への接続をブロックする• 感染の疑いがあるクライアントへ、囲い込みを通知 する• PTRの逆引きを使うサービス(IPレピュテーションは DNS RPZにマッピングすることが可能)
  10. 10. DNS RPZ & SURBL• SURBL RPZとは何か – SURBLとは、DNS RPZを利用した高精度のアンチスパム、フィッシング、 マルウェアのデータ一形態である。• SURBL RPZを使うメリット – 悪意があり危険なスパムやフィッシング、マルウェアサイトへの訪問から ユーザを守るために使われる。このことで、IDの漏洩やフィッシング攻撃、 マルウェアへの感染、スパムサイトに訪問することによる時間の浪費な ど防止が可能となる。これは、SURBLの高評価かつ複数のソースをもち、 リアルタイム性がある情報により実現されている。• SURBL RPZの利用方法 – SURBL RPZはBIND9の最新版のゾーン転送を使い利用することができ る。SURBLにヒットした問い合わせへの回答をキャッシュDNSサーバに よって、独自の応答を返すことができる。デフォルトの動作では、 NXDOMAINを返し名前解決を拒否する。また例えば、危険なドメインが 引かれた場合、ローカルの特定アドレスに誘導することも可能である。 管理者の運用状況に応じて、応答の値を任意に変更することで他の挙 動をとらせることもできる。SURBL RPZのデータは、差分ゾーン転送で 入手することができる。
  11. 11. DNS RPZ のその他諸々• DNSブラックリストの常連には事前通知を行った 方がよい。(前向きなフィードバック)• 管理者は自信のRPZと、他のRPZを混合して管 理することができる。• セキュリティベンダに対して新たな市場と分野を 提供する• 悪意の攻撃者に対して、DNSを使う限り、攻撃は 無駄ということを言えるまでになるのか?
  12. 12. DNS RPZにおけるISCの役割• セキュリティツールとして新しく強力な武器である DNS RPZに対して、ISCは3つの役割を担う – すべてのキャッシュDNSソフトベンダと共に、共通の フォーマットで適応できようBINDを開発する – ブラックリスト提供者になりうる団体との協力 – DNS RPZを適応していく運用者との協力• ISCがブラックリストを提供することは絶対にない。 ISCの役割は、セキュリティツールとしてのDNS RPZの設計・構築・適応を支援していくのみであ る
  13. 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. 14. BIND 9.8の新機能
  15. 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. 16. DNS64• DNS64は、ISP内でIPv6のみ保持している ユーザのための変換機構である• DNS64はNAT64と連動して動作する• DNS64とNAT64は、IPv6のみ保持してい るユーザや機器をIPv4のネットワークと疎 通させることができる
  17. 17. DNS64 (and NAT64)• NAT64を介して、IPv4アドレスとマッピングするた め、IPv6のプレフィックスが使われる• このプレフィックスは特定のネットワークか、 64:FF9B::/96が使われる• NAT64ルータはIPv6ネットワークに対して、この プレフィックスをアドバタイズする
  18. 18. DNS64の例 IPv4のみのサービスの場合• ゾーンはAレコードのみが記載されている• NAT64プレフィックスを使って、Aレコードを AAAAレコードに変換する• クライアントは、 AレコードとAAAAレコード の両方を取得できる
  19. 19. DNS64の例 IPv4/IPv6サービスの場合• ゾーンはAレコードとAAAAレコードが記載 されている• DNS64は何も動作しない• クライアントは、 ゾーンに記載されていると おり、AレコードとAAAAレコードを取得で きる
  20. 20. DNSSECアルゴリズムとして GOSTをサポート• GOSTはロシアで作成された公開鍵方式のアル ゴリズムである – GOST R 34.10-2001 と GOST R 34.11-94• RSAがいつも利用できるとは限らない• GOSTはゾーンへの署名に利用できる (RSASHA1,RSASHA256などと同様の)DNSSEC アルゴリズムである。• ほとんどの場合、RSAを使ったほうがよい。。。
  21. 21. DNSSEC Root Key• ルートDNSが署名された!!• BINDにルートDNSの鍵が組み込まれてリ リースされるようになっている• RFC5011方式での鍵の更新に対応
  22. 22. 組み込まれている ルート鍵の使用方法Options { dnssec-validation auto;};
  23. 23. GSSAPIとDLZ/LDAP• Sambaとの連携機能• BIND9がAcitve Directoryのように振舞う• SambaはSMB/CIFSを実装したオープンソー スであり、UNIXベースのホストをWindows クライアントを管理するドメインコントローラ として動作させることができる。
  24. 24. GSSAPIの設定• クライアントからの更新要求に依存して、っ keytabの中から自動的に最適なKerberos 鍵が選択される• ほとんどのケースでは、Keytabの中には1 つの鍵を指定する• 複数のWindowsドメインを管理可能 
  25. 25. DLZとDLZ ドライバ• “dlopen”ドライバ – DLZは、BIND9で直接サポートされていないフォーマッ トでゾーンデータを保存するための方法を提供する – 多くのドライバが“contrib”ディレクトリに置かれている – “dlopen”ドライバはBind9.8ではデフォルトでコンパイ ル済である。 – このことにより、他のドライバを動的にロードすること ができる• DLZドライバは書き込み可能(ダイナミックDNS アップデート)
  26. 26. LDAP DLZドライバ• BIND9とSambaの連携方法はSamba4のド キュントを参照のこと• 動的ロードが可能であることにより、各種 ゾーンデータの生成にBIND9.8を柔軟に対 応させることができる• 今のところ、設定は容易にはできない
  27. 27. スタブゾーン機能の改善• “type stub”ゾーンは、いつも期待どおりに 動作するわけではなかった• 新しく設けられた“type static-stub”ゾーンは 期待どおりに動作する
  28. 28. “type stub”
  29. 29. “type static-stub”
  30. 30. “type stub”• NSレコードをキャッシュに保持するだけ• キャッシュしているNSレコードを応答• プライベートアドレスや、委任されていない ドメインをリゾルバへの応答に追加するこ とが可能• リゾルバの管理者が既存のドメイン情報を 上書きすることを許容する
  31. 31. “type static-stub”• 指定のドメインに関する問い合わせを、特定のサー バにリダイレクトする• キャッシュや応答データはそのまま• プライベートアドレスや、委任されていないドメイ ンをリゾルバへの応答に追加することが可能• リゾルバの管理者が既存のドメイン情報を上書 きすることを許容する
  32. 32. static-stubの使いどころ• “type static-stub”は、通常のDNS検索の ショーットカットといえる• すべてのクエリを特定のサーバに向けた いが、そのリダイレクトの挙動をクライアン トに意識させたくない場合に有効• DNSSECのテスト環境に最適
  33. 33. DNSSECテスト環境その1
  34. 34. DNSSECテスト環境その2
  35. 35. 動的ACL• 外部プロセスが、ダイナミックアップデート のポリシを決定できるようにする機能であ り、BIND9.8からデフォルトでコンパイルさ れている• ダイナミックアップデート機能でのみ有効• 使用方法や設定については、“contrib”ディ レクトリの使用例を参照のこと
  36. 36. Client Query Timeout• デフォルトのタイムアウト値は30秒 – 30秒経過したら、クライアントはあきらめる設定 – しかし、多くのクライアントは4秒程しか待たない – あるCPEルータではサーバあたり5秒待つ• Bind9.8ではこの値を調整可能• SERVFAIL応答を指定時間で返すことが可能 – クライアントはこのSERVFAIL応答を、クライアント側 のタイムアウトより前に受け取ることになる
  37. 37. Client Query Timeoutの推奨値• 4秒から10秒の間での設定を推奨• BIND9.8では、タイムアウトの発生とともに 処理を停止する• 追加でSERVFAIL応答が生成されるケー スがある – 権威サーバからの応答自体が遅い、ネットワー クの経路の遅延など• チューニング前後でのモニタリングを推奨
  38. 38. RTT Banding の廃止• RTT Banding は、ある種のキャッシュポイ ズニング攻撃を2倍~4倍困難にすること ができるセキュリティ技術である• 一方、 RTT Banding は時に致命的になる ような問い合わせの遅延を引き起こすこと もある• RTT Banding はローカルベースのロードバ ランスを無効にしてしまう
  39. 39. RTT Banding
  40. 40. RTT Bandingなし
  41. 41. 使われない理由 われない理由• セキュリティ強化については、遅延を発生 させない代替手法がでてきている• 遅延は様々な面で重大な問題を引き起こ す、特にブラウザのようなユーザドリブン型 のアプリケーションでは顕著である。• ISCはbanding機能がよくないと判断した
  42. 42. 廃止された理由• コンテンツプロバイダから廃止要望• リゾルバ運用者からの廃止要望• プロバイダおよびDNSユーザから、エンド ユーザの利点の面からも廃止要望があがっ ていた• Banding機能をもつ他プロダクトのdnsサー バは一つだけだったから
  43. 43. 期待された仕様変更• BIND9の挙動は事前banding方式へ戻る – 応答時間が一番短いサーバが選択される – 選択されなかったサーバは定期的に試される
  44. 44. 廃止までのタイムライム• 9.8系では廃止され、有効化できない• 9.4系ではbandingを使わない• 9.6.4、9.7.4ではbandingの無効オプション が提供される予定。9.6.5と9.7.5はオプショ ンはそのままだが、デフォルト設定はoff
  45. 45. サーバ選択機能• BIND9におけるサーバ選択技術は完全で はない• 代替の選択手法がよい結果を生み出すと いう研究もある
  46. 46. サーバ選択機能
  47. 47. BIND9.8での改善事項• 性能 – Address Database(ADB)の拡張• 信頼性 – 再帰問い合わせクライントのリストが重複により溢れ るフローを修正 – “nsuupdate”コマンドの名前のcaseを保存 – ゾーン情報が正しいcaseと一緒にディスクに保存され る – 自動署名とダイナミックアップデートの一部を修正
  48. 48. BIND9のロードマップ• BIND9.9 – DNSSEC処理の改善 – NXDOMAINのリダイレクト – 起動時間およびメモリの使用の改善 – SERVFAILのキャッシュ – 全応答のキャッシュ• BIND9.10 – マルチマスタ機能 – 内部ヘルスモニタ機能 – 大規模サーバの設定

×