ネットワークワーキンググループ R. Arends Request for Comments: 4033 Telematica Instituut 廃止(Obsoletes): 2535, 3008, 3090, 3445, 3655, 3658, R. Austein 3755, 3757, 3845 ISC 更新(Updates): 1034, 1035, 2136, 2181, 2308, 3225, M. Larson 3007, 3597, 3226 VeriSign 分類: 標準化過程(Standards Track) D. Massey Colorado State University S. Rose NIST 2005年3月 DNSセキュリティ拡張(DNSSEC)の紹介とその要件 本文書の位置づけ 本文書はインターネットコミュニティのためにインターネット標準化過程に あるプロトコルを規定し、改善に向けた議論と提案を求めるものである。 このプロトコルの標準化の状況については"Internet Official Protocol Standards"(STD 1)の最新版を参照のこと。本文書の配布は制限されない。 著作権表示 Copyright (C) The Internet Society (2005). 要旨 DNSセキュリティ拡張(DNSSEC)は、データの出自の認証機能とデータの完全性 保護機能をDNSに追加するものである。本文書はこれらの拡張について紹介し、 その機能と制限について記述する。本文書はまた、DNSSECがどのような サービスを提供し、どのようなサービスは提供しないのかについても 論ずる。最後にDNSSECについて記述している様々な文書の関係を説明する。 Arends, et al. Standards Track [Page 1] RFC 4033 DNS Security Introduction and Requirements March 2005 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 重要なDNSSEC用語の定義 . . . . . . . . . . . . . . . . . . . 3 3. DNSSECが提供するサービス . . . . . . . . . . . . . . . . . . 7 3.1. データ生成元の認証とデータの完全性保護 . . . . . . . . 7 3.2. 名前およびタイプの不在証明 . . . . . . . . . . . . . . 9 4. DNSSECが提供しないサービス . . . . . . . . . . . . . . . . . 9 5. DNSSEC文書群の対象範囲とラストホップ問題(Last Hop Issues). . 9 6. リゾルバに関する考慮点 . . . . . . . . . . . . . . . . . . . 10 7. スタブリゾルバに関する考慮点 . . . . . . . . . . . . . . . . 11 8. ゾーンに関する考慮点 . . . . . . . . . . . . . . . . . . . . 12 8.1. TTL値とRRSIGの有効期限との関係 . . . . . . . . . . . . 13 8.2. ゾーンで新たに発生する時間依存の問題 . . . . . . . . . 13 9. ネームサーバに関する考慮点 . . . . . . . . . . . . . . . . . 13 10. DNSSECの関連文書 . . . . . . . . . . . . . . . . . . . . . . 14 11. IANAに関する考慮点 . . . . . . . . . . . . . . . . . . . . . 15 12. セキュリティに関する考慮点 . . . . . . . . . . . . . . . . . 15 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 14.1. Normative References . . . . . . . . . . . . . . . . . 17 14.2. Informative References . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 21 1. はじめに 本文書はDNSセキュリティ拡張(DNSSEC)を紹介する。本文書と2つの関連文書 ([RFC4034]と[RFC4035])は、RFC 2535[RFC2535]とそれに先行する取り組みで 定義されたセキュリティ拡張を更新し、明確にすると同時により洗練するもの である。DNSSECは、幾つかの新しいリソースレコードタイプと既存の DNSプロトコル([RFC1035])の修正とで構成される。本文書は新しい レコードとプロトコルの修正点を全て説明するものではない。それらは セクション10で概説する関連文書で説明される。セクション3, 4では セキュリティ拡張の機能と制限について詳細に記述する。セクション5では 本文書と関連文書で構成する一連の文書群の対象範囲について説明する。 セクション6, 7, 8, 9では、リゾルバ、スタブリゾルバ、ゾーン、 ネームサーバに対してこのセキュリティ拡張が与える影響について論じる。 本文書と2つの関連文書は [RFC2535], [RFC3008], [RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], [RFC3845]を廃止する。 また[RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225], [RFC3007], [RFC3597], [RFC3226]のDNSSECに関する記述を更新するが 廃止はしない。 Arends, et al. Standards Track [Page 2] RFC 4033 DNS Security Introduction and Requirements March 2005 DNSSECは、DNSデータの出自の認証機能とデータの完全性保護機能を提供 するだけではなく、公開鍵配布の手段としても機能する。ただし、 データの秘匿性は提供しない。 2. 重要なDNSSEC用語の定義 本セクションは、DNSSECに関する一連の文書群で使用する多数の用語を定義 する。一連の文書群を読み進める際に、便利な参照先となるように意図した セクションであるから、初めて本文書に接する読者は、本セクションを 流し読みしておき、残りの文書を読む際に必要に応じて本セクションに 戻ってきても構わない。 認証の連鎖(Authentication Chain): DNSKEY(DNS公開鍵) RRsetとDS (Delegation Signer) RRsetを交互に繰り返して構成する、署名付データの連鎖。 この連鎖内のリンクはそれぞれ次のリンクを保証する。 具体的に、DNSKEY RRを使用してDS RRの署名検証を行うことにより、その DS RRが認証(信頼できるものであると証明)される(DNSKEYからDS RRへの リンク)。このDS RRはDNSKEY RRのハッシュを含むので、このハッシュ値と 一致する新しいDNSKEY RRが次に認証される(DS RRからDNSKEYへのリンク)。 この新たに認証されたDNSKEY RRを使用して他のDNSKEY RRsetを認証し、 そのRRsetが含む幾つかのDNSKEY RRを使用して別のDS RRを認証する。 これを繰り返していき、認証したいDNSデータに署名した秘密鍵と対の DNSKEY RR(公開鍵)に到達した時点で認証の連鎖が終了する。 例えば、ルートのDNSKEY RRsetを使用して"example."ドメインのDS RRsetを 認証することができる。"example."ドメインのDS RRsetはハッシュ値を持ち、 "example."ドメインのDNSKEYのどれかとハッシュ値が一致する。ハッシュ値が 一致したDNSKEYに対応する秘密鍵で"example."ドメインのDNSKEY RRsetに 署名する。このDNSKEY RRsetの秘密鍵で"www.example."のようなデータ レコードや、"subzone.example."のような委任に関するDS RRに署名する。 認証鍵(Authentication Key): DNSSEC対応リゾルバが署名検証を済ませており データ認証に使用できる公開鍵。DNSSEC対応リゾルバが認証鍵を入手する 方法は3つある。 第1に、リゾルバは一般に設定により少なくとも1つは公開鍵を知っている。 この設定データは公開鍵そのものか、DS RRに見られるような公開鍵の ハッシュ値("トラストアンカ"の項参照)のどちらかである。 第2に、リゾルバは認証済みの公開鍵を使用して、DS RRとDS RRが参照する DNSKEY RRの署名検証を行う場合がある。 第3に、ある新しい公開鍵が署名検証済みの他の公開鍵と対の秘密鍵で 署名されたと判断できる場合がある。 リゾルバが新しい公開鍵を認証すべきか判断する際には、常にローカル ポリシーの指針にしたがわなければならないことに注意してもらいたい。 ローカルポリシーが、"リゾルバが署名を検証できた新しい公開鍵は 全て認証する"という単純なものであったとしても、その指針には したがわなければならない。 Arends, et al. Standards Track [Page 3] RFC 4033 DNS Security Introduction and Requirements March 2005 権威を持つRRset(Authoritative RRset): ゾーン内部において、RRsetの 所有者名(owner name)がゾーン頂点(zone apex)またはゾーン頂点より下位の 名前空間のサブセットの範囲内にあり、かつ子ゾーンを分割する分割場所 または分割場所よりも上にある名前空間のサブセットの範囲内にある場合に 限り、そのRRsetは"権威を持つ"という。 ゾーン頂点にあるRRsetは全て権威を持つが、そのゾーンの親に属しながら 同時にそのドメインにも存在するRRsetは例外で権威を持たない。 この例外的なRRsetには、DS RRset、DS RRsetを参照するNSEC RRset ("親ゾーン側のNSEC")、これらのRRsetに署名するRRSIG RRなどが 含まれる。これらのRRsetは全て親ゾーンで権威を持つ。 同様に、このゾーンが委任点(delegation point)を持つ場合、親ゾーン側に 存在するNSEC RRset、DS RRset、これらのRRsetに関連するRRSIG RRだけが このゾーン(親ゾーン)で権威を持ち、子ゾーン側では権威を持たない。 委任点(Delegation Point): ゾーンカットの親側を指す用語。例えば、 "foo.example"の委任点は"example"ゾーンの foo.example ノード となる。("foo.example"ゾーンのゾーン頂点の対語として使用される)。 ゾーン頂点の項も参照のこと。 セキュリティの島(Island of Security): 委任されたゾーンが署名ゾーンで あるが、委任した親側からの認証の連鎖は持たない状態を指す用語。 具体的に、島に相当するゾーン内のDNSKEY RRのハッシュを持つDS RRが 委任した親ゾーン側に存在しない状態を意味する([RFC4034]参照)。 セキュリティの島はDNSSEC対応ネームサーバによって管理され、 セキュリティの島から委任した任意の子ゾーンに対して認証の連鎖を 提供することもできる。セキュリティの島またはその下位ゾーンからの 応答は、それらのゾーンの認証鍵がDNSプロトコル以外の信頼できる手段で 認証可能な場合にだけ認証できる。 KSK(鍵署名鍵: Key Signing Key): ゾーンが持つ1つ以上の認証鍵に署名する 秘密鍵と対の認証鍵(公開鍵)。通常、KSKと対の秘密鍵でゾーン署名鍵 (公開鍵)に署名し、ゾーン署名鍵と対の秘密鍵で他のゾーンデータに署名する という手順になる。このようにすることで、ローカルポリシーが ゾーン署名鍵を頻繁に変更するよう要求する場合であっても、KSKは より安定したセキュアエントリーポイント(SEP)をゾーンに提供するために、 より長い有効期間を持つことができる。 ある認証鍵をKSKだと明示するかどうかは純粋に運用上の問題である。 DNSSECのデータ検証(validation)はKSKとDNSSEC認証鍵を区別しないし、 1つの鍵をKSKとゾーン署名鍵の両方に使用することもできる。KSKについては [RFC3757]に詳しい記述がある。ゾーン署名鍵の項も参照のこと。 Arends, et al. Standards Track [Page 4] RFC 4033 DNS Security Introduction and Requirements March 2005 署名を検証しないDNSSEC対応スタブリゾルバ(Non-Validating Security-Aware Stub Resolver): DNSSEC対応スタブリゾルバの中で、本文書と関連文書が 記述する処理に関して、その大半を実行するために1つ以上のDNSSEC対応 再帰ネームサーバを信頼するもの。特に、署名を検証しないDNSSEC対応 スタブリゾルバは、DNS問合わせを送信し、DNS応答を受信し、自身に代わって サービスを提供するDNSSEC対応再帰ネームサーバと安全なチャネルを確立 できるものを指す。DNSSEC対応スタブリゾルバの項および署名を検証する DNSSEC対応スタブリゾルバの項も参照のこと。 署名を検証しないスタブリゾルバ(Non-Validating Stub Resolver): 署名を検証しないDNSSEC対応スタブリゾルバを若干簡略化した呼称。 DNSSEC対応ネームサーバ(Security-Aware Name Server): ([RFC1034]の セクション2.4で定義する)ネームサーバの役割を果たすものでかつ、 本文書と関連文書が定義するDNSSECを理解するもの。 具体的に、DNSSEC対応ネームサーバとは、DNS問合わせを受信し、DNS応答を 送信し、EDNS0メッセージサイズ拡張([RFC2671])とDOビット([RFC3225])を サポートし、本文書と関連文書で定義するRRタイプとメッセージヘッダ ビットをサポートするものである。 DNSSEC対応再帰ネームサーバ(Security-Aware Recursive Name Server): DNSSEC対応ネームサーバとDNSSEC対応リゾルバの役割を両方提供するもの。 同じ意味だがより長たらしい言い回しとしては "再帰的サービスを提供する DNSSEC対応ネームサーバ"が挙げられる。 DNSSEC対応リゾルバ(Security-Aware Resolver): ([RFC1034]のセクション2.4で 定義する)リゾルバの役割を果たすものでかつ、本文書と関連文書が定義する DNSSECを理解するもの。具体的に、DNSSEC対応リゾルバとは、 DNS問合わせを送信し、DNS応答を受信し、EDNS0メッセージサイズ拡張 ([RFC2671])とDOビット([RFC3225])をサポートし、DNSSECサービスを 提供するために本文書と関連文書が定義するRRタイプとメッセージヘッダ ビットを使用できるものである。 DNSSEC対応スタブリゾルバ(Security-Aware Stub Resolver): ([RFC1034]の セクション5.3.1で定義する)スタブリゾルバの役割を果たすものでかつ、 本文書と関連文書が定義するDNSSECを充分理解するもの。 これにより、DNSSEC非対応スタブリゾルバでは利用できない付加的 サービスを提供する。DNSSEC対応スタブリゾルバは"署名を検証する"か "署名を検証しない"かのどちらかである。前者は自分自身でDNSSEC署名の 検証を試みるが、後者はその処理を自分で行う代わりに、使用する DNSSEC対応ネームサーバの検証結果を信頼する。 署名を検証するスタブリゾルバの項と署名を検証しないスタブリゾルバの 項も参照のこと。 Arends, et al. Standards Track [Page 5] RFC 4033 DNS Security Introduction and Requirements March 2005 DNSSEC非対応(Security-Oblivious) <何か>: DNSSEC対応ではない<何か>。 署名ゾーン(Signed Zone): ゾーンのRRsetが署名されている、すなわちゾーンが DNSKEY、RRSIG(Resource Record Signature)、NSEC(Next Secure)、 (任意で)DSレコードで適切に構成されているもの。 トラストアンカー(Trust Anchor): あらかじめ設定として持っているDNSKEY RR またはDNSKEY RRのハッシュを持つDS RR。 署名を検証するDNSSEC対応リゾルバは、署名付きDNS応答に至るまでの 認証の連鎖を構築する際に、この公開鍵またはハッシュ値を起点として 使用する。一般に、署名を検証するリゾルバは、DNSプロトコル以外の 安全かつ信頼できる手段でトラストアンカーの初期値を入手しなければ ならない。また、トラストアンカーが存在するということは、リゾルバは トラストアンカーがポイントするゾーンを署名付きのものとして扱うべき であることを意味する。 未署名ゾーン(Unsigned Zone): 署名されていないゾーン。 署名を検証するDNSSEC対応スタブリゾルバ(Validating Security-Aware Stub Resolver): DNSSEC対応リゾルバでありかつ、問合わせを再帰検索 モードで送信するが、署名の検証については使用するDNSSEC対応再帰 ネームサーバを盲目的に信頼せず、自分自身で検証を行うもの。 DNSSEC対応スタブリゾルバの項および署名を検証しないDNSSEC対応 スタブリゾルバの項も参照のこと。 署名を検証するスタブリゾルバ(Validating Stub Resolver): 署名を検証するDNSSEC対応スタブリゾルバを若干簡略化した呼称。 ゾーン頂点(Zone Apex): ゾーンカットの子側を指す用語。委任点の項も参照 のこと。 ZSK(ゾーン署名鍵: Zone Signing Key):ゾーン署名に使用する秘密鍵と対の 認証鍵(公開鍵)。通常、ZSKはDNSKEY RRsetに署名する秘密鍵と対のKSKと 同様に、DNSKEY RRsetの一部である。しかしZSKはKSKとは若干異なる目的で 使用され、有効期間など幾つか異なる点もある。 ある認証鍵をZSKだと明示するかどうかは純粋に運用上の問題である。 DNSSECのデータ検証(validation)はKSKとDNSSEC認証鍵を区別しないし、 1つの鍵をKSKとゾーン署名鍵の両方に使用することもできる。 KSKの項も参照のこと。 Arends, et al. Standards Track [Page 6] RFC 4033 DNS Security Introduction and Requirements March 2005 3. DNSSECが提供するサービス DNSSECは、DNSデータの出自の認証サービスと、データの完全性(改ざんされて いないこと)を保護するサービスに加えて、DNSデータの不在を証明する仕組みを 提供する。これらの仕組みについて以下に記述する。 これらの仕組みを実現するためには、DNSプロトコルの変更が必要である。 DNSSECは4つのリソースレコード、すなわちRRSIG(Resource Record Signature), DNSKEY(DNS Public Key), DS(Delegation Signer), NSEC(Next Secure)を 追加する。また2つのメッセージヘッダビット、すなわちCD(Checking Disabled) とAD(Authenticated Data)を追加する。 DNSSECに関連するRRを追加するとメッセージサイズはより大きくなるため、 DNSSECにはEDNS0([RFC2671])のサポートも必要とする。 最後に、DNSSEC対応リゾルバが、問合わせの際に応答メッセージで DNSSEC RRを受信したいという要望を明示できるようにするため、DNSSECは EDNSヘッダ内のDNSSEC OK(DO)ビット([RFC3225])のサポートを必要とする。 これらのサービスは、[RFC3833]に記載のあるDNSへの脅威の大部分を防御する。 この拡張の制限に関する議論についてはセクション12を参照のこと。 3.1. データ生成元の認証とデータの完全性保護 DNSSECは、DNSSEC RRsetに暗号技術を使用して生成された電子署名を結びつける ことで認証機能を提供する。電子署名は新しいリソースレコードであるRRSIG レコードに保存される。一般にゾーンデータに署名するのは単一の秘密鍵だが、 複数の鍵を使用することもできる。例えば、それぞれ異なる電子署名 アルゴリズムの鍵を複数使用してもよい。DNSSEC対応リゾルバがゾーンの 公開鍵を信頼できる手段で学習すると、そのリゾルバはゾーンの署名付き データを認証することができるようになる。 DNSSECにおける重要な考え方として、ゾーンデータに署名する鍵はゾーン自身に 関連付けられるものであり、ゾーンの権威ネームサーバには関連付けられる ものではない。([RFC2931]に記述があるように、DNSトランザクションの認証に 使用する公開鍵がゾーン内に存在する場合もある。しかしDNSSEC自身は オブジェクトセキュリティ(訳注: データ側で安全を確保するアプローチ)に 関する技術であり、DNSトランザクションのチャネルセキュリティ (訳注: データを転送する経路で安全を確保するアプローチ)に関連する技術では ない。トランザクションセキュリティに関連する鍵は別のRRタイプに保存される。 詳細は[RFC3755]を参照のこと)。 Arends, et al. Standards Track [Page 7] RFC 4033 DNS Security Introduction and Requirements March 2005 DNSSEC対応リゾルバは、トラストアンカーを設定で保持するか、通常の DNS名前解決処理を行うかのどちらかにより、ゾーンの公開鍵を学習することが できる。後者の手段を可能にするため、公開鍵を新しいリソースレコードである DNSKEY RRに保存する。ゾーンデータに署名する秘密鍵は安全に保持されなければ ならないため、そうすることが実際的であるならばオフラインで保存すべきで あることに注意してもらいたい。DNSの名前解決を通して信頼できる手段で 公開鍵を発見するために、探索対象の鍵自身は事前に設定された認証鍵か、 あらかじめ認証済みの別の鍵によって署名されていなければならない。 DNSSEC対応リゾルバは、新しく学習した認証鍵(公開鍵)から事前に学習済みの 認証鍵(公開鍵)へと連なる認証の連鎖を形成し、ゾーンデータを認証する。 "事前に学習済みの認証鍵"とは、リゾルバが設定として保持するものか、 事前に学習し検証済みのものかのどちらかである。 したがって、DNSSEC対応リゾルバは、少なくとも1つはトラストアンカーを 設定として持たなければならない。 設定されたトラストアンカーがZSKの場合、それを使用して関連するゾーンを 認証し、KSKの場合、それを使用してZSKを認証する。 設定されたトラストアンカーが鍵そのものではなく鍵のハッシュ値である場合、 リゾルバはDNS問合わせを通して鍵を入手しなければならない。DNSSEC対応 リゾルバが認証の連鎖を構築するのを助けるため、DNSSEC対応ネームサーバは、 DNS応答メッセージのサイズに余裕があれば、ゾーンの公開鍵に加えて ゾーン公開鍵を認証するために必要な署名を共に送信しようと試みる。 DS(Delegation Signer) RRタイプは、組織の境界をまたぐ委任への署名に 必要な管理作業を簡略化する。DS RRsetは親ゾーン側の委任点に位置し、 委任された子側のゾーン頂点に位置するDNSKEY RRsetの自己署名に使用した 秘密鍵と対の公開鍵を提示する。次に子ゾーンの管理者は自己署名された DNSKEY RRsetに含まれる1つ以上の公開鍵と対の秘密鍵を使用して 子ゾーンのデータに署名する。したがって、一般的な認証の連鎖は DNSKEY->[DS->DNSKEY]*->RRsetになる。ここで"*"は0個以上のDS->DNSKEYの 部分的連鎖を意味する。DNSSECは、例えばゾーン内においてあるDNSKEY RRと 対の秘密鍵が別のDNSKEY RRに署名する、つまりDNSKEY->DNSKEYとなるような 一段階認証の階層を追加した形態のより複雑な認証の連鎖も許容する。 DNSSEC対応リゾルバは、通常事前に設定されたDNSのルートの公開鍵を使用して、 認証の連鎖をルートから下位のゾーン(leaf zone)に向けて構築していく。 しかし、ローカルポリシーにより、DNSSEC対応リゾルバはルートの公開鍵では なく、設定された1つ以上の公開鍵(かまたは公開鍵のハッシュ値)を使用できる かもしれないし、またルートの公開鍵が設定されない場合もある。更に、 なんらかの理由により、たとえ公開鍵の署名が適切に検証可能であっても、 その公開鍵の使用を抑制する場合もある。 DNSSECは、DNSSEC対応リゾルバがRRsetの署名をDNSSECの枠内で"有効"であるか 判断できる仕組みを提供する。しかし、DNSの認証鍵やデータを認証するか どうかは最終的にはローカルポリシーの問題である。ローカルポリシーは 本文書と関連文書が定義するDNSSECの効果を更に拡大する場合もあり、 無効にする場合もある。より詳細な議論についてはセクション5を参照のこと。 Arends, et al. Standards Track [Page 8] RFC 4033 DNS Security Introduction and Requirements March 2005 3.2. 名前およびタイプの不在証明 セクション3.1に記述したDNSSECの仕組みは、ゾーンに存在するRRsetに署名する 方法を提供するだけである。同じレベルの認証と完全性を持つ不在応答を 提供するという問題を解決するためには、新しいリソースレコードタイプである NSECレコードを使用する必要がある。NSECレコードにより、DNSSEC対応 リゾルバは、名前またはタイプの不在を示す不在応答を他のDNS応答を認証 するのと同じ仕組みで認証できるようになる。NSECレコードを使用するには、 ゾーン内のドメイン名が正規に表現され、かつ順序づけがされている 必要がある。NSECレコードの連鎖はゾーン内に存在するドメイン名間のすき間 または"空き空間"を明示的に示し、また既存の名前が持つRRsetのタイプを 列挙する。各NSECレコードは、セクション3.1に記述した仕組みで署名され 認証される。 4. DNSSECが提供しないサービス 元来、DNSは誰が問合わせを発行したかにかかわらず、任意の問合わせに対して 同じ応答を返す、つまりDNS内に存在する全てのデータは閲覧可能(visible)である という前提で設計された。したがって、DNSSECは秘匿性やアクセス制限を実現する 手段や、問合わせ発行者に応じて応答を差別化する他の手段を提供するようには 設計されていない。 DNSSECはサービス不能攻撃(denial of service attacks)への防御機能を 何も提供しない。DNSSEC対応リゾルバとDNSSEC対応ネームサーバは、 どちらも暗号処理を利用した、新たなサービス不能攻撃に対して 脆弱である。詳細についてはセクション12を参照のこと。 DNSSECは、DNSデータとDNSデータの出自の認証機能を提供する。 これまでに概略を説明したこの仕組みは、ゾーン転送やダイナミックアップデート ([RFC2136], [RFC3007])等の処理を保護するようには設計されていない。 これらのトランザクションの安全な運用には、[RFC2845]と[RFC2931]に 記載のあるメッセージ認証の仕組みが用いられる。 5. DNSSEC文書群の対象範囲とラストホップ問題(Last Hop Issues) 本文書と関連文書は、データ検証者が明確にデータの状態を判定できるように ゾーン署名者・DNSSEC対応ネームサーバおよびDNSSEC対応リゾルバの振る舞いを 定義している。 データの署名を検証するリゾルバは、以下の4つの状態を判定できる。 Secure(検証成功：信頼度高) 署名を検証するリゾルバがトラストアンカーを持ち、信頼の連鎖を 構築しており、応答に含まれる署名を全て検証可能だった状態。 Arends, et al. Standards Track [Page 9] RFC 4033 DNS Security Introduction and Requirements March 2005 Insecure(未署名状況検出：信頼度低) 署名を検証するリゾルバがトラストアンカーを持ち、信頼の連鎖を構築 しているが、幾つかの委任点でDSレコードが署名付きで不在であると 示されている状態。これは、DNS木構造においてDSレコードが 存在しないとわかっている下位の空間は、おそらく安全ではないことを 意味する。署名を検証するリゾルバは、ドメイン空間の一部を安全でない ものとしてマークするローカルポリシーを設定してもよい。 Bogus(検証失敗：信頼禁止) 署名を検証するリゾルバがトラストアンカーを持ち、子側のデータが 署名付きの安全な委任がなされていることまでを確認しているが、 応答の署名検証には失敗した状態。 署名の検証に失敗する理由は幾つか考えられ、例えば署名の消失、 署名の期限切れ、署名で使われているアルゴリズムをサポートしていない、 NSEC RRは存在すると主張しているデータが実際には無い等が挙げられる。 Indeterminate(検証対象外：信頼度低) DNS木構造の一部が安全であることを示すトラストアンカーが 全く存在しない状態。これがデフォルトの運用モードである。 本仕様では、DNSSEC対応ネームサーバが署名を検証しないDNSSEC対応スタブ リゾルバに対し、データがBogusと判明したことを通知する手段を定義する だけである(RCODE=2, "Server Failure"を使用。[RFC4035]参照)。 DNSSEC対応ネームサーバがDNSSEC対応スタブリゾルバに対し、データが Secureと判明したことを通知する仕組みは既に存在する。(ADビットを使用。 [RFC4035]参照)。 本仕様は、応答がBogusと判定されたり、Insecureとマークされたりした理由を 通知する際に使用する書式を定義しない。つまり、現在の通知の仕組みは、 応答の状態がIndeterminateかInsecureかを区別しない。 DNSSEC対応スタブリゾルバとDNSSEC対応再帰ネームサーバの間で高度な エラーコードやポリシをやりとりする手法については、DNSSEC対応リゾルバと それを利用するアプリケーション間のインターフェース同様に今後の課題である。 しかし、本仕様がそのような通信を規定しないことで、署名ゾーンの展開が 抑制されるものではなく、また不適正なデータをアプリケーションに通知しない DNSSEC対応再帰ネームサーバの展開を抑制するものでもないことに注意 してもらいたい。 Arends, et al. Standards Track [Page 10] RFC 4033 DNS Security Introduction and Requirements March 2005 6. リゾルバに関する考慮点 DNSSEC対応リゾルバは、少なくとも実装必須なアルゴリズムの電子署名を 検証するために必要な暗号機能を実行できなければならない。 またDNSSEC対応リゾルバは、先に記述したとおり、新たに学習したゾーンから 認証鍵に至る認証の連鎖を形成できなければならない。この処理は、必要な DNSKEY、DSおよびRRSIGレコードを得るために、中間のDNSゾーンに対する 問合わせを必要とするかもしれない。 認証の連鎖を構築する起点として使用するため、DNSSEC対応リゾルバは 少なくとも1つはトラストアンカーを設定として持つべきである。 DNSSEC対応リゾルバと権威ネームサーバが再帰ネームサーバやDNSプロキシとして 動作する中間デバイスによって切り離されている状況で、再帰ネームサーバ または中間デバイスがDNSSEC対応ではない場合には、DNSSEC対応リゾルバは 安全なモードでは動作できないかもしれない。例えば、DNSSEC対応リゾルバの パケットがDNSSEC非対応のDNSプロキシ機能を持つNATデバイスを通して 経路付けされる場合、DNSSEC対応リゾルバは署名付きDNSデータを得たり 検証したりするのは困難であるか不可能だと判断するだろう。 このような状況下では、DNSSEC対応リゾルバがDS RRを得ることは特に困難に なる。DS RRはゾーンカットにおけるRRの所有者に関する一般的なDNSのルールに したがわないためである。 この問題はNAT固有のものではないことに注意してもらいたい。DNSSEC対応 リゾルバと権威ネームサーバ間に存在するあらゆるDNSSEC非対応の DNSソフトウェアはDNSSECの処理を妨害する。 DNSSEC対応リゾルバが未署名ゾーンまたはDNSSEC非対応DNSサーバに依存 しなければならない場合、DNSSEC対応リゾルバはDNS応答の署名検証をできない ので、未検証の応答を受理するかどうかについてローカルポリシーの判断を 必要とする。 署名付きデータを署名の有効期限を越えてキャッシュしないように、 DNSSEC対応リゾルバはデータのTTLを判定する際に署名の有効期限も 考慮すべきである。また一方で、DNSSEC対応リゾルバの時計が誤っている 可能性も許容すべきである。 したがって、DNSSEC対応再帰ネームサーバ内のDNSSEC対応リゾルバは、 DNSSEC CD(checking disabled)ビット([RFC4034])に細心の注意を 払わなければならない。これは、この再帰ネームサーバのクライアントに なっている他のDNSSEC対応リゾルバに有効な署名を伝達するのを 阻害しないためである。 DNSSEC対応再帰ネームサーバがCDビットが設定された問合わせを処理する 方法については[RFC4035]を参照のこと。 Arends, et al. Standards Track [Page 11] RFC 4033 DNS Security Introduction and Requirements March 2005 7. スタブリゾルバに関する考慮点 プロトコルで厳密に要求されているわけではないのだが、ほとんどの DNS問合わせはスタブリゾルバで生成される。定義によれば、 スタブリゾルバとはDNS名前解決処理の大半を再帰ネームサーバに 委託するために再帰問合わせモードを使用する、最小限のDNSリゾルバである。 スタブリゾルバは広範囲で使用されているため、DNSSECアーキテクチャは スタブリゾルバを考慮しなければならない。しかし、スタブリゾルバで 必要とされるDNSSEC機能は、DNSSEC対応の反復検索を行うリゾルバ (フルリゾルバ)で必要とされる機能と幾つかの点で異なる。 スタブリゾルバがDNSSEC非対応であったとしても、そのスタブリゾルバが 使用する再帰ネームサーバがDNSSEC対応であれば、DNSSECの恩恵を受けられる かもしれない。しかしDNSSECサービスを実際にあてにするのであれば、 スタブリゾルバは使用する再帰ネームサーバとネームサーバへの通信チャネルの 両方を信頼しなければならない。 再帰ネームサーバを信頼する問題はローカルポリシーに関するものである。 DNSSEC非対応スタブリゾルバは自分ではDNSSECのデータ検証を行わないため、 使用する再帰ネームサーバを信じる以外に選択肢は存在しない。 通信チャネルを信頼する問題は、何らかのチャネルセキュリティの仕組みを 必要とする。SIG(0)([RFC2931])やTSIG([RFC2845])のようなDNSトランザクション 認証の仕組みを適切に使用したり、IPsecを適切に使用すれば充分だろう。 特定の実装では、OS固有のプロセス間通信の仕組みのような別の選択肢も 利用可能かもしれない。このチャネルに秘匿性は必要ないが、データの 完全性保護とメッセージ認証は必要である。 再帰ネームサーバと通信チャネルの両方を信頼するDNSSEC対応スタブ リゾルバは、受信した応答メッセージのメッセージヘッダ内にある AD(Authenticated Data)ビットが設定されているかを調査してもよい。 再帰ネームサーバが応答の回答部(Answer section)と権威部(Authority section)の データ全てについて署名を検証できたのかを判断するヒントとして、 スタブリゾルバはこのフラグビットを利用することができる。 何らかの理由により、DNSSEC対応スタブリゾルバと、スタブリゾルバが使用する 再帰ネームサーバとの間に信頼関係を築けない場合、スタブリゾルバが選択可能な 方法がもう1つある。問合わせメッセージ内のCD (Checking Disabled)ビットを 設定することにより、自分自身で署名の検証を行えるようにすることである。 このようにすることで、署名検証を行うスタブリゾルバは、DNSSEC署名の処理を 通してゾーン管理者と信頼関係を築くことができるようになる。 8. ゾーンに関する考慮点 署名ゾーンと未署名ゾーンでは幾つか違いがある。署名ゾーンはセキュリティに 関連する付加的なレコード(RRSIG、DNSKEY、DSおよびNSECレコード)を持つ。 RRSIGおよびNSECレコードは、ゾーン提供前に行われる署名処理の際に 生成される。ゾーンデータに付随するRRSIGレコードは、署名とその署名対象 ゾーンデータの有効期間の開始時刻と終了時刻の情報を保持する。 Arends, et al. Standards Track [Page 12] RFC 4033 DNS Security Introduction and Requirements March 2005 8.1. TTL値とRRSIGの有効期限との関係 RRsetのTTL値と、RRsetの署名を持つRRSIG RRが指定する署名の有効期限の 区別に注意することは重要である。TTL値はキャッシュ内のデータベースの 一貫性を意図したものだが、DNSSECはその機能または定義を変更しない。 キャッシングリゾルバは、DNSSEC対応であるかどうかに関わらず、RRsetの TTLフィールドで指定された期限を過ぎたRRセットをキャッシュから消去する。 一方で、RRSIG RR([RFC4034])内の有効期間開始(inception)および 終了(expiration)フィールドは、署名をRRsetの検証に使用できる期間を 指定する。署名ゾーンのデータの署名は、該当するRRSIG RR内のこれらの フィールドで指定された期間だけ有効である。 リゾルバのキャッシュ内にある署名付きRRsetの有効期限をTTL値で延長させる ことはできない。しかし署名付きRRsetの署名有効期限までの残り時間を、 キャッシュ内にあるそのRRsetと関連するRRSIG RRとのTTLの上限値として 使用することはできる。 8.2. ゾーンで新たに発生する時間依存の問題 署名ゾーンに含まれる情報には、オリジナルのDNSプロトコルに存在しなかった 時間的な依存関係が存在する。署名ゾーンに含まれるRRsetが有効期限内の RRSIG RRを持つことを保証するため、署名ゾーンは定期的な保守を必要とする。 RRSIG RRの署名有効期限は、ある特定の署名付きRRsetの署名が有効とみなされる 期間である。したがって同じゾーン内の別のRRsetは異なる時刻に有効期限が 終了するかもしれない。ゾーン内の1つ以上のRRsetに再署名すると1つ以上の RRSIG RRが変更されるため、ゾーンのSOAシリアル番号をインクリメントして ゾーン更新を明示するとともにSOA RRsetの再署名が必要となる。 つまり、ゾーン内のRRsetに再署名すると、DNS NOTIFYメッセージとゾーン 転送処理のトリガーとなる。 9. ネームサーバに関する考慮点 リゾルバが、問合わせメッセージにおいて、メッセージサイズ制限を考慮して EDNS0ヘッダを使用し、DOビットを設定して適切なDNSSECレコード(RRSIG、DNSKEY、 DSおよびNSEC)の受信を希望することを通知した場合、DNSSEC対応ネームサーバは その問合わせへの応答にDNSSECレコードを含めて返すべきである。 DNSSEC RRをメッセージに含めると、容易にUDPメッセージ切り詰め(truncate)と TCPへの後退が生じるため、DNSSEC対応ネームサーバはEDNSの "sender's UDP payload"の仕組みをサポートしなければならない。 Arends, et al. Standards Track [Page 13] RFC 4033 DNS Security Introduction and Requirements March 2005 DNSSECの鍵ペアについて、秘密鍵は可能であればオフラインで保持すべきだが、 DNSのダイナミックアップデートが有効なゾーンではそれは不可能である。 ダイナミックアップデートを行う場合、ゾーンのプライマリマスタサーバは ゾーン更新時に再署名を行わなければならないため、ZSKと対の秘密鍵は オンラインで保持されなければならない。 これはゾーンのDNSKEY RRsetをZSKとKSKに分けることが有益な例である。 このような状況でも、KSKと対の秘密鍵は依然としてオフラインで保持し、 ZSKよりも長く利便性のよい有効期間を設定することができる。 ゾーン転送時にゾーン全体の完全性を保護するには、DNSSECだけでは不十分 である。なぜなら署名ゾーンであっても子ゾーンがあれば署名が無く 権威を持たないデータを含むからである。したがってゾーン保守作業には 付加的な仕組み(おそらくはTSIG、SIG(0)あるいはIPsecのようなチャネル セキュリティ形態のもの)が必要となる。 10. DNSSECの関連文書 DNSSECの文書群は、より大きなDNS基本プロトコル文書群に属する幾つかの 主要なグループに分割できる。 "DNSSECプロトコル文書群"は、DNSSECの中心部分を成す3つの文書を指す。 1. DNSSECの紹介とその要件 (本文書) 2. DNSSECで使用するリソースレコード [RFC4034] 3. DNSSECのためのプロトコル変更 [RFC4035] 更に、DNSSECの中心部分に追加または変更を行う文書もこの分類に属する。 例えばDNSSEC対応スタブリゾルバと上流のDNSSEC対応再帰ネームサーバ間の 通信に関する今後の取り組みなどが考えられる。 "電子署名アルゴリズムの実装仕様"文書群は、特定の電子署名アルゴリズムを DNSSECリソースレコードフォーマットに適合するよう実装する手法を記述した 文書群である。文書群に属する文書それぞれが特定の電子署名アルゴリズム 1つを扱う。DNSSECの中心部分が規定された段階で定義されたアルゴリズムの リストについては、[RFC4034]の付録"DNSSECアルゴリズムとダイジェスト タイプ"を参照のこと。 "トランザクション認証プロトコル"文書群は、秘密鍵の確立と検証などを 含めてDNSメッセージ認証について扱う文書群である。厳密には関連文書で定義 するDNSSEC仕様の一部ではないが、DNSSECとの関係を示すためにこの文書群に ついても記述した。 Arends, et al. Standards Track [Page 14] RFC 4033 DNS Security Introduction and Requirements March 2005 最後の文書群である"新しいセキュリティの使用法"は、提案したDNSSECを 別のセキュリティ関連の目的で使用する方法を模索するものである。 DNSSECはこれら新しい使用法に対して直接的なセキュリティは提供しないが、 新しい使用法の支援はできるかもしれない。DNSを使用した証明書の保存と配布 ([RFC2538])の方法に関する文書はこの文書群に属する。 11. IANAに関する考慮点 この概略を記した文書では、IANAに関する新たな考慮すべき事項は存在しない。 DNSSEC導入に際してIANAに関して考慮すべき事項の全容については[RFC4034]を 参照のこと。 12. セキュリティに関する考慮点 本文書はDNSSECを紹介し、新しいセキュリティレコードとDNSプロトコルの 修正に関する文書群について記述している。DNSSECは、RRsetに電子署名を 付与することにより、DNSデータの出自の認証機能とデータの完全性保護機能を 提供する。本セクションではこれらの拡張機能の制限について述べる。 本文書と関連文書で定義しているように、DNSSEC対応リゾルバがDNS応答の 署名検証を行うためには、信頼できる起点から応答に含まれるゾーンまで 連なる全ゾーンが署名ゾーンでなければならない。また名前解決処理に関わる 全てのネームサーバとリゾルバはDNSSEC対応でなければならない。 DNSSEC対応リゾルバは、未署名ゾーンで生成された応答、DNSSEC非対応の ネームサーバが提供するゾーンで生成された応答は署名検証できない。 またDNSSEC非対応の再帰ネームサーバを経由してしかDNSデータを取得できない 場合、そこから得られたあらゆるDNSデータは署名検証できない。 DNSSEC対応リゾルバが必要な認証鍵を入手できなかったり、入手できても 署名検証できないといった場合のような、認証の連鎖に断絶が生じた場合、 DNSSEC対応リゾルバはその認証の連鎖を必要とするDNSデータを署名検証 できない。 本文書では、IPsecで保護されたチャネルの利用、TSIG([RFC2845])またはSIG(0) ([RFC2931])のようなDNSトランザクション認証の仕組みといった、 DNS問合わせにセキュリティを付加する別の方法について簡単に記述しているが、 トランザクションセキュリティはDNSSECそれ自体の一部ではない。 署名を検証しないDNSSEC対応スタブリゾルバは、定義により自身ではDNSSECの 署名を検証しないので、署名検証を代理で行うDNSSEC対応再帰ネームサーバ 上の攻撃、DNSSEC対応再帰ネームサーバからの攻撃、リゾルバからDNSSEC対応 再帰ネームサーバまでの通信路における攻撃に対して脆弱である。 最後に挙げた脅威を防御するために、署名を検証しないDNSSEC対応スタブ リゾルバは何らかのチャネルセキュリティを使用すべきである。 始めに挙げた二つの脅威に対する防御法として唯一知られているものは、 DNSSEC対応スタブリゾルバが自分自身で署名検証を実行することである。 しかし定義により、この時点でそのリゾルバは署名を検証しないDNSSEC対応 スタブリゾルバではなくなる。 Arends, et al. Standards Track [Page 15] RFC 4033 DNS Security Introduction and Requirements March 2005 DNSSECはサービス不能攻撃を防御しない。DNSSECを導入することにより、 DNSSEC対応リゾルバとDNSSEC対応ネームサーバは共に暗号処理を利用した サービス不能攻撃に対して脆弱になる。攻撃者はDNSSECの仕組みを利用して、 目標とするマシンのリソース消費を試みられるからである。 暗号処理を利用した攻撃には少なくとも2つの形態が考えられる。攻撃者は、 応答メッセージ内のRRSIG RRを改ざんするか、必要以上に複雑な認証の連鎖を 構築することにより、DNSSEC対応リゾルバの署名検証コード実行時にリゾルバの リソースを消費させることができるかもしれない。また、DNSダイナミック アップデートをサポートするDNSSEC対応ネームサーバに対して、過剰な頻度で ゾーン内のRRsetに再署名を強制するようなダイナミックアップデートの ストリームを送りつけることにより、ネームサーバのリソースを消費させる ことができるかもしれない。 設計時に意図的にそのように選択したので、DNSSECは秘匿性を提供しない。 DNSSECを導入すると、悪意を持った集団がNSECの連鎖をたどってゾーン内の 全ての名前を列挙できるようになる。NSEC RRは、ゾーンに存在する全ての名前を 正規順序づけし、それを順にリンクしていくことにより、ゾーン内に存在しない 名前を明示する。したがって、攻撃者はNSEC RRを順に問い合わせることで、 ゾーン内の全ての名前を取得することができる。これはDNSそのものへの 攻撃ではないが、ゾーンの内容を列挙することにより、攻撃者はネットワーク ホストや他のリソースを把握できる可能性がある。 DNSSECを導入するとDNSが大幅に複雑になるため、実装のバグやゾーン設定の 誤りが発生する機会が増加する。特にリゾルバでDNSSEC署名検証機能を有効に すると、DNSSECの設定誤りやバグのために正当なゾーン全体が到達不可能になる 可能性がある。 DNSSECは署名を持たないゾーンデータの改ざんを防御しない。ゾーンカットに おける権威を持たないデータ(親ゾーンのグルーとNS RR)は署名されない。 これにより認証の連鎖の検証時に問題が生じることはないが、権威を持たない データそのものはゾーン転送中の改ざんに対して脆弱であることを意味する。 DNSSECはRRsetに対してデータの出自の認証とデータの完全性保護を提供 できるが、ゾーンに対しては提供できないので、(TSIG、SIG(0)あるいは IPsecのような)他の仕組みを使用してゾーン転送を保護しなければならない。 Arends, et al. Standards Track [Page 16] RFC 4033 DNS Security Introduction and Requirements March 2005 セキュリティに関する考慮点について他に追加すべき事項については、 [RFC4034]と[RFC4035]を参照のこと。 13. Acknowledgements This document was created from the input and ideas of the members of the DNS Extensions Working Group. Although explicitly listing everyone who has contributed during the decade in which DNSSEC has been under development would be impossible, the editors would particularly like to thank the following people for their contributions to and comments on this document set: Jaap Akkerhuis, Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein, David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson, Gilles Guette, Andreas Gustafsson, Jun-ichiro Itojun Hagino, Phillip Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson, Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters, Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis, Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ Mundy, Thomas Narten, Mans Nilsson, Masataka Ohta, Mike Patton, Rob Payne, Jim Reid, Michael Richardson, Erik Rozendaal, Marcos Sanz, Pekka Savola, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, Brian Wellington, and Suzanne Woolf. No doubt the above list is incomplete. We apologize to anyone we left out. 14. References 14.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001. Arends, et al. Standards Track [Page 17] RFC 4033 DNS Security Introduction and Requirements March 2005 [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver message size requirements", RFC 3226, December 2001. [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. 14.2. Informative References [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. [RFC2538] Eastlake 3rd, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System (DNS)", RFC 2538, March 1999. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000. [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) Signing Authority", RFC 3008, November 2000. [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone Status", RFC 3090, March 2001. [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. Arends, et al. Standards Track [Page 18] RFC 4033 DNS Security Introduction and Requirements March 2005 [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS Authenticated Data (AD) bit", RFC 3655, November 2003. [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", RFC 3658, December 2003. [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004. [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, April 2004. [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004. [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format", RFC 3845, August 2004. Arends, et al. Standards Track [Page 19] RFC 4033 DNS Security Introduction and Requirements March 2005 Authors' Addresses Roy Arends Telematica Instituut Brouwerijstraat 1 7523 XC Enschede NL EMail: roy.arends@telin.nl Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA EMail: sra@isc.org Matt Larson VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA EMail: mlarson@verisign.com Dan Massey Colorado State University Department of Computer Science Fort Collins, CO 80523-1873 EMail: massey@cs.colostate.edu Scott Rose National Institute for Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899-8920 USA EMail: scott.rose@nist.gov Arends, et al. Standards Track [Page 20] RFC 4033 DNS Security Introduction and Requirements March 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Arends, et al. Standards Track [Page 21]