ネットワークワーキンググループ 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セキュリティ拡張の紹介とその要件 本文書の位置づけ 本文書はインターネットコミュニティーのためにインターネット標準化過程に あるプロトコルを規定し、その向上のために議論と提案を求めるものである。 このプロトコルの標準化の状況については"Internet Official Protocol Standards"(STD 1)の最新版を参照のこと。本文書の配布は制限されない。 著作権表示 Copyright (C) The Internet Society (2005). 要旨 DNSセキュリティ拡張(DNSSEC)は、データ生成元の認証機能とデータの完全性 保護機能をDNSに追加するものである。本文書はこれらの拡張について紹介し、 その機能と制限について記述する。本文書はまた、DNSセキュリティ拡張が どのようなサービスを提供し、どのようなサービスは提供しないのかについても 論ずる。最後にDNSSECについて記述している様々な文書の関係を説明する。 Arends, et al. Standards Track [Page 1] RFC 4033 DNS Security Introduction and Requirements March 2005 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 重要なDNSSEC用語の定義 . . . . . . . . . . . . . . . . . . . 3 3. DNSセキュリティ拡張が提供するサービス. . . . . . . . . . . . 7 3.1. データ生成元の認証とデータの完全性保護 . . . . . . . . 7 3.2. 名前およびタイプの不在証明 . . . . . . . . . . . . . . 9 4. DNSセキュリティ拡張が提供しないサービス. . . . . . . . . . . 9 5. DNSSEC文書群の対象範囲とラストホップ問題(Last Hop Issues). . 9 6. リゾルバに関する考慮点 . . . . . . . . . . . . . . . . . . . 10 7. スタブリゾルバに関する考慮点 . . . . . . . . . . . . . . . . 11 8. ゾーンに関する考慮点 . . . . . . . . . . . . . . . . . . . . 12 8.1. TTL値とRRSIGの有効期限との関係 . . . . . . . . . . . . 13 8.2. ゾーンで新たに発生する依存関係の問題 . . . . . . . . . 13 9. ネームサーバに関する考慮点 . . . . . . . . . . . . . . . . . 13 10. DNSセキュリティ拡張の関連文書. . . . . . . . . . . . . . . . 14 11. IANAに関する考慮点 . . . . . . . . . . . . . . . . . . . . . 15 12. セキュリティに関する考慮点 . . . . . . . . . . . . . . . . . 15 13. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 14. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . 17 14.1. 必須の参考文献 . . . . . . . . . . . . . . . . . . . . 17 14.2. 有用な参考文献 . . . . . . . . . . . . . . . . . . . . 18 著者達の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . 20 完全な著作権表示 . . . . . . . . . . . . . . . . . . . . . . . . 21 1. はじめに 本文書はDNSセキュリティ拡張(DNSSEC)を紹介する。本文書と2つの関連文書 ([RFC4034]と[RFC4035])は、RFC2535[RFC2535]とそれに先行する取り組みで 定義されたセキュリティ拡張を更新し、明確にすると同時により洗練するもの である。このセキュリティ拡張は、幾つかの新しいリソースレコードタイプと 既存の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 DNSセキュリティ拡張はDNSデータの生成元認証機能とデータ完全性保護 機能を提供するだけではなく、公開鍵配布の手段としても機能する。ただし、 これらの拡張は機密性は提供しない。 2. 重要なDNSSEC用語の定義 本セクションは本文書を含むDNSSECに関する一連の文書群で使用する多数の 用語を定義する。本セクションは本文書以外の残りの文書群を読み進める上で 有用であるように意図して設けられたセクションであるから、読者ははじめは 流し読みしておき、残りの文書を読んだ後であらためて本セクションに 戻ってきても構わない。 認証の連鎖(Authentication Chain): DNS公開鍵(DNSKEY) RRsetとDelegation Signer (DS) RRsetを交互に繰り返して構成された、署名付データの連鎖。 この連鎖内のリンクはそれぞれ次のリンクを保証する。あるDNSKEY RRを 使用して連鎖の次のDS RRの署名を検証することにより、DS RRを認証する ことができる。認証されたこのDS RRは、連鎖の次に位置する別のDNSKEY RRの ハッシュを含み、この新しいDNSKEY RRはDS RRにおけるハッシュの一致により 認証される。この新しいDNSKEY RRは順次別のDNSKEY RRsetを 認証し、そのDNSKEY RRsetに含まれる幾つかのDNSKEY RRが別のDS RRを 認証する。この連鎖は目的とするDNSデータに署名した秘密鍵に対応する 公開鍵をデータとして持つDNSKEY RRに到達するまで繰り返される。 例えばルートのDNSKEY RRsetを使用して、ルートドメイン内に存在する "example."ドメイン向けDS RRsetを認証することができる。 このDS RRsetは"example."ドメイン内にあるDNSKEYと同じハッシュ値を 持つ。この同じハッシュ値を持つDNSKEYの秘密鍵で"example."ドメインの DNSKEY RRsetに署名する。このDNSKEY RRsetの秘密鍵で"www.example."の ようなデータレコードや、"subzone.example."のような委任に関する DS RRに署名する。 認証鍵(Authentication Key): セキュリティ拡張対応リゾルバが既に検証を 済ませた、したがってデータ認証に使用することができる公開鍵。 セキュリティ拡張対応リゾルバが認証鍵を入手する方法は3つある。 まず、リゾルバは一般に設定によって少なくとも1つは公開鍵を知っている。 この設定データは公開鍵そのものであるか、またはDS RR内にあるような 形式の公開鍵のハッシュ値である("信頼のアンカー"参照)。 次に、リゾルバは認証済みの公開鍵を使用して、DS RRとそのDS RRが 参照するDNSKEY RRとを検証する場合がある。さらに、ある新しい公開鍵が 検証済みの他の公開鍵に対応する秘密鍵によって署名されたと判断できる 場合がある。リゾルバが新しい公開鍵を認証すべきか判断する際には、常に リゾルバが動作するローカルポリシーの指針にしたがわなければならない ことに注意してもらいたい。ローカルポリシーが、"リゾルバが署名を検証 できた新しい公開鍵は全て認証する"という単純なものであったとしても、 リゾルバはその指針にしたがわなければならない。 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]参照)。 セキュリティの島はセキュリティ対応ネームサーバによって供給され、 委任した任意の子ゾーンに対して認証の連鎖を提供することもできる。 セキュリティの島またはその下位ゾーンからの応答は、それらのゾーンの 認証鍵がDNSプロトコル以外の信頼できる手段で認証可能な場合にだけ 認証できる。 鍵署名鍵(KSK: Key Signing Key): 与えられたゾーンが持つ1つ以上の認証鍵に 署名する秘密鍵に対応する認証鍵。通常鍵署名鍵に対応する秘密鍵が ゾーン署名鍵に署名し、そのゾーン署名鍵の秘密鍵に相当する鍵が 順次他のゾーンデータに署名するという手順になる。ローカルポリシーが ゾーン署名鍵を頻繁に変更するよう要求する場合があるが、その場合でも 鍵署名鍵はより安定した安全なエントリー地点をゾーンに提供するために、 より長い有効期間を持つことができる。認証鍵を鍵署名鍵であると 明示するかどうかは純粋に運用上の問題である。DNSSECの検証は 鍵署名鍵とDNSSEC認証鍵を区別しないし、1つの鍵を鍵署名鍵と ゾーン署名鍵の両方に使用することもできる。鍵署名鍵については [RFC3757]に詳しい記述がある。ゾーン署名鍵の項も参照のこと。 Arends, et al. Standards Track [Page 4] RFC 4033 DNS Security Introduction and Requirements March 2005 検証機能無しセキュリティ対応スタブリゾルバ(Non-Validating Security-Aware Stub Resolver): 本文書と関連文書に記述される処理について、その大半を 実行するために1つ以上のセキュリティ対応再帰ネームサーバを信頼する セキュリティ対応スタブリゾルバ。特に検証機能無しセキュリティ対応 スタブリゾルバは、DNS問合わせを送信し、DNS応答を受信し、自身に代わって サービスを提供するセキュリティ対応再帰ネームサーバと安全なチャネルを 確立することができるものである。セキュリティ対応スタブリゾルバの項 および検証機能付きセキュリティ対応スタブリゾルバの項も参照のこと。 検証機能無しスタブリゾルバ(Non-Validating Stub Resolver): 検証機能無しセキュリティ対応スタブリゾルバを若干簡略化した呼称。 セキュリティ対応ネームサーバ(Security-Aware Name Server): ([RFC1034]の セクション2.4で定義する)ネームサーバの役割を果たすものでかつ、本文書と 関連文書で定義するDNSセキュリティ拡張を理解するもの。具体的に言うと、 セキュリティ対応ネームサーバとは、DNS問合わせを受信し、DNS応答を 送信し、EDNS0メッセージサイズ拡張([RFC2671])とDOビット([RFC3225])を サポートし、本文書と関連文書で定義するRRタイプとメッセージヘッダー ビットをサポートするものである。 セキュリティ対応再帰ネームサーバ(Security-Aware Recursive Name Server): セキュリティ対応ネームサーバとセキュリティ対応リゾルバの役割を 両方とも提供するもの。使いにくいが同じ意味の言い回しとしては "再帰的なサービスを提供するセキュリティ対応ネームサーバ"が挙げられる。 セキュリティ対応リゾルバ(Security-Aware Resolver): ([RFC1034]の セクション2.4で定義する)リゾルバの役割を果たすものでかつ、本文書と 関連文書で定義するDNSセキュリティ拡張を理解するもの。具体的に言うと、 セキュリティ対応リゾルバとは、DNS問合わせを送信し、DNS応答を受信し、 EDNS0メッセージサイズ拡張([RFC2671])とDOビット([RFC3225])をサポートし、 DNSSECサービスを提供するために本文書と関連文書が定義するRRタイプと メッセージヘッダービットを使用できるものである。 セキュリティ対応スタブリゾルバ(Security-Aware Stub Resolver): ([RFC1034]のセクション5.3.1で定義する)スタブリゾルバの役割を果たす ものでかつ、セキュリティ非対応スタブリゾルバでは利用できない 付加的サービスを提供するために本文書と関連文書が定義するDNSセキュリティ 拡張を充分理解するもの。セキュリティ対応スタブリゾルバは "検証機能付き"か"検証機能無し"のどちらかである。前者は自分自身で DNSSEC署名を検証しようと試みるが、後者はその処理を自分で行う代わりに 使用するセキュリティ対応ネームサーバを信頼する。検証機能付き スタブリゾルバの項と検証機能無しスタブリゾルバの項も参照のこと。 Arends, et al. Standards Track [Page 5] RFC 4033 DNS Security Introduction and Requirements March 2005 セキュリティ非対応(Security-Oblivious) <何か>: セキュリティ対応ではない <何か>。 署名付きゾーン(Signed Zone): ゾーンのRRsetがDNSKEY、RRSIG(Resource Record Signature)、NSEC(Next Secure)、(任意で)DSレコードから適切に構成されて おり、かつそのRRsetが署名付きであるもの。 信頼のアンカー(Trust Anchor): あらかじめ設定されたDNSKEY RRまたは DNSKEY RRのハッシュを持つDS RR。検証機能付きセキュリティ対応 リゾルバは、署名付きDNS応答への認証の連鎖を構築する際に、この公開鍵 またはハッシュ値を開始点として使用する。一般に、検証機能付きリゾルバは DNSプロトコル以外の安全かつ信頼できる手段によって、この信頼の アンカーの初期値を入手しなければならない。また、信頼のアンカーが 存在するということは、リゾルバは信頼のアンカーが指し示すゾーンを 署名付きのものとして扱うべきであることを意味する。 署名無しゾーン(Unsigned Zone): 署名が無いゾーン。 検証機能付きセキュリティ対応スタブリゾルバ(Validating Security-Aware Stub Resolver): セキュリティ対応リゾルバでありかつ、問合わせを 再帰検索モードで送信するが、署名の検証については使用するセキュリティ 対応再帰ネームサーバを盲目的に信頼するのではなく、自分自身で検証処理を 行うもの。セキュリティ対応スタブリゾルバの項および検証機能無し セキュリティ対応スタブリゾルバの項も参照のこと。 検証機能付きスタブリゾルバ(Validating Stub Resolver): 検証機能付きセキュリティ対応スタブリゾルバを若干簡略化した呼称。 ゾーン頂点(Zone Apex): ゾーンカットの子側を指す用語。委任点の項も参照 のこと。 ゾーン署名鍵(ZSK: Zone Signing Key): ゾーン署名に使用する秘密鍵に 対応する認証鍵。一般に、ゾーン署名鍵はDNSKEY RRsetに署名する秘密鍵に 対応する鍵署名鍵と同様に、DNSKEY RRsetの一部である。 しかしゾーン署名鍵は鍵署名鍵とは若干異なる用途で使用され、 また有効期間など幾つか異なる点もある。認証鍵をゾーン署名鍵であると 明示するかどうかは純粋に運用上の問題である。DNSSECの検証処理は 鍵署名鍵とDNSSEC認証鍵を区別しないし、1つの鍵を鍵署名鍵とゾーン署名鍵 両方に使用することもできる。鍵署名鍵の項も参照のこと。 Arends, et al. Standards Track [Page 6] RFC 4033 DNS Security Introduction and Requirements March 2005 3. DNSセキュリティ拡張が提供するサービス DNSセキュリティ拡張はDNSデータの生成元(origin)の認証サービスと、 データの完全性保護サービスを提供する。また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 RRを受信したいとする希望を問合わせの際に 明示できるようにするため、DNSSECはEDNSヘッダー内のDNSSEC OK(DO)ビット ([RFC3225])のサポートを必要とする。 これらのサービスは[RFC3833]で記述されるDNSへの脅威の大部分を防御する。 この拡張の制限に関する記述についてはセクション12を参照のこと。 3.1. データ生成元の認証とデータの完全性保護 DNSSECは、暗号化された電子署名をDNS RRsetに関連づけることにより認証機能を 提供する。電子署名は新しいリソースレコードであるRRSIGレコード内に保存 される。一般にゾーンデータに署名するのは単一の秘密鍵だが、複数の鍵を 使用することも可能である。例えば幾つかの異なる電子署名アルゴリズムで 生成された複数の鍵を使用してもよい。もし、セキュリティ対応リゾルバが ゾーンの公開鍵を信頼できる手段で学習したならば、そのリゾルバはゾーンの 署名付きデータを認証することができる。DNSSECにおける重要な考え方として、 ここでゾーンデータに署名する鍵はゾーン自身に関連付けられるものであり、 ゾーンの権威ネームサーバには関連付けられない。([RFC2931]に記述が あるように、DNSトランザクションの認証に使用する公開鍵がゾーン内に 存在することもある。しかしDNSSEC自身はオブジェクトセキュリティ (訳注: データ側で安全を確保するアプローチ)に関する技術であり、 DNSトランザクションのチャネルセキュリティ(訳注: データを転送する経路で 安全を確保するアプローチ)に関連する技術ではない。トランザクション セキュリティに関わる鍵は別のRRタイプに保存される。詳細は[RFC3755]を 参照のこと)。 セキュリティ対応リゾルバは、リゾルバ内に信頼のアンカーを設定として 持つか、または通常のDNSの名前解決のどちらかによって、ゾーンの公開鍵を 学習することができる。後者の手段を可能にするため、公開鍵を新しい リソースレコードであるDNSKEY RRに保存する。ゾーンデータに署名する 秘密鍵は安全に保持されなければならないため、そうすることが実際的で あるならばオフラインで保存すべきであることに注意してもらいたい。 DNSの名前解決を通して信頼できる手段で公開鍵を発見するために、 探索対象の鍵自身は事前に設定された認証鍵か、あらかじめ認証済みの 別の鍵によって署名されていなければならない。セキュリティ対応リゾルバは、 新しく学習した公開鍵から事前に学習済みの認証公開鍵へと連なる 認証の連鎖を形成し、ゾーンデータを認証する。したがって学習済みの 認証公開鍵は、あらかじめリゾルバに設定されていたものか、事前に学習し 検証済みかのどちらかである。 Arends, et al. Standards Track [Page 7] RFC 4033 DNS Security Introduction and Requirements March 2005 設定された信頼のアンカーがゾーン署名鍵であれば、署名したゾーンを認証 する。設定された鍵が鍵署名鍵であれば、ゾーン署名鍵を認証する。 設定された信頼のアンカーが鍵そのものではなく鍵のハッシュ値であれば、 リゾルバはDNS問合わせを通じて鍵を入手しなければならない。セキュリティ対応 リゾルバが認証の連鎖を構築するのを助けるため、セキュリティ対応 ネームサーバはDNS応答メッセージのサイズに余裕があれば、ゾーンの公開鍵に 加えてゾーン公開鍵を認証するために必要な署名を共に送信しようと試みる。 DS(Delegation Signer) RRタイプは、組織の境界をまたぐ委任への署名に 必要な管理作業を簡略化する。DS RRsetは親ゾーン側の委任点に位置し、 委任された子側のゾーン頂点に位置するDNSKEY RRsetに自己署名するために 使用した秘密鍵に対応する公開鍵を提示する。次に子ゾーンの管理者は自己署名 されたDNSKEY RRsetに含まれる1つ以上の公開鍵に対応する秘密鍵を使用して 子ゾーンのデータに署名する。したがって、一般的な認証の連鎖は DNSKEY->[DS->DNSKEY]*->RRsetになる。ここで"*"は0個以上のDS->DNSKEYの 部分的連鎖を意味する。DNSSECは、例えばゾーン内において他のDNSKEY RRに 署名するDNSKEY RRsの層の追加といった、より複雑な認証の連鎖も 許容する。 セキュリティ対応リゾルバは通常事前に設定されたDNS階層のルートの公開鍵 情報に基づき、認証の連鎖をルートから下位のゾーン(leaf zone)に向けて構築 していく。しかし、ローカルポリシーにより、セキュリティ対応リゾルバは ルートの公開鍵ではなく、設定された1つ以上の公開鍵(かまたは公開鍵の ハッシュ値)を使用することができるかもしれないし、またルートの公開鍵が 設定されない場合もある。更に、独善的な理由によって、たとえこの公開鍵が 検証可能な署名によって適切に署名されていても、リゾルバが特定の公開鍵を 使用することを抑制する場合がある。DNSSECは、セキュリティ対応リゾルバが RRsetの署名をDNSSECの枠内で"有効"であるか判断できる仕組みを提供する。 しかし、DNS内の鍵やデータを認証するかどうかは最終的にはローカルポリシーの 問題である。ローカルポリシーは本文書と関連文書が定義するプロトコル拡張を 更に拡大する場合もあり、無効にする場合もある。より詳細な議論については セクション5を参照のこと。 Arends, et al. Standards Track [Page 8] RFC 4033 DNS Security Introduction and Requirements March 2005 3.2. 名前およびタイプの不在証明 セクション3.1に記述したセキュリティの仕組みは、ゾーン内に存在するRRsetに 署名する方法を提供するだけである。同じレベルの認証と完全性を持つ否定的 応答を提供するという問題を解決するためには、新しいリソースレコードタイプ であるNSECレコードを使用する必要がある。NSECレコードにより、名前または タイプ不在時に生成される否定的応答を、他のDNS応答を認証するのと 同じ仕組みでセキュリティ対応リゾルバが認証できるようになる。NSECレコードを 使用するには、ゾーン内のドメイン名が正規に表現され、かつ順序づけがされて いることが必要である。NSECレコードの連鎖はゾーン内に存在するドメイン名間の すき間または"空き空間"を明示的に示し、既存の名前が持つRRsetのタイプを 列挙する。各NSECレコードは、セクション3.1に記述した仕組みで署名され 認証される。 4. DNSセキュリティ拡張が提供しないサービス 元来、DNSは誰が問合わせを発行したかにかかわらず、任意の問合わせに対して 同じ応答を返す、つまりDNS内に存在する全てのデータは閲覧可能(visible)である という前提で設計された。したがって、DNSSECは機密性やアクセス制御リスト、 問合わせ発行者を差別化する他の手段を提供するようには設計されていない。 DNSSECはサービス不能攻撃(denial of service attacks)への防御機能を 何も提供しない。セキュリティ対応リゾルバとセキュリティ対応ネームサーバは 共に暗号処理を利用するという、新たに加わったサービス不能攻撃に対して 脆弱である。詳細についてはセクション12を参照のこと。 DNSセキュリティ拡張は、DNSデータとDNSデータ生成元の認証機能を提供する。 先に概略を説明したこの仕組みは、ゾーン転送や動的更新([RFC2136], [RFC3007]) のような処理を保護するようには設計されていない。これらのトランザクションに 関するセキュリティを考慮した運用には、[RFC2845]と[RFC2931]に記述がある メッセージ認証の仕組みが対応する。 5. DNSSEC文書群の対象範囲とラストホップ問題(Last Hop Issues) 本文書と関連文書は、データ検証者が曖昧さを差し挟まずに状態を決定できる ようにゾーン署名者・セキュリティ対応ネームサーバ・セキュリティ対応 リゾルバの振る舞いを定義する。 検証を行うリゾルバは、以下の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木構造の一部が安全であることを示す信頼の アンカーが存在しない状態。これがデフォルトの運用モードである。 本仕様では、セキュリティ対応ネームサーバが検証機能無しセキュリティ対応 スタブリゾルバに対し、データが不適正であると判明したことを通知する手段 を定義するだけである(RCODE=2, "Server Failure"を使用する。[RFC4035]参照)。 セキュリティ対応ネームサーバがセキュリティ対応スタブリゾルバに対し、 データが安全であると判明したことを通知する仕組みは既に存在する。 (ADビットを使用する。[RFC4035]参照)。 本仕様は、応答が不適正または安全でないとマークされた理由を通知する際に 使用する書式を定義しない。すなわち現在の通知の仕組みは、応答の安全性が 不確定な状態と安全でない状態を区別しない。 セキュリティ対応スタブリゾルバとセキュリティ対応再帰ネームサーバの間で 高度なエラーコードやポリシを交換する手法については、セキュリティ対応 リゾルバとそれを利用するアプリケーション間のインターフェース同様に 今後の課題である。ただし、そのような通信を本仕様が規定しないことが、 署名付きゾーンの普及を抑制するものではなく、また不適正なデータを アプリケーションに通知しないセキュリティ対応再帰ネームサーバの普及を 抑制するものでもないことに注意してもらいたい。 6. リゾルバに関する考慮点 セキュリティ対応リゾルバは、少なくとも実装必須なアルゴリズムの電子署名を 検証するために必要な暗号機能を実行できなければならない。またセキュリティ 対応リゾルバは、先に記述したとおりの手順で、新たに学習したゾーンから 認証鍵に至る認証の連鎖を形成できなければならない。この処理は、必要な DNSKEY、DSおよびRRレコードを得るために、中間のDNSゾーンに対する問合わせを 必要とするかもしれない。認証の連鎖を構築する開始点として使用するため、 セキュリティ対応リゾルバは少なくとも1つは信頼のアンカーを設定として 持つべきである。 Arends, et al. Standards Track [Page 10] RFC 4033 DNS Security Introduction and Requirements March 2005 セキュリティ対応リゾルバと適切な権威ネームサーバが再帰ネームサーバや DNSプロキシーとして動作する中間デバイスによって切り離されている状況で、 再帰ネームサーバまたは中間デバイスがセキュリティ対応ではない場合には、 セキュリティ対応リゾルバは安全なモードでは動作できないかもしれない。 例えば、セキュリティ対応リゾルバのパケットがセキュリティ対応でない DNSプロキシー機能を持つNATデバイスを通して経路付けされる場合、 セキュリティ対応リゾルバは署名付きDNSデータを得たり検証したりするのは 困難であるか不可能だと判断するだろう。DS RRはゾーンカットにおける RRの所有者に関する一般的なDNSのルールにしたがわないため、このような 条件下でDS RRを得るのは特に難しくなるかもしれない。この問題はNAT固有の ものではないことに注意してもらいたい。セキュリティ対応リゾルバと 権威ネームサーバ間に存在するあらゆるセキュリティ非対応のDNSソフトウェアは DNSSECを妨害する。 セキュリティ対応リゾルバが署名無しゾーンまたはセキュリティ対応でない ネームサーバに依存しなければならない場合、リゾルバはDNS応答を 検証できないかもしれないため、未検証の応答を受理するかどうかについて ローカルポリシーの判断を必要とする。 署名付きデータを署名の有効期限を越えてキャッシュしないように、 セキュリティ対応リゾルバはデータのTTLを決める際に署名の有効期限を 考慮すべきである。ただしセキュリティ対応リゾルバの時計が誤っている 可能性も許容すべきである。したがって、セキュリティ対応再帰 ネームサーバ内のセキュリティ対応リゾルバは、DNSSEC CD(checking disabled) ビット([RFC4034])に細心の注意を払わなければならない。これは、この再帰 ネームサーバのクライアントになっている他のセキュリティ対応リゾルバに 有効な署名を伝達するのを阻害しないためである。安全な再帰サーバが CDビットが設定された問合わせを処理する方法については[RFC4035]を 参照のこと。 7. スタブリゾルバに関する考慮点 プロトコルで厳密に要求されているわけではないが、ほとんどの DNS問合わせはスタブリゾルバで生成される。定義によれば、スタブリゾルバとは DNS名前解決処理の大半を再帰ネームサーバに委託するために再帰問合わせモードを 使用する、最小のDNSリゾルバである。スタブリゾルバは広範囲で使用されている ため、DNSSECアーキテクチャはスタブリゾルバを考慮しなければならない。 しかし、スタブリゾルバで必要なセキュリティ機能はセキュリティ対応の反復型 リゾルバで必要なセキュリティ機能とは幾つかの点で異なる。 スタブリゾルバがセキュリティ非対応であったとしても、そのスタブリゾルバが 使用する再帰ネームサーバがセキュリティ対応であればDNSSECの恩恵を受けられる かもしれない。しかしDNSSECサービスを実際にあてにするのであれば、スタブ リゾルバは使用する再帰ネームサーバとネームサーバへの通信チャネルの両方を 信頼しなければならない。幾つかある問題の中で第1のものはローカルポリシーに 関するものである。セキュリティ非対応スタブリゾルバは自分ではDNSSECの有効性 検査を行わないため、使用する再帰ネームサーバを全面的に信頼する以外にない。 もう1つの問題は何らかのチャネルセキュリティの仕組みを必要とする。 SIG(0)([RFC2931])やTSIG([RFC2845])のようなDNSトランザクション認証の仕組みを 適切に使用したり、IPsecを適切に使用すれば充分だろう。特定の実装では、 OS固有のプロセス間通信の仕組みのような別の選択肢も利用可能かもしれない。 チャネルには機密性は必要ないが、データの完全性保護とメッセージ認証は 必要である。 再帰ネームサーバと通信チャネルの両方を信頼するセキュリティ対応スタブ リゾルバは、受信した応答メッセージのメッセージヘッダ内にある AD(Authenticated Data)ビットが設定されているかどうかを調査してもよい。 再帰ネームサーバが応答の回答部(Answer section)と権威部(Authority section)の データ全てについて署名を検証できたのかを判断するヒントとして、 スタブリゾルバはこのフラグビットを利用することができる。 何らかの理由でセキュリティ対応スタブリゾルバが使用する再帰ネームサーバと 信頼関係を築けない場合に、スタブリゾルバが選択可能な対処がもう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はその機能または定義を 変更しない。キャッシングリゾルバは、そのリゾルバがセキュリティ対応であるか どうかに関わらず、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 RRをメッセージに含めると容易にUDPメッセージ切り詰め (truncate)とTCPへの後退が生じるため、セキュリティ対応ネームサーバは EDNSの"sender's UDP payload"の仕組みをサポートしなければならない。 Arends, et al. Standards Track [Page 13] RFC 4033 DNS Security Introduction and Requirements March 2005 DNSSECの鍵ペアそれぞれについて、可能であれば秘密鍵をオフラインで 保持すべきであるが、DNSの動的更新が有効なゾーンでは不可能である。 動的更新を行う場合、ゾーンのプライマリマスタサーバはゾーン更新時に 再署名を行わなければならないため、ゾーン署名鍵の秘密鍵部分は オンラインで保持されなければならない。これはゾーンのDNSKEY RRsetを ゾーン署名鍵と鍵署名鍵に分けることが有益な例である。このような状態で あっても鍵署名鍵は依然としてオフラインで保持することができる。 ゾーン転送時にゾーン全体の完全性を保護するには、DNSSECだけでは不十分 である。なぜなら署名付きゾーンであっても子ゾーンがあれば署名が無く 権威を持たないデータを含むからである。したがってゾーン保守作業には 付加的な仕組み(おそらくはTSIG、SIG(0)あるいはIPsecのようなチャネル セキュリティ形態のもの)が必要となる。 10. DNSセキュリティ拡張の関連文書 DNSSECの文書群は、より大きなDNS基本プロトコル文書群に属する幾つかの 主要なグループに分割できる。 "DNSSECプロトコル文書群"は、DNSセキュリティ拡張の中心部分を成す3つの 文書を指す。 1. DNSセキュリティ拡張の紹介とその要件 (本文書) 2. DNSセキュリティ拡張で使用するリソースレコード [RFC4034] 3. DNSセキュリティ拡張のためのプロトコル変更 [RFC4035] 更に、DNSセキュリティ拡張の中心部分に追加または変更を行う文書もこの分類に 属する。例えばセキュリティ対応スタブリゾルバと上流のセキュリティ対応 再帰ネームサーバ間の通信に関する今後の成果が考えられる。 "電子署名アルゴリズムの実装仕様"文書群は、特定の電子署名アルゴリズムを DNSSECリソースレコードフォーマットに適合する形で実装する手法を記述した 文書群である。文書群に属する文書それぞれが特定の電子署名アルゴリズム 1つを扱う。この実装仕様の中心部分が規定された段階で定義されたアルゴリズムの リストについては、[RFC4034]の付録"DNSSECアルゴリズムとダイジェスト タイプ"を参照のこと。 "トランザクション認証プロトコル"文書群は、秘密鍵の確立と検証などを 含めてDNSメッセージ認証について扱う文書群である。厳密には関連文書で定義 するDNSSEC仕様の一部ではないが、DNSSECとの関係を示すためにこの文書群に ついても記述した。 Arends, et al. Standards Track [Page 14] RFC 4033 DNS Security Introduction and Requirements March 2005 最後の文書群である"新しいセキュリティの使用法"は、提案したDNSセキュリティ 拡張を別のセキュリティ関連の目的で使用する方法を模索するものである。 DNSSECはこれら新しい使用法に対して直接的なセキュリティは提供しないが、 新しい使用法の支援はできるかもしれない。DNSを使用した証明書の保存と配布 ([RFC2538])の方法に関する文書はこの文書群に属する。 11. IANAに関する考慮点 この概略を記した文書では、IANAに関する新たな考慮すべき事項は存在しない。 DNSSEC導入に際してIANAに関して考慮すべき事項の全容については[RFC4034]を 参照のこと。 12. セキュリティに関する考慮点 本文書はDNSセキュリティ拡張を紹介し、新しいセキュリティレコードと DNSプロトコルの修正に関する文書群について記述する。DNSセキュリティ拡張は、 RRsetに電子署名を付与することにより、DNSデータの生成元認証機能と データ完全性保護機能を提供する。本セクションではこの拡張の制限について 述べる。 本文書と関連文書で定義しているように、セキュリティ対応リゾルバがDNS応答を 検証するためには、信頼できる開始地点から応答ゾーンまで連なる全ゾーンが 署名付きでなければならない。また名前解決処理に関わる全てのネームサーバと リゾルバはセキュリティ対応でなければならない。セキュリティ対応リゾルバは、 署名無しゾーンから生成された応答や、セキュリティ非対応のネームサーバが 提供するゾーンから生成された応答を検証できない。またセキュリティ対応 リゾルバが使用する再帰ネームサーバがセキュリティ対応でない場合は いかなるDNSデータも検証できない。セキュリティ対応リゾルバが必要な認証鍵を 入手できず、検証できなかった場合のように認証の連鎖に断絶が生じた場合、 セキュリティ対応リゾルバはその認証の連鎖の影響を受けるDNSデータを検証 できない。 本文書では、IPsecで保護されたチャネルの利用、TSIG([RFC2845])またはSIG(0) ([RFC2931])のようなDNSトランザクション認証の仕組みといった、 DNS問合わせにセキュリティを付加する別の方法について簡単に記述しているが、 トランザクションセキュリティはDNSSECそれ自体の一部ではない。 検証機能無しセキュリティ対応スタブリゾルバは、自身ではDNSSEC署名検証を 実行しないと定義されている。したがって、署名検証を代理で行うセキュリティ 対応再帰ネームサーバ上における攻撃、署名検証を代理で行うセキュリティ対応 再帰ネームサーバからの攻撃、リゾルバからセキュリティ対応再帰ネームサーバ までの通信路における攻撃に対して脆弱である。最後に挙げた脅威を防御する ために、検証機能無しセキュリティ対応スタブリゾルバは何らかの形態の チャネルセキュリティを使用すべきである。前者二つの脅威に対する防御法として 唯一知られているものは、セキュリティ対応スタブリゾルバが自分自身で 署名の検証を実行することである。定義によればこの時点でこのリゾルバは 検証機能無しセキュリティ対応スタブリゾルバではなくなる。 Arends, et al. Standards Track [Page 15] RFC 4033 DNS Security Introduction and Requirements March 2005 DNSSECはサービス不能攻撃を防御しない。DNSSECを導入することにより、 セキュリティ対応リゾルバとセキュリティ対応ネームサーバは共に暗号処理を 利用したサービス不能攻撃に対して脆弱になる。なぜなら、攻撃者はDNSSECの 仕組みを利用して目標とするマシンのリソース消費を試みられるからである。 暗号処理を利用した攻撃には少なくとも2つの形態が考えられる。 攻撃者は、応答メッセージ内のRRSIG RRを改ざんするかまたは不必要に複雑な 認証の連鎖を構築することにより、セキュリティ対応リゾルバの署名検証コード 実行時にリゾルバのリソースを消費させることができる可能性がある。 また、DNS動的更新をサポートするセキュリティ対応ネームサーバに対して、 過剰な頻度でゾーン内の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. 謝辞 本文書はDNS Extensionsワーキンググループメンバのインプットとアイディア から作成された。DNSSECが開発途上であった10年間に貢献してくれた全員を 列挙することはできないが、著者らは以下の人々の本文書と関連文書に対する 貢献とコメントに対して特に感謝の意を表したい。 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、Suzanne Woolf。 上記のリストが不完全であることは明らかである。名前を挙げられなかった 人々に対してここにお詫びする。 14. 参考文献 14.1. 必須の参考文献 [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. 有用な参考文献 [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 著者達の連絡先 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 完全な著作権表示 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. 知的所有権に関する表示 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. 謝辞 RFCエディタの活動に対する資金は現在Internet Societyによって提供されて いる。 Arends, et al. Standards Track [Page 21] RFC4033-ja.txt revision 1.0 この翻訳文に関するお問い合わせは dnstech-info@jprs.jp までご連絡下さい。 Japan Registry Service Co., Ltd. http://jprs.jp/tech/