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

アジェンダ

• ISCの概要

• BIND 9.8の機能

• BIND9のロードマップ

• ISCサービス

• 質疑応答

ISCとはどんな組織か

• Internet Systems Consortium, Inc. (ISC) は、

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

DNS Response Policy Zone

(DNS RPZ)

DNS Response Policy Zone (DNS RPZ)

• DNS RPZは、特定のDNSゾーン内に定義されるポリシ情報である

• ドメインの評価データの製作者と運用者を連携させ、リアルタイムのDNS応答を操作することを可能にする。

• DNS RPZは、 キャッシュDNSサーバをセキュリティ機器化する– アンチスパム、DNSBL(DNSブラックリスト)やRHSBL(Right Hand Side Block List)と類似の機能を付与

– 規模とスピードを高めた状態での提供が可能

DNSの通常の挙動Master/

Primary DNS

Slave/

Secondary

DNS

AXFR

TSIG

IXFR

TSIG

.org

isc.org

www.isc.org

キャッシュDNS www.isc.org は 149.20.64.42

www.isc.org のIPはなんだ？

isc.orgの管理はどのサーバ?

AXFR – フルゾーン転送

IXFR – 増分ゾーン転送

TSIG - Transaction SIGnature

AXFR/IXFRの保護のため署名処理

DNS　RPZMaster DNS

RPZ

AXFR

IXFR

.org

isc.org

www.isc.org

キャッシュDNS www.isc.org は 149.20.64.42

www.isc.org のIPはなんだ？

isc.orgの管理はどのサーバ?

キャシュDNSサーバ上のRPZ機能は、

数秒以内に

ゾーン転送を受けることを可能にする。.

セキュリティ企業

RPZ

DNS　RPZの動作

Master DNS

RPZ

AXFR

IXFR

キャッシュDNS

xyzbadness.comのIPはなんだ？

セキュリティ企業

RPZ

SPAMコンピューコンピューコンピューコンピュー

タタタタががががxyzbadness.com

をををを引引引引くくくく

xyzbadness.com評価評価評価評価がががが低低低低いいいい

ドメインドメインドメインドメインであることをであることをであることをであることを検知検知検知検知

考えられるDNS RPZの

利用シーン• URLに使用されるドメイン名を用いて、悪意のある

サイトをブロッキングやリダイレクトする

• ボッドで使われるC&Cサーバ（Command and Control Server）機能への接続をブロックする

• 感染の疑いがあるクライアントへ、囲い込みを通知する

• PTRの逆引きを使うサービス（IPレピュテーションはDNS RPZにマッピングすることが可能）

DNS RPZ & SURBL• SURBL RPZとは何か

– SURBLとは、DNS RPZを利用した高精度のアンチスパム、フィッシング、マルウェアのデータ一形態である。

• SURBL RPZを使うメリット

– 悪意があり危険なスパムやフィッシング、マルウェアサイトへの訪問からユーザを守るために使われる。このことで、IDの漏洩やフィッシング攻撃、マルウェアへの感染、スパムサイトに訪問することによる時間の浪費など防止が可能となる。これは、SURBLの高評価かつ複数のソースをもち、リアルタイム性がある情報により実現されている。

• SURBL RPZの利用方法

– SURBL RPZはBIND9の最新版のゾーン転送を使い利用することができる。SURBLにヒットした問い合わせへの回答をキャッシュDNSサーバによって、独自の応答を返すことができる。デフォルトの動作では、NXDOMAINを返し名前解決を拒否する。また例えば、危険なドメインが引かれた場合、ローカルの特定アドレスに誘導することも可能である。管理者の運用状況に応じて、応答の値を任意に変更することで他の挙動をとらせることもできる。SURBL RPZのデータは、差分ゾーン転送で入手することができる。

DNS RPZ のその他諸々

• DNSブラックリストの常連には事前通知を行った

方がよい。（前向きなフィードバック）

• 管理者は自信のRPZと、他のRPZを混合して管

理することができる。

• セキュリティベンダに対して新たな市場と分野を提供する

• 悪意の攻撃者に対して、DNSを使う限り、攻撃は

無駄ということを言えるまでになるのか？

DNS RPZにおけるISCの役割

• セキュリティツールとして新しく強力な武器であるDNS RPZに対して、ISCは3つの役割を担う– すべてのキャッシュDNSソフトベンダと共に、共通の

フォーマットで適応できようBINDを開発する

– ブラックリスト提供者になりうる団体との協力

– DNS RPZを適応していく運用者との協力

• ISCがブラックリストを提供することは絶対にない。ISCの役割は、セキュリティツールとしてのDNS RPZの設計・構築・適応を支援していくのみである

参考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/takingback-dns-0

• Google “taking back the dns”

• Draft Specification

• ftp://ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt

• BIND 9.8

BIND 9.8の新機能

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

DNS64

• DNS64は、ISP内でIPv6のみ保持している

ユーザのための変換機構である

• DNS64はNAT64と連動して動作する

• DNS64とNAT64は、IPv6のみ保持しているユーザや機器をIPv4のネットワークと疎

通させることができる

DNS64 (and NAT64)

• NAT64を介して、IPv4アドレスとマッピングするため、IPv6のプレフィックスが使われる

• このプレフィックスは特定のネットワークか、64:FF9B::/96が使われる

• NAT64ルータはIPv6ネットワークに対して、このプレフィックスをアドバタイズする

DNS64の例IPv4のみのサービスの場合

• ゾーンはAレコードのみが記載されている

• NAT64プレフィックスを使って、AレコードをAAAAレコードに変換する

• クライアントは、 AレコードとAAAAレコード

の両方を取得できる

DNS64の例IPv4/IPv6サービスの場合

• ゾーンはAレコードとAAAAレコードが記載

されている

• DNS64は何も動作しない

• クライアントは、 ゾーンに記載されているとおり、AレコードとAAAAレコードを取得で

きる

DNSSECアルゴリズムとしてGOSTをサポート

• GOSTはロシアで作成された公開鍵方式のアル

ゴリズムである– GOST R 34.10-2001 と GOST R 34.11-94

• RSAがいつも利用できるとは限らない

• GOSTはゾーンへの署名に利用できる(RSASHA1,RSASHA256などと同様の)DNSSEC

アルゴリズムである。

• ほとんどの場合、RSAを使ったほうがよい。。。

DNSSEC Root Key

• ルートDNSが署名された！！

• BINDにルートDNSの鍵が組み込まれてリ

リースされるようになっている

• RFC5011方式での鍵の更新に対応

組み込まれているルート鍵の使用方法

Options {

dnssec-validation auto;

};

GSSAPIとDLZ/LDAP

• Sambaとの連携機能

• BIND9がAcitve Directoryのように振舞う

• SambaはSMB/CIFSを実装したオープンソースであり、UNIXベースのホストをWindows

クライアントを管理するドメインコントローラとして動作させることができる。

GSSAPIの設定

• クライアントからの更新要求に依存して、っkeytabの中から自動的に最適なKerberos

鍵が選択される

• ほとんどのケースでは、Keytabの中には１

つの鍵を指定する

• 複数のWindowsドメインを管理可能　

DLZとDLZ ドライバ

• “dlopen”ドライバ– DLZは、BIND9で直接サポートされていないフォーマッ

トでゾーンデータを保存するための方法を提供する

– 多くのドライバが“contrib”ディレクトリに置かれている

– “dlopen”ドライバはBind9.8ではデフォルトでコンパイル済である。

– このことにより、他のドライバを動的にロードすることができる

• DLZドライバは書き込み可能（ダイナミックDNS

アップデート）

LDAP DLZドライバ

• BIND9とSambaの連携方法はSamba4のド

キュントを参照のこと

• 動的ロードが可能であることにより、各種ゾーンデータの生成にBIND9.8を柔軟に対

応させることができる

• 今のところ、設定は容易にはできない

スタブゾーン機能の改善

• “type stub”ゾーンは、いつも期待どおりに

動作するわけではなかった

• 新しく設けられた“type static-stub”ゾーンは

期待どおりに動作する

“type stub”

“type static-stub”

“type stub”

• NSレコードをキャッシュに保持するだけ

• キャッシュしているNSレコードを応答

• プライベートアドレスや、委任されていないドメインをリゾルバへの応答に追加することが可能

• リゾルバの管理者が既存のドメイン情報を上書きすることを許容する

“type static-stub”

• 指定のドメインに関する問い合わせを、特定のサーバにリダイレクトする

• キャッシュや応答データはそのまま

• プライベートアドレスや、委任されていないドメインをリゾルバへの応答に追加することが可能

• リゾルバの管理者が既存のドメイン情報を上書きすることを許容する

static-stubの使いどころ

• “type static-stub”は、通常のDNS検索の

ショーットカットといえる

• すべてのクエリを特定のサーバに向けたいが、そのリダイレクトの挙動をクライアントに意識させたくない場合に有効

• DNSSECのテスト環境に最適

DNSSECテスト環境その１

DNSSECテスト環境その２

動的ACL

• 外部プロセスが、ダイナミックアップデートのポリシを決定できるようにする機能であり、BIND9.8からデフォルトでコンパイルさ

れている

• ダイナミックアップデート機能でのみ有効

• 使用方法や設定については、“contrib”ディ

レクトリの使用例を参照のこと

Client Query Timeout

• デフォルトのタイムアウト値は30秒

– 30秒経過したら、クライアントはあきらめる設定

– しかし、多くのクライアントは4秒程しか待たない

– あるCPEルータではサーバあたり5秒待つ

• Bind9.8ではこの値を調整可能

• SERVFAIL応答を指定時間で返すことが可能

– クライアントはこのSERVFAIL応答を、クライアント側

のタイムアウトより前に受け取ることになる

Client Query Timeoutの推奨値

• 4秒から10秒の間での設定を推奨

• BIND9.8では、タイムアウトの発生とともに処理を停止する

• 追加でSERVFAIL応答が生成されるケースがある– 権威サーバからの応答自体が遅い、ネットワー

クの経路の遅延など

• チューニング前後でのモニタリングを推奨

RTT Banding のののの廃止廃止廃止廃止

• RTT Banding は、ある種のキャッシュポイズニング攻撃を2倍～4倍困難にすることができるセキュリティ技術である

• 一方、 RTT Banding は時に致命的になるような問い合わせの遅延を引き起こすこともある

• RTT Banding はローカルベースのロードバランスを無効にしてしまう

RTT Banding

RTT Bandingなし

使使使使われないわれないわれないわれない理由理由理由理由

• セキュリティ強化については、遅延を発生させない代替手法がでてきている

• 遅延は様々な面で重大な問題を引き起こす、特にブラウザのようなユーザドリブン型のアプリケーションでは顕著である。

• ISCはbanding機能がよくないと判断した

廃止された理由

• コンテンツプロバイダから廃止要望

• リゾルバ運用者からの廃止要望

• プロバイダおよびDNSユーザから、エンド

ユーザの利点の面からも廃止要望があがっていた

• Banding機能をもつ他プロダクトのdnsサー

バは一つだけだったから

期待された仕様変更

• BIND9の挙動は事前banding方式へ戻る

– 応答時間が一番短いサーバが選択される

– 選択されなかったサーバは定期的に試される

廃止までのタイムライム

• 9.8系では廃止され、有効化できない

• 9.4系ではbandingを使わない

• 9.6.4、9.7.4ではbandingの無効オプションが提供される予定。9.6.5と9.7.5はオプションはそのままだが、デフォルト設定はoff

サーバ選択機能

• BIND9におけるサーバ選択技術は完全で

はない

• 代替の選択手法がよい結果を生み出すという研究もある

サーバ選択機能

BIND9.8での改善事項

• 性能– Address Database(ADB)の拡張

• 信頼性

– 再帰問い合わせクライントのリストが重複により溢れるフローを修正

– “nsuupdate”コマンドの名前のcaseを保存

– ゾーン情報が正しいcaseと一緒にディスクに保存され

る

– 自動署名とダイナミックアップデートの一部を修正

BIND9のロードマップ

• BIND9.9

– DNSSEC処理の改善

– NXDOMAINのリダイレクト

– 起動時間およびメモリの使用の改善

– SERVFAILのキャッシュ

– 全応答のキャッシュ

• BIND9.10

– マルチマスタ機能

– 内部ヘルスモニタ機能

– 大規模サーバの設定