ネットワーク ワーキング グループ D. Eastlake Request for Comments: 2535 　IBM 廃棄: 2065 1999年3月 更新: 2181、1035、1034 分類: 標準化過程　 Domain Name Systemセキュリティ拡張機能 このメモの位置づけ このドキュメントはインターネットコミュニティに対してインターネット標準 化過程プロトコルの詳細を示し、内容の改善のために議論と提案を求めるもの である。標準化の段階と状態については「Internet Official Protocol Standards」(STD 1)の最新版を参照ください。このメモの配布は無制限です。 著作権表示 Copyright (C) The Internet Society (1999). All Rights Reserved. 要旨 Domain Name System (DNS)に対する機能拡張を説明する。DNSは、暗号化デジ タル署名の使用によりセキュリティ対応リゾルバおよびアプリケーションに、 データの保全と認証を提供するものである。これらのデジタル署名は、リソー スレコードとして安全保護ゾーンに含まれる。セキュリティは、ある場合には セキュリティ未対応のDNSサーバによって提供することもできる。 機能拡張は、DNSにおける認証パブリック キーのストレージを提供する。この キーのストレージは、DNSセキュリティの他に、一般のパブリックキー配布サ ービスをサポートすることができる。格納されたキーは、最初に構成されたも のに加えて、ゾーンの認証キーを認識するためにセキュリティ対応リゾルバを 有効にする。DNS名に関連付けられたキーは、他のプロトコルをサポートする ために取得すことができる。さまざまなキーの種類とアルゴリズムのための規 定が設けられている。 さらに、セキュリティ機能拡張は、DNSプロトコルのトランザクションと要求 に対するオプションの認証を提供する。 このドキュメントは、初期導入者と潜在的ユーザーからのRFC 2065に関するフ ィードバックを取り入れたものである。 Eastlake Standards Track [Page 1] RFC 2535 DNS Security Extensions March 1999 謝辞 DNSセキュリティに対する以下の方々(アルファベット順)の多大な貢献と提案 に深く感謝する。 James M. Galvin John Gilmore Olafur Gudmundsson Charlie Kaufman Edward Lewis Thomas Narten Radia J. Perlman Jeffrey I. Schiller Steven (Xunhua) Wang Brian Wellington 目次 要旨.........................................................1 謝辞.........................................................2 1. 内容の概観................................................4 2. DNS拡張機能の概観.........................................5 2.1 提供されないサービス.....................................5 2.2 キー配布.................................................5 2.3 データ発信元の認証と保全性...............................6 2.3.1 SIGリソース レコード...................................7 2.3.2 名前および種類の不存在の認証...........................7 2.3.3 生存時間についての特別な考慮点.........................7 2.3.4 委任ポイントについての特別な考慮点.....................8 2.3.5 CNAMEについての特別な考慮点............................8 2.3.6 ゾーン以外の署名者.....................................9 2.4 DNSトランザクションおよび要求の認証......................9 3. KEYリソース レコード.....................................10 3.1 KEY RDATA形式...........................................10 3.1.1 オブジェクト タイプ、DNS名、キー......................11 3.1.2 KEY RRフラグ フィールド...............................11 3.1.3 プロトコル オクテット.................................13 3.2 KEYアルゴリズム番号の指定...............................14 3.3 フラグ、アルゴリズム、およびプロトコル バイトの対話.....15 3.4 ゾーンが安全かどうかの判断..............................15 3.5 応答の構造におけるKEY RR................................17 4. SIGリソース レコード.....................................17 4.1 SIG RDATAの形式.........................................17 4.1.1 Type Coveredフィールド................................18 4.1.2 Algorithm Numberフィールド............................18 4.1.3 Labelsフィールド......................................18 4.1.4 Original TTLフィールド................................19 Eastlake Standards Track [Page 2] RFC 2535 DNS Security Extensions March 1999 4.1.5 署名の Expirationと Inception フィールド..............19 4.1.6 Key Tagフィールド.....................................20 4.1.7 Signer's Nameフィールド...............................20 4.1.8 Signatureフィールド...................................20 4.1.8.1 トランザクションおよび要求のSIGの計算...............21 4.2 応答の構造におけるSIG RR................................21 4.3 応答とSIG RRの処理......................................22 4.4 署名の存続期間、終了、TTL、有効性.......................23 5. 非存在の名前とタイプ.....................................24 5.1 NXTリソース レコード....................................24 5.2 NXT RDATAの形式.........................................25 5.3 ワイルドカードによる追加の複雑性........................26 5.4 例......................................................26 5.5 委任ポイントについての特別な考慮点......................27 5.6 ゾーン転送..............................................27 5.6.1 全体ゾーン転送........................................28 5.6.2 増分ゾーン転送........................................28 6. 安全な解決方法とADおよびCDビット.........................29 6.1 ADおよびCDヘッダ ビット.................................29 6.2 静的に構成されるキー....................................31 6.3 DNSを介した連鎖.........................................31 6.3.1 キーを介したチェイン..................................31 6.3.2 競合データ............................................33 6.4 確実な時刻..............................................33 7. セキュリティRRのASCII表現................................34 7.1 KEY RRの表現............................................34 7.2 SIG RRの表現............................................35 7.3 NXT RRの表現............................................36 8. リソース レコードの正規形式と配列........................36 8.1 RRの正規形式............................................36 8.2 正規のDNS名配列.........................................37 8.3 RRsetにおけるRRの正規配列...............................37 8.4 RRタイプの正規配列......................................37 9. 適合性...................................................37 9.1 サーバの適合性..........................................37 9.2 リゾルバの適合性........................................38 10. セキュリティに関する考慮点..............................38 11. IANAに関する考慮点......................................39 References..................................................39 Author's Address............................................41 Appendix A: Base 64エンコード...............................42 Appendix B: RFC 0265からの変更..............................44 Appendix C: キー タグの計算.................................46 Full Copyright Statement....................................47 Eastlake Standards Track [Page 3] RFC 2535 DNS Security Extensions March 1999 1. 内容の概観 このドキュメントは、Domain Name System (DNS)プロトコルの機能拡張とパブ リック キーの配布を標準化するものである。特にRFC 1033、1034、1035およ びそれ以降のRFCで説明されるDomain Name Systemについて読者が知識を持っ ていることを前提としている。これらの機能拡張の以前のバージョンはRFC 2065で説明されている。本ドキュメントではこのRFCを置き換え、初期実装の 経験と潜在的ユーザーからの要求を取り入れている。 セクション2では、機能拡張の概要とキー配布、データ発信元の認証、それら が提供するトランザクションと要求のセキュリティについて説明する。 セクション3では、KEYリソース レコード、その構造、DNSの応答での使用につ いて検討する。これらのリソース レコードは、DNSで名前が付けられるエンテ ィティのパブリック キーを表し、キー配布のために使用される。 セクション4では、SIGデジタル署名のリソース レコード、その構造、DNSの応 答での使用について検討する。これらのリソース レコードは、DNSの他のリソ ース レコードを認証するために使用され、任意によりDNSのトランザクション と要求を認証するために使用される。 セクション5では、NXTリソース レコード(RR)と、全体および差分ゾーン転送 を含むDNSの応答におけるその使用について検討する。NXT RRは、名前の存在 または既存の名前RRタイプに対する認証済みの拒否を認める。 セクション6では、DNS要求を安全に解決するために開始キーまたは複数キーに よりリゾルバをどのように構成できるかについて検討する。セキュリティ対応 とセキュリティ未対応のさまざまな組合せに対するリゾルバとサーバの対話が 論じられる。リゾルバとサーバーの間の信号方式については2つの追加DNSヘッ ダ ビットが定義されている。 セクション7では、マスタ ファイルおよび他の場所で使用するためのセキュリ ティ リソース レコードのASCII表現について論じる。 セクション8では、DNSセキュリティを目的とした正規形式とRRの配列について 検討する。 セクション9では、リゾルバとサーバの適合のレベルを定義する。 セクション10では、全体的なセキュリティの考慮点をいくつか説明する。 セクション11では、このドキュメントで定義されるパラメータに追加された値 の割当てについてIANAの考慮点を詳述する。 Eastlake Standards Track [Page 4] RFC 2535 DNS Security Extensions March 1999 付録Aでは、このドキュメントで定義されるいくつかのRRのファイル表現に使 用されるBase 64エンコーディングの詳細を説明する。 付録Bでは、このメモとRFC2065の間の変更点を要約する。 付録Cでは、ほとんどのSIG RRのキー タグとして使用されるサンプル チェッ クサムの計算方法を示す。 このドキュメントにおける「しなければならない」、「してはならない」、 「すべきである」、「すべきでない」、「推奨される」、「してもよい」、 「オプション」というキーワードは、[RFC2119]に記述される通りに解釈する ものとする。 2. DNS拡張機能の概観 Domain Name System (DNS)プロトコル セキュリティ拡張は、以下のセクショ ン2.2で説明するキー配布、セクション2.3で説明するデータ発信元の認証、セ クション2.4で説明するトランザクションと要求の認証という3つの異なるサー ビスを提供する。 また「Time to Live」に関連した特別な考慮点であるCNAMEと委任ポイントに ついて、セクション2.3で説明する。 2.1 提供されないサービス DNSのデータが公開され、DNSはすべての問い合わせに対して同じ応答を行うこ とは、DNSの設計思想の一部である。この思想に従って、何らかのアクセス制 御リストまたは他の区別手段を含める試みは一切行われていない。 問い合わせまたは応答を秘密にする努力は一切行われていない。(このサービ スは、IPSEC [RFC 2401]、TLS、または他のセキュリティ プロトコルにより利 用できる。) サービス拒否に対する保護は提供されない。 2.2 キー配布 キーをDNS名に関連付けるためのリソース レコード形式が定義されている。こ れにより、DNSは、DNSセキュリティ自体および他のプロトコルでサポートされ るパブリック キー配布メカニズムとして使用することができる。 KEYリソース レコード(RR)の構文はセクション3で定義されている。この構文 には、アルゴリズム識別子、実際のパブリック キー パラメータ、さまざまな フラグが含まれ、これらのフラグにはキーが関連付けられているエンティティ の種類を示すものや、そのエンティティに関連付けられているキーはないこと を示すものがある。 Eastlake Standards Track [Page 5] RFC 2535 DNS Security Extensions March 1999 セクション3.5で説明する状況では、セキュリティ対応のDNSサーバは、必要 な要求の数を最小限にするため、実際に要求されたリソース レコードと共に 追加情報として自動的にKEYリソースを返すことを試みる。 2.3 データ発信元の認証と保全性 認証は、DNSの暗号化生成によるデジタル署名のリソース レコード セット (RRsets [RFC 2181])と関連付けることで提供される。通常、ゾーン全体を認 証するプライベート キーが1つ存在するが、異なるアルゴリズムや署名者など のために複数のキーが存在する場合もある。セキュリティ対応リゾルバの信頼 性によりゾーンのパブリック キーが認識された場合、そのゾーンから読み込 まれた署名付きデータ のため、リゾルバはそれが適切な権限を持つものと認 証することができる。最も安全な方法は、ゾーンのパブリック キーをオフラ インの状態に置き、ゾーンのレコードすべてを定期的に署名し直すために使用 することである。ただし、DNSプライベート キーをオンラインにすることが必 要な動的更新 [RFC 2136、2137]の場合もある[RFC 2541]。 データ発信元認証キーはゾーンに関連付けられ、データのコピーを保存してい るサーバには関連付けられない。これは、セカンダリ サーバの危険や、キー がオフラインである場合のゾーンのプライマリ サーバの危険は、データが 本物であるかどうか判断できるというリゾルバの信頼性には必ずしも影響しな いことを意味する。 リゾルバは、ゾーンのパブリック キーをDNSから読み取るか静的に構成するこ とで認識することができる。DNSから読み取ることでパブリック キーを確実に 認識するため、キー自体がリゾルバの信頼するキーで署名されなければならな い。リゾルバには、最低限、開始ポイントとして1つのゾーンを認証するパブ リック キーが構成されなければならない。DNSツリーの仲介ゾーンが安全であ り、それらの署名付きキーがアクセス可能であれば、リゾルバはこの開始ポイ ントから他のゾーンのパブリック キーを安全に読み取ることができる。 データ発信元の認証と整合性を追加する場合、署名リソース タイプとキー配 布に必要なキー リソース タイプを追加する以外に、「接続中」のDNSプロト コルを変更する必要はない。(データ不存在の認証にも、2.3.2で説明するNXT RRが必要となる。) このサービスは、追加リソース タイプをサポートできれ ば、既存のリゾルバとキャッシング サーバの実装によりサポートできる(セク ション9参照)。1つの例外は、安全なゾーンのCNAME参照は、セキュリティ未対 応のサーバからのものである場合、認証されないことである(セクション2.3.5 参照)。 Eastlake Standards Track [Page 6] RFC 2535 DNS Security Extensions March 1999 認証する情報を取得するときに署名が個別に取得され検証される場合、サーバ への経路が長くなり、パフォーマンスに影響が出る。セキュリティ対応サーバ は、必要な署名の送信を試みることでこのパフォーマンス低下を緩和する(セク ション4.2参照)。 2.3.1 SIGリソースレコード SIGリソース レコード(署名)の構文はセクション4で説明されている。SIGリソ ース レコードは、署名されるRRsetを暗号化して署名者と有効間隔に送信する。 安全保護されたゾーンの各名前は、glueアドレスRRと委任ポイントNS RRのSIG リソース レコードを除き、その名前の下にある各リソース タイプの最低1つ のSIGリソース レコードに関連付けられる。セキュリティ対応サーバは、取得 されたRRと共に、対応するSIGを返すことを試みる。サーバがセキュリティ対 応でない場合、リゾルバは名前に対するすべてのSIGレコードを取得し、リゾ ルバが関与するリソース レコード セットに署名するレコードを選択しなけれ ばならない。 2.3.2 名前および種類の不存在の認証 上記のセキュリティ メカニズムは、ゾーン内の既存のRRsetに署名する手段を 提供するにすぎない。「データ発信元」の認証は、ゾーンにドメイン名が存在 しないこと、または既存の名前の種類が存在しないことを明示的に示さない。 この相違は、ゾーンに存在しない名前の範囲と、その範囲の直前にある既存の 名前の種類が存在しないことを正当にアサートするNXT RRによって埋められる。 NXT RRについては下のセクション5で扱う。 2.3.3 生存時間についての特別な考慮点 デジタル署名は、最初に署名された時から署名が検証された時の間にデータに 変更があった場合、検証に失敗する。これは、リソース レコードのTime-to- Live (TTL)フィールドがキャッシュされるときにリソース レコードに照合印 を付けたいというユーザーの希望に反する。 これは生存時間をデジタル署名に入れないことで回避できるが、そのために悪 意のあるサーバが気付かれずに任意に長いＴＴＬ値を設定できることが可能 になる。この代わりに、署名には「元の」TTLを含めるようにし、現在のTTLと 共にそのデータを伝達する。この方法の下では悪意のあるサーバはTTLを操 作できるが、セキュリティ対応リゾルバは使用するTTL値を最初に署名された 値にすることができる。署名は別に、署名開始時刻と署名終了時刻を含む。 Eastlake Standards Track [Page 7] RFC 2535 DNS Security Extensions March 1999 絶対的時刻を認識するリゾルバは、署名が有効かどうかを安全に判断できる。 ただし、TTLの代替として署名終了のみに依存することはできない。TTLが主に データベースの一貫性メカニズムであり、TTLに依存するセキュリティ未対応 サーバがサポートされなければならないためである。 2.3.4 委任ポイントについての特別な考慮点 DNSセキュリティは、ゾーン管理者が持つ特別なプライベート キーによって署 名される各エントリ(RRset)を持つゾーン所有者の完全な管理の下で、データ の単位として各ゾーンを見なす。しかし、DNSプロトコルは、下位ゾーンの最 上位ノード(つまり委任ポイント)でもあるゾーンの葉ノードを、その下位ゾー ンに「実際に」属しているものと見なす。これらのノードは、2つのマスタ ファイルで発生し、上位および下位にあるゾーンのキーによって署名されるRR を持つ場合がある。取得の際は、特に1つのサーバが委任ポイントの上位お よび下位ゾーンに応答することも可能であるため、これらのRRとSIGを混合し て得ることができる。[RFC 2181] 上位ゾーンが安全であれば、各下位ゾーンについて上位ゾーンによって署名さ れるゾーンＫEY RRがなければならない。これは通常、下位ゾーンに現れるが、 上位ゾーンに含まれる場合もある。しかし、セキュリティRRを追加するように 変更できない、または変更されない下位ゾーンの場合、上位ゾーンが安全であ れば、安全保護されていないことを宣言するKEYが上位ゾーンの署名に含まれ なければならない。他の１つのRRタイプを除くすべてについては、下位ゾーン からのデータの信頼性が高くなるため、下位ゾーンのKEY RRは上位ゾーンがそ こに現れていればその上位ゾーンで署名されるべきである。NSおよびglueアド レスRRは、下位ゾーンのみで署名されるべきである。SOAと所有者としてゾー ン名を持つ他のRRは、下位ゾーンにのみ存在するべきであり、そこでのみ署名 されるべきである。NXT RRタイプは、例外的な場合であり、常に異なる場所に 現れ、上位ゾーンおよび下位ゾーンが安全であればその両方に権限を与えられ た形で現れる。これはセクション5で説明する通りである。 2.3.5 CNAMEについての特別な考慮点 CNAME RRとして同一の所有者名を持つセキュリティ関連のRRがセキュリティ未 対応サーバから取得される場合の問題がある。特に、CNAMEまたは他のタイ プのための初期の取得によって、関連するSIG、KEY、NXT RRが取得されないこ とがある。CNAME以外の取得されたタイプについては、CNAME（またはCNAMEの チェーン）のターゲット名においてそのタイプが取得され、再びCNAMEを返す。 特に、タイプSIGに対する特定の取得では、SIGがある場合、元のCNAMEドメイ ン名ではなく対象名でSIGを取得する。 Eastlake Standards Track [Page 8] RFC 2535 DNS Security Extensions March 1999 DNSのCNAMEに対してはセキュリティ対応サーバが安全に使用されなければな らない。セキュリティ対応サーバは、(1)CNAME RRと共にKEY、SIG、NXTを許 可し、(2)タイプCNAMEの取得と共にこれらのタイプの取得に関するCNAME処理 を制限し、(3)問い合わせを解決する際に見つかったCNAMEを認証するSIG RRを 自動的に返さなければならない。これは、CNAME RRが存在しする他のRRタイプ を禁止していた以前のDNS標準[RFC 1034/1035]からの変更である。 2.3.6 ゾーン以外の署名者 SIGリソース レコードの署名者が、ゾーンを認証するために使用された以前の キーのいずれでもない場合がある。 第一は、動的更新[RFC 2136]（あるいは安全な認証を要求する将来のリクエス ト）をサポートする場合である。この場合、エンティティがそのレコードを認 証/更新することが許可され[RFC 2137]、ゾーンはゾーン キーがオンラインで ないモードで動作している。DNSにはエンティティのパブリック キーが存在し なければならず、エンティティのキーで署名されなければならないが、他のRR はエンティティのキーで署名されることができる。 第二の場合は、セクション2.4で説明するトランザクションと要求の認証のサ ポートである。 さらに、署名は、DNS以外のアプリケーションによる使用のためにDNS内のリソ ース レコードに含まれることがある。DNSに関連付けられた署名は、データが ゾーン所有者の権限で発生したこと、要求またはトランザクションが関連のエ ンティティで発生したことを認証する。他の署名では、他の事項を確認できる。 2.4 DNSトランザクションおよび要求の認証 上で説明したデータ発信元認証サービスは、取得されたリソース レコードと リソース レコードの非存在を保護するが、DNS要求またはメッセージ ヘッダ の保護は提供しない。 ヘッダ ビットが不良サーバによって不適切に設定されている場合、できる ことはほとんどない。しかし、トランザクションの認証を追加することは可能 である。そのような認証は、少なくともリゾルバが問い合わせを受けたとみな すサーバからメッセージを取得していること、サーバが送信した問い合わ せから応答を得ていること(つまり、それらのメッセージが転送中に不正操作 されていないこと)を確認できることを意味する。これは、応答の末尾に特別 なSIGリソース レコードを任意に追加し、サーバの応答とリゾルバの問い合 わせの連結にデジタル署名を付けることで実現される。 Eastlake Standards Track [Page 9] RFC 2535 DNS Security Extensions March 1999 要求はまた、要求の末尾に特別なSIG RRを挿入することでも認証できる。要求 の認証には古いDNSサーバの機能は提供せず、空でない追加情報セクション を持つ要求はエラー応答を生成するか、それらの多くによって無視されること もある。しかし、要求に署名するこの構文は、安全な動的更新の要求[RFC 2137] または認証を求める将来の要求を認証する手段として定義されている。 トランザクションのセキュリティで使用されるプライベート キーは、含まれ るゾーンではなく、応答を構成するエンティティに属する。要求の認証は、ホ ストまたは要求を構成する他のエンティティのプライベート キーや、プライ ベート キーが確立することを求められる要求の権限に応じて他のプライベート キーも含むことができる。対応するパブリック キーは通常、確認のためにDNS に保存され、DNSから取得される。 要求と応答は変動の大きなものであるため、メッセージ認証SIGは事前に計算 することはできない。したがって、ソフトウェアまたはハードウェアの直接接 続する部分などにおいて、プライベート キーをオンラインにしておくことが 必要となる。 3. KEYリソースレコード KEYリソース レコード(RR)は、Domain Name System (DNS)名に関連付けられた パブリック キーを保存するために使用される。これは、ゾーン、ユーザー、 またはホストや他のエンド エンティティのパブリック キーとなる場合がある。 セキュリティ対応DNSの実装は、同一の名前に関連付けられた同一タイプの有 効なキーを少なくとも2つ同時に処理するよう設計されなければならない。 KEY RRのタイプ番号は25である。 KEY RRは、他のRRと同様に、SIG RRによって認証される。KEY RRは、ゾーン レベル キーによって署名されなければならない。 3.1 KEY RDATA形式 KEY RRのRDATAは、フラグ、プロトコル オクテット、アルゴリズム番号オクテ ット、パブリック キー自体から構成される。形式は以下の通りである。 Eastlake Standards Track [Page 10] RFC 2535 DNS Security Extensions March 1999 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | フラグ | プロトコル | アルゴリズム | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / / パブリック キー / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| KEY RRは、証明書の保存を目的としたものではなく、この目的のためには、 [RFC 2538]に定義される個別の証明書RRが作成される。 KEY RR所有者名、フラグ、プロトコル オクテットの意味は、以下のセクショ ン3.1.1から3.1.5で説明する。フラグとアルゴリズムは、アルゴリズム オク テットに続くすべてのデータの前に検証されなければならない。後続のデータ の存在と形式を管理するものであるためである。アルゴリズムおよびパブリッ ク キー フィールドは、セクション3.2で説明する。パブリック キーの形式 は、アルゴリズムに依存する。 KEY RRは有効期間を指定しないが、それらの認証SIG RRはセクション4で説明 する通りである。 3.1.1 オブジェクト タイプ、DNS名、キー KEY RRのパブリック キーは、所有者名のオブジェクト名である。 DNS名は、3つの異なるカテゴリの事項を参照できる。たとえば、 foo.host.exampleは、(1)ゾーン、(2)ホストまたは他のエンド エンティテ ィ、または(3)ユーザーまたはアカウントfoo@host.exampleのDNS名に対する マッピングとなる場合がある。そのため、これらの役割のいずれが所有者名お よびパブリック キーと関連付けられているかを示す下記のフラグ ビットが KEY RRにある。適切なゾーンKEY RRは、安全なゾーンの最上位ノードで発生し なければならず、ゾーンKEY RRは委任ポイントのみで発生する。 3.1.2 KEY RRフラグ フィールド 「フラグ」フィールドの内容: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | A/C | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z | SIG | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ ビット0および1は、値が以下のような意味を持つキー「タイプ」ビットとなる。 Eastlake Standards Track [Page 11] RFC 2535 DNS Security Extensions March 1999 10: 認証のためキーの使用は禁止されている。 01: 機密保護のためキーの使用は禁止されている。 00: 認証および機密保護のためにキーの使用が許可されている。DNS セキュリティは、認証のためのみにキーを使用する。機密保持で 使用するフラグにより、他のプロトコルでのキーの使用が可能に なる。機密保持のためのキー配布をサポートすることを目的とし ない実装は、それらが応答するキーのために機密保持の使用によ り禁止されるビットをオンにすることを要求できる。 11: 両方のビットが「no key」値である1となる場合、キー情報はな く、RRはアルゴリズム オクテットの後で停止する。この「no key」値の使用により、署名のあるKEY RRは、ゾーンは安全でな いなど正当にアサートできる。下のセクション3.4を参照。 ビット2は予約済みであり、0でなければならない。 ビット3はフラグ拡張ビットとして予約されている。値が1である場合、2番目 の16ビット フラグ フィールドは、アルゴリズム オクテットの後、キー データの前に追加される。このビットは、そのような追加ビットが1つまたは 複数定義され、0以外の値となっている場合を除き、設定されてはならない。 ヒット4-5は予約済みであり、0でなければならない。 ヒット6および7は、名前のタイプをエンコードするフィールドを形成する。 フィールドの値は以下の意味を持つ。 00: 通常ホストとなるエンド エンティティの「ユーザー」または 「アカウント」と関連付けられたキーであることを示す。所有者 名のコーディングは、SOAおよびRP RRの担当者のメールボックス に使用されるものであり、所有者名はエンティティ名の下にある ノード名としてのユーザー名である。たとえば、 host.subdomain.exampleの「j_random_user」は、KEY RRを介し てj_random_user.host.subdomain.exampleという名前を含むパブ リック キーを持つことができる。これは、ユーザーの認証が望 まれるセキュリティ プロトコルで使用することができる。この キーは、telnet、ftp、rloginなどのユーザー レベル サービス に対するIPまたは他のセキュリティで有用な場合がある。 01: 名前がKEY RR所有者名であるゾーンのゾーン キーであることを 示す。これは、データ発信元の認証という主なDNSセキュリティ 機能に使用されるパブリック キーである。ゾーンKEY RRは、委 任ポイントのみで発生する。 10: 名前がRR所有者名である、ゾーン以外の「エンティティ」に関連 付けられたキーであることを示す。これは通常ホストになるが、 DNSツリーの一部では、電話番号[RFC 1530]や数値IPアドレス Eastlake Standards Track [Page 12] RFC 2535 DNS Security Extensions March 1999 などの他のタイプのエンティティになることもある。これは、 DNS要求およびトランザクション認証サービスとの関連で使用さ れるパブリック キーである。また、ルーティングやNTPなど、 ユーザー レベルではなくホスト レベルでの認証が望ましいIP セキュリティ プロトコルで使用されることもできる。 11: 予約済み ビット8-11は予約済みであり、0でなければならない。 ビット12-15は、「署名者」フィールドとなる。0以外の場合、キーはDNSの動 的更新[RFC 2137]で指定される事項に対して有効に署名できるこ とを示す。ゾーン キー(ビット6および7を参照)は、署名者フィー ルドの値に関わらず常にゾーンのRRに署名する権限を持つ。 3.1.3 プロトコルオクテット DNSに格納されるキーはさまざまなインターネット プロトコルに関連して使用 されることが予想される。プロトコル オクテットおよび場合によっては現在 使用されていないKEY RRフラグのビットのいくつか(多くは0)は、将来の指定 の際に、さまざまなプロトコルのためにキーの有効性を示すことに使用される。 プロトコル オクテットの値は、以下のように予約されている。 値 プロトコル 0 - 予約済み 1 TLS 2 電子メール 3 dnssec 4 IPSEC 5-254 - IANAによる割当てが可能 255 すべて 詳細: 1 は、TLSに関する使用のために予約されている。 2 は、電子メールに関する使用のために予約されている。 3 は、DNSセキュリティのために使用される。プロトコル フィールドは、 ゾーン キーおよびDNSセキュリティで使用される他のキーのためにこ の値に設定されなければならない。フラグ ラベルがゾーン キーであ る事実または署名者フラグ フィールドが0以外である事実により、キ ーがDNSセキュリティ キーであることを判断できる実装は、プロトコ ル フィールドをチェックすることを要求されない。 4 は、Oakley/IPSEC [RFC 2401]プロトコルを参照するために予約されて おり、このキーがそのセキュリティ標準との関連で使用するのに有効 Eastlake Standards Track [Page 13] RFC 2535 DNS Security Extensions March 1999 であることを示す。このキーは、エンティティまたはユーザーのフラ グ ビットが設定されていれば、エンド エンティティまたは名前がKEY RRの所有者名であるユーザーに代わって、安全保護された通信との関 連で使用することができる。このプロトコル値を持つKEYリソースが存 在すれば、ホストはOakley/IPSECを認識できるという意味になる。 255は、キーが、KEY RRプロトコル オクテット値が定義されているあら ゆるプロトコルとの関連で使用できることを示す。この値の使用は勧 められず、異なるプロトコルには異なるキーを使用することが勧めら れる。 3.2 KEYアルゴリズム番号の指定 このオクテットは、セクション4.1で説明されるSIGリソースの同一フィールド に対応するキー アルゴリズムとなる。以下の値が割り当てられている。 値 アルゴリズム 0 - 予約済み。セクション11を参照 1 RSA/MD5 [RFC 2537] - 推奨 2 Diffie-Hellman [RFC 2539] - オプション。キーのみ 3 DSA [RFC 2536] - 必須 4 楕円曲線暗号化のために予約 5-251 - 使用可能。セクション11を参照 252 間接キーのために予約 253 プライベート - ドメイン名(以下を参照) 254 プライベート - OID(以下を参照) 255 - 予約済み。セクション11を参照 アルゴリズム固有の形式と手順は別のドキュメントで説明されている。相互運 用アルゴリズムのために実装が必須のものは、3番のDSAである。1番のRSA/MD5 アルゴリズムも実装が勧められる。アルゴリズム2はDiffie-Hellmanキーを示 すためい使用され、アルゴリズム4は楕円曲線のために予約されている。 アルゴリズム番号252は、実際のキーのデータが別の場所にある間接キー形式 を示す。この形式は、別のドキュメントで定義される。 アルゴリズム番号253および254は、プライベートの使用のために予約され、特 定のアルゴリズムに割り当てられることはない。253番については、パブリック キー領域と署名者が接続エンコードドメイン名で開始される。ローカル ドメイ ン名の圧縮のみが認められる。ドメイン名は使用するプライベート アルゴリズ ムを示し、パブリック キー領域のリマインダは、そのアルゴリズムに要求され るものになる。254番については、KEY RRのパブリック キー領域と署名者が無 Eastlake Standards Track [Page 14] RFC 2535 DNS Security Extensions March 1999 署名の長さのバイトで開始され、BERでエンコードされたその長さのObject Identifier (ISO OID)が続く。OIDは、使用中のプライベート アルゴリズムを 示し、領域のリマインダはそのアルゴリズムに要求されるものになる。 値0および255は予約されているが、値0は、アルゴリズム フィールドが使用さ れていない場合、そのフィールドで使用される。たとえば、最上位の2つのフ ラグ ビットがオンであり、キーが存在しない「no-key」値を持つKEY RRの場 合がある。 3.3 フラグ、アルゴリズム、およびプロトコルバイトの対話 no-keyタイプのフラグ、アルゴリズム バイト、プロトコル バイト、フラグを 示す将来の割当てプロトコルのさまざまな組合せが可能である。これらの組合 せの意味は以下に示す通りである。 NK = no-keyタイプ(フラグ ビット0および1がオン) AL = アルゴリズム バイト PR = プロトコルバイトまたは将来の割当てフラグによって示されるプロトコル x は0以外の有効な値を表す。 AL PR NK 意味 0 0 0 違反、キーを要求するが不良なアルゴリズムフィールドがある 0 0 1 所有者のゾーンの全体的なセキュリティ不足を指定。 0 x 0 違反、キーを要求するが不良なアルゴリズムフィールドがある 0 x 1 指定されたプロトコルは安全でない、他は安全かも知れない。 x 0 0 キーを提供するがそれを使用するプロトコルがない。 x 0 1 特定のアルゴリズムのキーを拒否。 x x 0 プロトコルのキーを指定 x x 1 プロトコルに対してアルゴリズムが認識されない。 3.4 ゾーンが安全かどうかの判断 「no-key」タイプ フィールド値(キー タイプ フラグ ビット0および1がオン) を持つゾーンKEY RRは、名前を付けられたゾーンが安全でないことを示し、キ ーが存在するゾーンKEY RRは、名前を付けられたゾーンが安全であることを示 す。ゾーンが安全か安全でないかは、異なる暗号化アルゴリズムによって変わ ることがある。同一のアルゴリズムでも、競合するゾーンKEY RRが存在する場 合がある。 ゾーンKEY RRは、すべてのRRと同様に、SIG RRによって認証された場合にのみ 信頼される。この場合SIG RRの署名者フィールドは、ゾーンKEY RRに信頼され るリゾルバがパブリック キーを持っている署名者であり、リゾルバ ポリシー により署名者がKEY所有者名に対して署名することが許可される。信頼されな いゾーンKEY RRは、ゾーンのセキュリティ状態を判断するときに無視しなけれ ばならない。ただし、異なるアルゴリズムや署名者を持つゾーンについて、信 頼されたゾーンKEY RRの複数のセットが存在する場合がある。 Eastlake Standards Track [Page 15] RFC 2535 DNS Security Extensions March 1999 特定のアルゴリズムでは、ゾーンは、(1)安全であり、取得されるRRがSIG RRによって認証されるか、偽物として放棄されるかを示す場合、(2)安全でな く、SIG RRが、ゾーンから取得されたRRのために期待または要求されないこと を示す場合、または(3)経験的に安全であり、SIG RRが存在することも存在し ないこともあるが、見つかればチェックされなければならないという場合があ る。ゾーンの状態は以下のように判断される。 1. ゾーンとアルゴリズムに対して、信頼されたゾーンの各ゾーンKEY RRがそ のゾーンにキーがないと主張する場合、そのアルゴリズムは安全確保され ていない。 2. 少なくとも1つの信頼されたno-keyゾーンKEY RRと、ゾーンKEY RRを指定す る信頼された1つのキーがある場合、そのゾーンはアルゴリズムに対して経 験的にのみ安全である。ゾーンについて認証されたRRと認証されていない RRの両方が、リゾルバに認められる必要がある。 3. ゾーンとアルゴリズムが持つ信頼された各ゾーンKEY RRがキー固有のもの である場合、そのアルゴリズムでは安全であり、そこから認証されたRRが 認められる。 例: (1) リゾルバは初めに、DNS階層内にあるゾーンZの上位ゾーンによる署名のみ を信頼する。したがってリゾルバは、上位ゾーンによって署名されたKEY RRの みに着目する。no-key KEY RRのみが見つかれば、そのゾーンは安全でないと 見なす。キー固有のKEY RRが見つかれば、ゾーンは安全であると見なし、署名 のない応答はすべて拒絶する。両方見つかった場合、ゾーンは経験的に安全で あると見なす。 (2) リゾルバは、ゾーンZ(リゾルバがローカル ゾーンから安全に到達したゾ ーン)の上位ゾーンと、サードパーティcert-auth.exampleを信頼する。ゾーン Zからのデータを検討するとき、リソルバは、Zの上位ゾーン、 cert-auth.example、またはその両方によって署名されたり、いずれによって も署名されない場合がある。次の表は、ゾーンZが、署名されたZのゾーンKEY RRに応じて、安全と見なされるか、経験的に安全と見なされるか、または安全 でないと見なされるかを示したものである。 c e r t - a u t h . e x a m p l e KEY RRs| None | NoKeys | Mixed | Keys | S --+-----------+-----------+----------+----------+ u None | illegal | unsecured | experim. | secure | p --+-----------+-----------+----------+----------+ e NoKeys | unsecured | unsecured | experim. | secure | r --+-----------+-----------+----------+----------+ Z Mixed | experim. | experim. | experim. | secure | Eastlake Standards Track [Page 16] RFC 2535 DNS Security Extensions March 1999 o --+-----------+-----------+----------+----------+ n Keys | secure | secure | secure | secure | e +-----------+-----------+----------+----------+ 3.5 応答の構造におけるKEY RR KEY RRに対する明示的な要求があっても、セキュリティ対応サーバからの対 応するSIG RRを除き、特別な追加情報処理は行われない (セクション4.2を参照)。 セキュリティ対応DNSサーバは応答の中に追加情報としてKEY RRを含み、以 下の場合にKEYを使用することができる。 (1) SOAまたはNS RRを取得するときは、空き領域があれば、同一の名前を持つ KEY RRset(おそらくゾーン キーのみ)が追加情報として含まれるべきである。 すべての追加情報が適合するわけでない場合、タイプAおよびAAAA glue RRは、 KEY RRよりも優先順位が高くなる。 (2) タイプAまたはAAAA RRを取得するときは、空き領域があれば、同じ名前を 持つKEY RRset(通常ホストRRのみであり、(通常異なる名前を持つ)ゾーン キ ーではない)が含まれるべきである。AまたはAAAA RRを追加情報として含める 場合、同一の名前を持つKEY RRも含まれるべきだが、AまたはAAAA RRよりも優 先順位は低くなる。 4. SIGリソースレコード SIGまたは「署名」リソース レコード(RR)は、データが安全なDomain Name System (DNS)において認証される基本的な手段である。そのため、提供される セキュリティの中心となる。 SIG RRは、特定のタイプ、クラス、名前のRRset [RFC 2181]を正しく認証し、 時間間隔と署名者のドメイン名にバインドする。これは、暗号化技術と署名者 のプライベート キーを利用して実現される。署名者は、RRが発生したゾーン の所有者であることが多い。 SIG RRタイプのタイプ番号は24である。 4.1 SIG RDATAの形式 SIG RRのRDATA部分は以下に示す通りである。RDATA情報の整合性は署名フィー ルドによって保護される。 Eastlake Standards Track [Page 17] RFC 2535 DNS Security Extensions March 1999 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type covered | algorithm | labels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | original TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signature expiration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signature inception | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key tag | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name + | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ / / / signature / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.1 Type Coveredフィールド 「type covered」は、このSIGによって扱われる他のRRのタイプである。 4.1.2 Algorithm Numberフィールド このオクテットは、セクション3.2で説明される通りである。 4.1.3 Labelsフィールド 「labels」オクテットは、元のSIG RR所有者名にいくつのラベルがあるかにつ いての無署名のカウント数であり、ルートのnullラベルはカウントせず、ワイ ルドカードのための初めの「*」をカウントしない。安全な検索がワイルドカ ード置換の結果となる場合、リゾルバはデジタル署名を検証する際に名前の元 の形式を使用する必要がある。このフィールドにより、元の形式の判断が容易 になる。 検索の際、RRが「labels」によって示されるよりも長い名前を持つように見え る場合、リゾルバはそれがワイルドカード置換の結果であることを判断できる。 RR所有者名がラベル数よりも短いように見える場合、SIG RRは破損していると 見なされ、無視されなければならない。現在のDNSで認めらるラベルの最大数 は127であるが、DNS名が255のラベルに拡大する場合はオクテット全体が必要 となり、オクテット全体が予約される。次の表はいくつかの例を示したもので ある。「labels」の値が最上段にあり、取得された所有者名が左側にある。表 に記載したものは署名の検証で使用する名前である。ただし「不良」はRRが破 損していることを意味する。 Eastlake Standards Track [Page 18] RFC 2535 DNS Security Extensions March 1999 labels= | 0 | 1 | 2 | 3 | 4 | --------+-----+------+--------+----------+----------+ .| . | bad | bad | bad | bad | d.| *. | d. | bad | bad | bad | c.d.| *. | *.d. | c.d. | bad | bad | b.c.d.| *. | *.d. | *.c.d. | b.c.d. | bad | a.b.c.d.| *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. | 4.1.4 Original TTLフィールド 「original TTL」フィールドがRDATA部分に含まれる。これは、(1) キャッシ ング サーバが実際のTTLフィールドをデクレメントすることで発生する認証 の問題、(2) 悪意のあるサーバが実際のTTLフィールドを操作することによ り発生するセキュリティの問題を回避するためである。この元のTTLは署名に よって保護されるが、現在のTTLフィールドは保護されない。 注: 「original TTL」は、署名が検証されるとき対象のRRに格納されなければ ならない(セクション8参照)。これは通常、特定のタイプ、名前、クラスのす べてのRR、つまり特定のRRsetにおけるすべてのRRが同一のTTLから開始するこ とを示すものである。 4.1.5 署名の Expirationと Inceptionフィールド SIGは、「signature inception」時刻から「signature expiration」時刻まで 有効である。これらは共に、うるう秒を無視した1970年1月1日(グリニッジ標 準時)からの符号なしの秒数である。(セクション4.4も参照)。DNS SOAシリア ル番号[RFC 1982]に関しては循環的計算が用いられ、これらの時刻は約68年を 超えて過去または未来になることはできない。これは、これらの時刻が136.09 年までを法として不明瞭となることを意味する。しかし、キーは少なくとも5 年ごとに[RFC 2541]によって新しいランダム キーに変更されることが要求さ れるため、セキュリティ フローはない。これは、同一のキーがN*136.09年後 に使用される可能性は無作為の推測が当たる可能性と同じであることを意味す る。 SIG RRは、終了時刻が32ビット ラップアラウンド ポイントに近い値であり、 署名が長期にわたって存続している場合、数値の上で開始時刻より前の終了時 刻を持つことがある。 (ゾーンを直接更新するネットワーク要求の混乱を避けるため、単調に増加す る「signature inception」時刻が必要な場合がある。) 安全なゾーンは、そのデータが更新された場合だけでなく、新しいSIG RRが挿 入された場合(つまり、ゾーンまたはそのいずれかの部分が再署名された場合) も、SOAシリアル番号のために変更されたと見なされなければならない。 Eastlake Standards Track [Page 19] RFC 2535 DNS Security Extensions March 1999 4.1.6 Key Tagフィールド 「key Tag」は、適用可能な複数のキーを効率的に選択するために使用される2 つのオクテットから構成される。署名確認のための非効率な計算作業に使用さ れるパブリック キーが本当に妥当であるかチェックする。[RFC 2537]で定義 されているアルゴリズム1(MD5/RSA)の場合、これは、signatureフィールドを デコードするために必要なパブリック キー係数の末尾の2つのオクテットの隣 にある。つまり、ネットワーク(ビッグエンディアン)の序列において係数中の 最も重要度の低い(後よりの)24ビットのうち最も重要度の高い(前よりの)16 ビットである。他のすべてのアルゴリズムでは、付録Cで説明するようにKEY RRの単純なチェックサムとして計算される。 4.1.7 Signer's Nameフィールド 「signer's name」フィールドは、SIG RRを生成する署名者のドメイン名であ る。これは、署名を確認するために使用されるパブリックKEY RRの所有者名に なる。また認証されるRRsetを含んだゾーンになることが多い。どの署名者が 何の署名することを認証されるべきかは、セクション6で説明するように、リ ゾルバのポリシーの重要な問題である。署名者の名前は、ネットワークに送信 されるときに標準のDNS名圧縮により圧縮される場合がある。 4.1.8 Signatureフィールド SIG RRの実際の署名部分は、所有者名とクラスを持つ「type covered」RRの RRsetに他のRDATAフィールドをバインドする。この対象RRsetは、これによっ て認証される。これを実現するため、データ シーケンスは次のように構成さ れる。 data = RDATA | RR(s)... ここで「|」は連結であり、 RDATAは、SIG RR自体におけるすべてのRDATAフィールドの接続形式(署名者の 名前の正規形式を含む)であるが、署名は含まない。 またRRは、セクション8で定義される通り、正規形式および順序のSIG RRと同 一の所有者名とクラスを持つ対象タイプのRRのRRsetである。 このデータ シーケンスがどのように署名に処理されるかはアルゴリズムに依 存する。これらのアルゴリズム依存の形式およびプロシージャは、別のドキュ メント(セクション3.2)で説明される。 Eastlake Standards Track [Page 20] RFC 2535 DNS Security Extensions March 1999 SIGは、ANYやAXFRなどの「メタタイプ」のためにゾーンに含まれるべきではな い(ただしIXFRに関してはセクション5.6.2を参照)。 4.1.8.1 トランザクションおよび要求のSIGの計算 セキュリティ対応サーバからの応答メッセージは、トランザクションを認証 するために追加情報セクションの末尾において特別なSIGを任意に含むことが できる。 このSIGは、有効なRRタイプではない。0の「type covered」フィールドを持つ。 これは、処理を行うDNS応答メッセージ全体の「データ」(セクション4.1.8参 照)を使用することで計算される。これはDNSヘッダを含むがIPヘッダは含まな い。また、応答RRカウント数はトランザクションSIGの含めた数に調整され、 この応答を生成したDNS問い合わせメッセージ全体と連結される。これは問い 合わせのDNSヘッダと要求SIGを含むが、そのIPヘッダは含まない。これは次の 通りである。 data = full response (less transaction SIG) | full query 要求を行うリゾルバによるトランザクションSIGの確認(サーバ ホスト キー によって署名され、ゾーン キーでは署名されない)では、問い合わせと応答は 転送中に不正操作されていないこと、応答は意図した問い合わせに対応するこ と、応答は問い合わせを受けたサーバから返されたことが示される。 DNS要求は、問い合わせの末尾に1つまたは複数のSIGを含めることにより、オ プションの選択で署名を受けることができる。そのようなSIGは、0の 「type-covered」フィールドを持つことで特定される。これらは処理を行う DNS要求メッセージに署名する。このDNS要求メッセージはDNSヘッダを含むが、 IPヘッダまたは末尾の要求SIGは含まず、要求RRカウント数が要求SIGを含めた 数に調整された前のものは含まない。 警告: 要求SIGは、更新[RFC 2136, 2137]を除き、現在定義されている要求で は不要であり、一部の古いDNSサーバがエラーを返したり問い合わせを無視 する原因になる。ただし、このようなSIGは将来、他の要求で必要になる場合 がある。 更新または特権を持つ同様の要求を認証するために必要である場合を除き、サ ーバーは要求SIGをチェックすることは要求されない。 4.2 応答の構造におけるSIG RR セキュリティ対応DNSサーバは、問い合わせが返される認証済みの各RRsetに 対して、要求されたRRsetを認証する使用可能なSIG RRの送信を試みるべきで ある。以下の規則が、要求にSIG RRを含める場合に適用される。 Eastlake Standards Track [Page 21] RFC 2535 DNS Security Extensions March 1999 1. RRsetが応答内に置かれている場合、そのSIG RRは、包含することが必要 な追加RRよりも高い優先順位で包含される。空き領域により包含が認め られない場合、下の2で説明される場合を除き、応答は省略されたものと 見なされなければならない。 2. SIG RRが、追加情報セクションRRのゾーンに存在する場合、応答は、空 き領域のため追加情報を持つSIG RRの包含が認められないという理由の みで省略されたものと見なされてはならない。 3. 委任ポイントにおける下位ゾーンのglueレコードとNS RRを認証するSIG は不要であり、送信されてはならない。 4. SIGが応答の応答セクションにRRを含む場合、その自動的包含は応答セク ションに行わなければならない。権限セクションに現れるRRを含む場合、 その自動的包含は権限セクションに行わなければならない。追加情報セ クションに現れるRRを含む場合、その自動的包含は追加情報セクション に行わなければならない。これは、権限セクションのNSとSOA RRのみに 着目する既存の標準[RFC 1034、1035] における変更である。 5. オプションにより、DNSトランザクションは、追加情報セクションの応答 の末尾におけるSIG RRによって認証されることができる(セクション 4.1.8.1)。このようなSIG RRは、応答の発信元であるDNSサーバに署名 される。署名者フィールドは、発信元サーバ ホストの名前でなければ ならないが、所有者名、クラス、TTL、元のTTLは意味を持たない。クラ スおよびTTLフィールドは0とすべきである。空き領域を節約するため、 所有者名はルート(単一の0オクテット)にすべきである。トランザクショ ンの認証が望ましい場合、そのSIG RRは最も高い優先順位で包含される ものと見なされなければならない。 4.3 応答とSIG RRの処理 以下の規則が、応答に含まれるSIG RRの処理に適用される： 1. ADビット(セクション6.1参照)セットを持つ安全な通信を通じてセキュリ ティ対応サーバから応答を受け取るセキュリティ対応リゾルバは、ゾ ーンSIG RRの確認なしで受け取られたRRを受け入れることができる。 2. 別の場合では、セキュリティ対応リゾルバは、対象とするRRのためにSIG RRを検証するべきである。 Eastlake Standards Track [Page 22] RFC 2535 DNS Security Extensions March 1999 (上の2.3.5で説明したように、安全でないリゾルバによって提供される CNAMEを安全保護することは不可能である。) 注: 実装を行う者は、上記の「すべきである」を「しなければならない」 と考えてもよい。ただし、ローカル ポリシーまたは呼び出しアプリケー ションはセキュリティ サービスを必要としないことがある。 3. SIGタイプを明示的に示すユーザーの問い合わせに対する応答でSIG RRが 受け取られた場合、特別な処理は必要ない。 メッセージが整合性チェックに合格しない場合またはSIGが署名付きRRをチェ ックしない場合、SIG RRは無効であり無視されなければならない。RRsetの認 証を主張するSIG RRのすべてが無効である場合、RRsetは認証されない。 SIG RRが追加情報セクションの応答における末尾のRRであり、0の対象タイプ を持っている場合、応答とその応答を生成した問い合わせのトランザクション 署名となる。これはオプションでチェックすることができ、チェックに失敗し た場合はメッセージは拒否される。しかしチェックが成功した場合、そのよう なトランザクション認証SIGは、メッセージのRRを直接認証することはない。 ゾーンによって署名された適切なSIG RRまたは、ゾーンまたは静的リゾルバ構 成に対してその権限を追跡するキーのみが、リゾルバのポリシーに従って、RR を直接認証することができる(セクション6参照)。リゾルバはトランザクショ ンまたは要求SIGを実行しない場合、エラーを返すことなくそれらを無視しな ければならない。 すべてのチェックによりSIG RRが有効であることが示された場合、確認された RRは認証されたと見なされる。 4.4 署名の存続期間、終了、TTL、有効性 セキュリティ対応サーバは、署名開始より前または終了時刻の後にSIG RRが 何かを認証したと見なしてはならない(セクション6も参照)。セキュリティ対 応サーバは、署名がすべて終了した後にRRが認証されたと見なしてはならな い。安全なサーバが認証済みデータをキャッシュするときに、認証終了時刻 が経過した後の時点でTTLが終了している場合、サーバは、認証終了時刻が 延長しないようにキャッシュ エントリのTTLを切り捨てるべきである。これら の制限内で、サーバは、引き続きDNS TTLの時間効果に従うべきである。そ のため認証サーバは引き続きゾーン更新および終了パラメータに従い、非認 証サーバはTTLのカウントダウンを行いTTLが0になったときはRRを廃棄する べきである(認証終了時刻に達していないSIGについても同様である)。また、 RRが問い合わせへの応答で転送される場合、 Eastlake Standards Track [Page 23] RFC 2535 DNS Security Extensions March 1999 TTLに加えて現在の時刻が認証終了時刻を超えて延長されないように、TTLは切 り捨てられるべきである。したがって一般に、転送されるRRのTTLは次のよう になる。 min(authExpTim,max(zoneMinTTL,min(originalTTL,currentTTL))) 署名が生成されるとき、署名終了時刻は、新しい署名が古い署名の終了前に生 成できるだけの期間を取って設定されるべきである。しかし、終了を先に設定 しすぎることは、生成された不良なデータまたは署名を受け取る期間が長くな ることを意味する場合がある。 署名存続期間は、TTLを数倍した値(つまりTTLの4倍から16倍)であるべきだが、 妥当な最大の再署名間隔およびゾーン終了時刻よりも小さくなるべきではない。 5. 非存在の名前とタイプ 上のセクション4で説明したSIG RRメカニズムは、ゾーンに存在するRRに対す る強力な認証を可能にする。しかし、ゾーン内の名前または既存の名前のタイ プの存在を確実に否定する方法は上記からは明らかではない。 ゾーン内の名前の非存在は、非存在名を含む名前間隔のNXT(「next」) RRによ って示される。サーバがセキュリティ対応であれば、NXT RRまたはRRとそれ らのSIGは、エラーと共に権限セクションで返される。既存の名前における非 存在タイプについても同様である。NXTに付随する空の応答セクション以外の エラー表示はない。これは、権限セクションのNSおよびSOA RRのみに着目する 既存の標準[RFC 1034/1035] における変更である。NXT RRは、NXTタイプへの 明示的な問い合わせが行われた場合にも返される。 ゾーンにおけるNXTレコードの完全なセットの存在は、委任ポイントNSあるい はglue AまたはAAAA RRへの問い合わせを除き、ゾーンに応答するセキュリテ ィ対応サーバに対する名前とタイプの問い合わせによって、少なくとも1つ の署名付きRRを含む応答が得られることを意味する。 5.1 NXTリソースレコード NXTリソース レコードは、特定の名前間隔における所有者名を持つRRがゾーン に存在しないことを安全に示すため、また既存の名前についてどのようなRRタ イプが存在しているかを示すために使用される。 Eastlake Standards Track [Page 24] RFC 2535 DNS Security Extensions March 1999 NXT RRの所有者名はゾーン内の既存の名前になる。そのRDATAは「次の」名前 およびタイプ ビット マップである。したがってゾーン内のNXT RRは、そのゾ ーン内の実際の所有者名すべてのチェインを作成する。チェインは予期しない ワイルドカードを含むが、glueアドレス レコードの所有者名は他の形で含ま れない限り省略する。これは、セクション8で説明するように、ゾーンにある すべてのドメイン名の正規の配列を示すものである。NXT RRの存在は、その所 有者名とRDATA領域における名前の間に名前が存在しないこと、およびその所 有者名においては他のタイプが存在しないことを意味する。 ゾーンの末尾のNXTには、正規配列の末尾にある既存の名前である所有者名を 必要とする場合の潜在的問題がある。この解決は容易だが、名前空間のリマイ ンダ全体を示すためにどのような名前をRDATAに挿入するかは明らかでない。 これは、名前空間を循環的に扱い、ゾーンの末尾のNXTのRDATAにゾーン名を挿 入することで対処される。 ゾーンのNXT RRは、自動的に計算され、SIGが追加されるときにゾーンに追加 されるべきである。NXT RRのTTLは、ゾーンの最小TTLを超えるべきではない。 NXT RRのタイプ番号は30である。 NXT RRはゾーン レベル キーによってのみ署名される。 5.2 NXT RDATAの形式 NXT RRのRDATAは、次に示すように、ビット マップが続くドメイン名からのみ 構成される。 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | next domain name / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type bit map / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 現在定義されているNXT RRタイプ ビット マップは、所有者名のために存在し ているRRタイプごとの1ビットである。1ビットは、所有者名について、そのタ イプのRRが少なくとも1つ存在していることを示す。ビット マップの末尾を超 えているために指定されていないすべてのビットは、0と見なされる。ビット 30は、NXTの場合、最小のビット マップの長さが実際に4オクテットになるよ うに常にオンになる。後続の0オクテットは、この形式では禁止される。先頭 のビットは、RRタイプ0(存在できない不正タイプ)を表し、この形式では0にな る。127より大きなタイプ番号を持つRRが存在する場合、この形式は使用され ない。 Eastlake Standards Track [Page 25] RFC 2535 DNS Security Extensions March 1999 タイプ ビットの0ビットが1である場合、異なる形式が使用されていることを 示す。127より大きなタイプ番号が存在している場合、常にこのようになる。 ドメイン名は、ネットワークに転送されるときに標準DNS名圧縮で圧縮される 場合がある。ビット マップのサイズは、RDLENGTHとその次のドメイン名の長 さから推測することができる。 5.3 ワイルドカードによる追加の複雑性 非存在の名前の応答が正しいこと、またはワイルドカード拡張応答が正しいこ とを証明する場合、処理がやや複雑になる。 特に、非存在の名前の応答が返される場合、問い合わされた正確な名前が存在 しないことを示すNXTが返されなければならない。また通常、ワイルドカード がなくその拡張が返されなかったことを証明するために、1つまたは複数の追 加NXTが返される必要がある(同じNXTの複数のコピーを返す必要はない。)。こ れらのNXTがある場合、応答の権限セクションにおいて返される。 さらに、ワイルドカード拡張が応答で返された場合、応答の基礎となった特別 な名前(ゾーン内のより特殊なワイルドカードを含む)が存在しなかったことを 証明するため、通常1つまたは複数のNXTも権限セクションで返される必要があ る。 5.4 例 ゾーンfoo.nilに次のエントリがあるとする場合 big.foo.nil, medium.foo.nil. small.foo.nil. tiny.foo.nil. huge.foo.nilについてのセキュリティ対応サーバへの問い合わせにより、 NXDOMAINのRCODEと次のような権限セクション データを持つエラー応答が生成 される。 Eastlake Standards Track [Page 26] RFC 2535 DNS Security Extensions March 1999 foo.nil. NXT big.foo.nil NS KEY SOA NXT ;prove no *.foo.nil foo.nil. SIG NXT 1 2 ( ;type-cov=NXT, alg=1, labels=2 19970102030405 ;signature expiration 19961211100908 ;signature inception 2143 ;key identifier foo.nil. ;signer AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfBeH1El4ixPFhpfHFElxbvKoWmvjDTCm fiYy2X+8XpFjwICHc398kzWsTMKlxovpz2FnCTM= ;signature (640 bits) ) big.foo.nil. NXT medium.foo.nil. A MX SIG NXT ;prove no huge.foo.nil big.foo.nil. SIG NXT 1 3 ( ;type-cov=NXT, alg=1, labels=3 19970102030405 ;signature expiration 19961211100908 ;signature inception 2143 ;key identifier foo.nil. ;signer MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU 1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature (640 bits) ) この応答は、big.foo.nilがゾーン内の既存の名前であり、NXTの他にそれに関 連付けられた他のRRタイプがあることを示す。しかし、非存在の名前である huge.foo.nilについての問い合わせに対する応答にはNXT(およびそのSIG) RR のみが現れる。 5.5 委任ポイントについての特別な考慮点 ゾーンの見出しとなる名前(ルート以外)は上位ゾーンのリーフとしても現れる。 両方が安全であれば、同じ名前を持つ2つの異なるNXT RRが常に存在すること になる。これらは署名者、その次のドメイン名フィールド、SOAタイプ ビット の存在などで容易に区別できる。セキュリティ対応サーバは、名前の非存在 を認証するように要求されたときには正しいNXTを、またタイプNXTについての 明示的な問い合わせが可能であればその問い合わせ時に両方のNXTを自動的に 返す必要がある。 セキュリティ未対応サーバは、NXTを自動的に返すことはなく、同じ古い実 装は明示的な問い合わせ時に下位ゾーンからNXTを返すことのみができる。 5.6 ゾーン転送 以下のサブセクションでは、全体または増分ゾーン転送がどのように安全保護 されるかを説明する。 SIG RRは、全体および増分ゾーン転送[RFC 1995]で転送されるすべての認証RR を安全保護する。NXT RRは、安全なゾーン転送の不可欠な要素であり、それぞ れの認証名およびタイプが存在していることを確認する。ただし、同じ名前お よび対象タイプを持つ複数のSIGがある場合、少なくとも1つが存在する限り、 SIGのサブセットが送られる。 Eastlake Standards Track [Page 27] RFC 2535 DNS Security Extensions March 1999 また無署名の委任ポイントNSあるいはglue AまたはAAAA RRの場合、少なくと も各タイプのいずれかが含まれる限り、これらのRRのサブセットまたは単に修 正されたセットが送られる。 ゾーンのサーバ側コピーと同じバージョン番号またはそれより新しいバージ ョン番号を持つ増分または全体ゾーン転送の要求が受け取られると、サーバ の現在のバージョンのSOA RRとそのSOA RRを確認するSIG RRsetのみで応答が 行われる。 このドキュメントで指定される完全なNXTチェインでは、NXTを介した連続的な 問い合わせの連鎖により、リゾルバは、ゾーン転送が禁止されている場合でも ゾーン内の名前のすべてを取得することができる。これを回避するために、将 来、異なる形式のNXTが指定される場合がある。 5.6.1 全体ゾーン転送 全体の転送が行われたというサーバ認証を可能にするため、転送の認証は全 体ゾーン転送で使用されるべきである。これにより、ゾーン転送全体に対する サーバ ベースの強力な保護が実現される。 5.6.2 増分ゾーン転送 増分(IXFR)転送[RFC 1995]における個々のRRは、全体ゾーン転送の場合と同様 に検証される。増分RRの削除および追加後におけるNXT名チェインの整合性と ゾーンのNXTタイプ ビットの正確性により、更新されたゾーンの各切断領域を チェックできる。しかし、通常、削除されたRRセクションも追加されたRRセク ションも競合ゾーンNXTチェインを持たないため、増分転送の完全性は確認で きない。その結果、IXFRを安全にサポートするサーバは、保守を行う増分転 送セットごとにIXFR SIG RRを処理しなければならない。 IXFR SIGは、RRの増分ゾーン更新コレクションに基づいて計算される。順序は 転送された順で、古いSOA、削除されたRR、新しいSOA、追加されたRRとなる。 各セクション内では、RRはセクション8で説明する通りに順番付けられなけれ ばならない。隣接する増分更新セットの圧縮がゾーン所有者によって行われた 場合、圧縮に含まれる各セットに対する元のIXFR SIGは廃棄され、圧縮セット を扱うために新しいIXFR SIGが計算されなければならない。 IXFR SIGは実際には全体としてのゾーンに属し、ゾーン名に属するものではな い。IXFR SIGはゾーン名について正確であるべきだが、ゾーン名に属するもの だとするとIXFR SIGのラベル フィールドは無意味になる。IXFR SIGは、増分 ゾーン転送の一部としてのみ送られる。 Eastlake Standards Track [Page 28] RFC 2535 DNS Security Extensions March 1999 IXFR SIGの検証後、転送されたRRは、サーバにおける信頼がローカル ポリ シーに適合すれば、内部SIGの検証なしで有効であると見なされることができ る。 6. 安全な解決方法とADおよびCDビット Domain Name System (DNS)からの安全なデータの取得と解決は、リゾルバで静 的に構成された1つまたは複数の信頼されたパブリック キーからの開始を含む。 信頼されたキーの開始により、暗号化を実行しようとするリゾルバは、安全な DNS構造を介して、セクション6.3で説明される対象ゾーンに安全に進むことが できる。このような信頼されたパブリック キーは、通常、セクション6.2で説 明するものと同様の方法で構成される。しかし、特別な方法として、セキュリ ティ対応リゾルバは、キーが構成されていないがローカルのよく知られたサー バーから取得した内容を信頼した場合でも、静的に構成されたかのように、応 答の結果として一部の信任を得ることがある。 セキュリティ対応サーバに格納されたデータは、認証済み、未決定、不明と して内部で分類される必要がある。また、すべてのSIGのチェックがそのデー タに関して明らかに失敗したことを示す不良という4番目の一時的状態がある。 このような不良データは、セキュリティ対応サーバに保持されない。認証済 みは、データが、リゾルバで静的に構成されたKEYに対してリゾルバ ポリシー によって認められた0またはそれ以上のSIGおよびKEY RRのチェインを介した KEYにおける有効なSIGを持っていることを意味する。未決定データは、認証さ れたSIGを持たず、リゾルバが認証を試みている追加のSIGを少なくとも1つ持 っている。不明データは、安全でないゾーンにあるか安全でないゾーンを介し て到達されたものであること、または署名のないglueアドレスや委任ポイント NSデータであることが理由で、それが見つかったゾーンにおいて認証済みとも 不良とも判断できないデータである。制御の点での動作およびそのようなデー タ ラベルに基づくフラグ付けは、セクション6.1で説明される。 署名の適切な検証には、セクション6.4で説明するように、リゾルバとサーバ の間の絶対時間について適度に確定された共通の評価が必要である。 6.1 ADおよびCDヘッダビット 従来使用されなかった2つのビットは、DNS問い合わせ/応答形式ヘッダから割 り当てられる。AD(認証データ)ビットは、応答において、サーバのポリシー に従い、応答の回答および権限部分に含まれるすべてのデータがサーバによ って認証されたことを示す。CD(チェック無効)ビットは、問い合わせにおいて、 未決定(非認証)データが問い合わせを送るリゾルバに受け入れ可能であること を示す。 Eastlake Standards Track [Page 29] RFC 2535 DNS Security Extensions March 1999 これらのビットは、従来0でなければならなかったZフィールドにより次のよう に割り当てられる。 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ これらのビットは、古いサーバおよびリゾルバでは0である。したがって、 古いサーバの応答は、セキュリティ対応リゾルバに対して認証されたときに フラグ付けが行われず、セキュリティ未対応リゾルバからの問い合わせは、チ ェック無効ビットをアサートにしないため、セキュリティ対応サーバからは 認証済みまたは不明データのみで応答が行われる。セキュリティ対応リゾルバ は、データの伝送先となっているサーバを信頼し、サーバへの安全なパス があるかDNSトランザクション セキュリティを使用しない限り、ADビットを信 頼してはならない。 暗号化を行おうとするセキュリティ対応リゾルバは、それ自身のポリシーを課 し、セキュリティ対応サーバが未決定データで応答できるようにすることで DNSの待ち時間を短縮するため、すべての問い合わせでCDビットをアサートに すべきである。 セキュリティ対応サーバは、不良データを返してはならない。CDビットをク リアにすることでサービスを要求するセキュリティ未対応リゾルバまたはセキ ュリティ対応リゾルバに対して、セキュリティ対応サーバは、回答および権 限セクションにおいて、応答に設定されたADビットで認証済みまたは不明のデ ータのみを返さなければならない。セキュリティ対応サーバは、要求の中で CDビットをアサートにすることでこのサービスを要求するセキュリティ対応リ ゾルバに対し、応答の中でADビットをクリアにして、未決定データを返すべき である。ADビットは、応答の回答および権限セクションにおけるRRのすべてが 認証済みまたは不明でない限り、応答に設定されてはならない。ADビットは追 加情報セクションを対象としない。 Eastlake Standards Track [Page 30] RFC 2535 DNS Security Extensions March 1999 6.2 静的に構成されたキー ゾーンを認証するパブリック キーは、ゾーンを認証できるように、そのゾー ンがプライマリ サーバに置かれる前にローカルの構成ファイルで定義すべ きである。 ルート ゾーンに関連付けられたパブリック キーから開始し、各リゾルバでこ れを静的に構成することが論理的に思える場合があるが、これには問題がある。 世界中のすべてのDNSリゾルバを更新することのロジスティックスは、このキ ーが変更された場合、大きな困難を含むものになる。さらに、多くの組織は、 「内部」のDNSの実装が独自のDNSサーバのみを完全に信頼することを明らか に望んでいる。このような組織の内部リゾルバは組織のゾーン サーバを介 して組織のドメイン外のデータにアクセスすることができ、組織のDNSの最上 位部分を超えてキーを構成する必要はない。 より大規模な組織の一部ではないホスト リゾルバには、再帰的で安全なDNSキ ャッシング サーバを使用するローカルISPのドメインのキーが構成されるこ とがある。 6.3 DNSを介した連鎖 ゾーンについて信頼された1つまたは複数のキーから開始する場合、キーを持 つそのゾーンの下位ゾーンについて署名付きキーを取得することが可能である べきである。安全な下位ゾーンは、非nullキー情報を持つKEY RRによって示さ れる。これは、NS RRと共に下位ゾーンに現れるが、親にも現れることがある。 これらは、ゾーンのツリーの中を降りることを可能にする。 6.3.1 キーを介したチェイン 一般に、安全なDNSで検証することをユーザーが望む一部のRRsetは、1つまた は複数のSIG RRによって署名される。これらのSIG RRはそれぞれ署名者を持ち、 この署名者の名前の下にSIGの認証に使用するパブリック キーが格納される。 またこれらのSIGはKEYも参照する署名者名を持つ。以下も同様である。その結 果、認証は、認証が示される元のデータに署名した最初のSIGと、認証を実行 するリゾルバで静的に構成される信頼済みキーとなる最終的なKEYを持った、 別のSIGとKEY RRのチェインに到達する。 このようなチェインをテストする場合、見つかったSIGの有効期間は、データ の認証の有効期間を判断するために二分されなければならない。これは純粋に アルゴリズム上のプロセスである。さらに、KEYへの参照を伴うデータに対す る各SIGの検証は、使用される暗号化アルゴリズムによって示される Eastlake Standards Track [Page 31] RFC 2535 DNS Security Extensions March 1999 客観的暗号化テストに適合しなければならない(ただし、ここでもリゾルバは 信頼されるアルゴリズムとキーの長さに関するポリシーを持つことがある)。 最後に、特定の署名者名を持つSIGが、特定の所有者名を持つデータ(おそらく KEY RRset)を認証できるという判断が、主にポリシーに関連する問題となる。 最終的に、これはリゾルバとそのリゾルバの判断に依存するクライアントに固 有なポリシーである。しかし、次のポリシーを採用することが勧められる。 Bの左端から1つまたは複数の全体のラベルを落とすことで、A < Bが、A がBよりも短いドメイン名であることを意味するようにする。つまり、A はBの直接または間接的な上位ドメインとなる。A = BはAとBが同じドメ イン名であることを意味するようにする(つまり、大文字小文字の標準化 後には同一になる)。Bの左端に1つまたは複数の全体のラベルを追加する ことで、A > Bが、AがBより長いドメイン名であることを意味するように する。つまり、AはBの直接または間接的な下位ドメインになる。 Staticを、静的に構成されリゾルバで信頼されたキーのセットの所有者 名にする。 次に、以下の3つの規則のいずれかが適用されると、Signerが、リゾルバ において所有者名Ownerを持つRRset(場合によってはKEY RRset)を認証す るSIGの有効な署名者名になる。 (1) Owner > または = Signer (ただしSignerがルートである場合、 Ownerはルートまたは最上位のドメイン名でなければならない)。つまり、 OwnerはSignerと同一またはその下位ドメインになる。 (2) ( Owner < Signer ) かつ ( Signer > または = some Static )。 つまり、OwnerはSignerの上位ドメインになり、Signerは静的に構成され るか、静的に構成されたキーの下位ドメインになる。 (3) Signer = 一部のStatic。つまり、署名者は静的に構成されたキーと 完全に同一になる。 規則 1は、DNSツリーを降りるための規則であり、ルート ゾーンは 1階層下の ラベルになるという制限により、ルート ゾーン キーに対する特別な禁止を含 む。これは最も基本的な規則である。 規則 2は、1つまたは複数の静的に構成されたキーからDNSツリーを登るための 規則である。規則2は、ルート ゾーン キーのみが静的に構成されている場合 は効力を持たない。 規則 3は、直接的な相互証明を許可する規則である。規則3は、ルート ゾーン キーのみが静的に構成されている場合は効力を持たない。 Eastlake Standards Track [Page 32] RFC 2535 DNS Security Extensions March 1999 これらの規則にローカル ポリシーを合わせる前に、(ルート ゾーン キーのみ が静的に構成されている場合に規則2および3を省くこと以外に)その結果が十 分に検討されるように注意を払うべきである。 6.3.2 競合データ 同じ問い合わせに対する競合するRRset応答を認証するように見える複数の SIG-KEYチェインが存在することが可能である。リゾルバは、返信するのに最 も信頼性の高い応答のみを選択し、他のデータを廃棄しなければならない。最 も信頼性の高いものの選択は、アルゴリズム、キー サイズ、静的に構成され たキー、横断されるゾーンなどにおいて異なる信頼を考慮することができるロ ーカル ポリシーの問題である。以下に説明する方法は、SIG-KEYチェインの長 さを考慮する場合に勧められるものである。 リゾルバは、静的に構成されたキーの開始ポイントから到達可能な安全なゾー ンにまたがり、連続する安全なゾーンの数を把握する必要がある。一般に、そ のような距離の数が少ないほど、データの信頼性は高くなる。静的に構成され たデータは、距離数として0を与えられるべきである。問い合わせの際に、異 なる距離の値を持つ同一の問い合わせについて異なる認証済みデータが見つか った場合、他のローカル ポリシーがこの場合を扱う場合を除き、より大きな 値を持つ方が無視されるべきである。 セキュリティ対応リゾルバは、安全でないゾーンがno-key値を持つ安全でない ゾーンの認証済みKEY RRの存在によって安全でないと認められる場合を除き、 安全なゾーンから安全でないゾーンに移ることを完全に拒否すべきである。そ うでなければ、リゾルバは偽物のデータまたは不正操作されたデータを取得す ることになる。 DNSツリーを横断する際に安全保護されていない正当なゾーンが見つかった場 合、そのような安全でないゾーンからの情報を介してのみ到達できるゾーンは、 安全なものとして信頼されることができない。安全保護されていないゾーン データは不正操作された可能性があり、それを介して到達された「安全な」ゾ ーンは偽物である可能性がある。これがDNSで安全なゾーンを通ってできるだ け大きな距離にまさるとともに、256以上にそのようなゾーン経由で達したそ のようなゾーンあるいはゾーンでのデータへの「距離」をセットすることがで きるかもしれない。 6.4 確実な時刻 SIG RRの時刻フィールドに対する共通の解釈には、DNSセキュリティ拡張を実 行するホストが適切に一貫した時刻を利用できることが必要である。 Network Time Protocol (NTP [RFC 1305、2030])を含み、さまざまな時刻同期 プロトコルが存在する。このようなプロトコルが使用される場合、時刻に対す る不正操作ができないように、安全に使用されなければならない。 Eastlake Standards Track [Page 33] RFC 2535 DNS Security Extensions March 1999 さもなければ、ホストが時計を戻して古いSIG RRを信用することが可能になり、 それらが認証するデータは、以前は有効だったが有効でなくなったデータとな る場合がある。 7. セキュリティRRのASCII表現 このセクションでは、マスタ ファイルの形式と3つのDNSセキュリティ リソー ス レコードのASCII表現について検討する。 KEYおよびSIG RRのアルゴリズム フィールドは、符号なしの整数型または記号 として表現できる。次の頭文字記号は、以下に示すように定義される。 値 記号 001 RSAMD5 002 DH 003 DSA 004 ECC 252 INDIRECT 253 PRIVATEDNS 254 PRIVATEOID 7.1 KEY RRの表現 KEY RRは、ゾーン データ マスタ ファイル[RFC 1033]の単一の論理行として 現れることがある。 フラグ フィールドは、符号なしの整数型または、以下のように垂直バー「|」 のインスタンスによって分離されるニーモニックの配列として表現される。 ビット ニーモニック 説明 0-1 キー タイプ NOCONF =1 秘密上の使用は禁止 NOAUTH =2 認証での使用は禁止 NOKEY =3 キーが存在しない 2 FLAG2 - 予約済み 3 EXTEND フラグ拡張 4 FLAG4 - 予約済み 5 FLAG5 - 予約済み 6-7 名前のタイプ USER =0 (デフォルト、省略可能) ZONE =1 HOST =2 (ホストまたは他のエンド エンティティ) NTYP3 - 予約済み 8 FLAG8 - 予約済み 9 FLAG9 - 予約済み Eastlake Standards Track [Page 34] RFC 2535 DNS Security Extensions March 1999 10 FLAG10 - 予約済み 11 FLAG11 - 予約済み 12-15 署名フィールド、0から15までの値は SIG0、SIG1、...SIG15で表現できる ビットまたはそれが表すフィールドが0である場合、フラグ ニーモニックが存 在する必要はない。 プロトコル オクテットは、符号なしの整数型または記号として表現できる。 次の頭文字記号が定義されている。 000 NONE 001 TLS 002 EMAIL 003 DNSSEC 004 IPSEC 255 ALL タイプ フラグ フィールドにNOKET値がある場合、アルゴリズム オクテットの 後には何も表示されない。 残りのパブリック キー部分は、Base 64 (付録A参照)で表現され、空白で隔て られた多くの部分列に分割され、さらに完全な署名を取得するために連結され る単一のBase 64の数字に分割されることがある。これらの部分列は、標準の 括弧を使用する複数行にまたがることができる。 パブリック キーは、内部サブフィールドを持つことができるが、これらはマ スタ ファイルの表現には現れない。たとえばアルゴリズム1では、公開指数サ イズ、公開指数、係数がある。アルゴリズム254では、OIDサイズ、OID、アル ゴリズム依存の情報がある。しかし、いずれの場合も、単一の論理的なBase 64文字列がマスタ ファイルに現れる。 7.2 SIG RRの表現 データSIG RRは、ゾーン データ ファイル[RFC 1033]における単一の論理行と して表現できるが、以下に説明するような特別な考慮点がいくつかある。(ト ランザクションまたは要求認証SIG RRをファイルに含めても、これらは短期間 のトランザクション番号を含むデータを扱う一時的認証であり、実際の時間で 計算されなければならないため、意味はない。) 署名者、対象タイプ、時刻には特に問題はない。時刻フィールドは、 YYYYMMDDHHMMSSという形式で表される。YYYYは年、1番目のMMは月の番号 (01-12)、DDはその月の日にち(01-31)、HHは24時間表記による時間(00-23)、 2番目のMMは分(00-59)、SSは秒(00-59)である。 Eastlake Standards Track [Page 35] RFC 2535 DNS Security Extensions March 1999 元のTTLフィールドは、符号なしの整数型として現れる。 署名されたタイプに適用される元のTTLがSIG RR自体のTTLと同じである場合、 そのTTLは省略される。それに続くデータ フィールドは最大のTTLより大きい ため、あいまいさはない。 「labels」フィールドは符号なしの整数型として現れる。 キー タグは符号なしの数値として現れる。 ただし、署名自体は非常に長くなることがある。これは最後のデータ フィー ルドであり、Base 64で表現され(付録A参照)、空白で隔てられた多くの部分列 に分割され、完全な署名を取得するために連結された単一のBase 64の数に分 割されることがある。これらの部分列は、標準の括弧を使用して行に分けるこ とができる。 7.3 NXT RRの表現 NXT RRは、署名されるときにゾーンから得るべきものであるため、元の無署名 ゾーン マスタ ファイルには現れない。NXTを追加して署名されたファイルが 出力される場合またはNXTがコードをデバッグすることで出力される場合、そ の次のドメイン名として現れ、符号なしの整数型またはRRニーモニックの配列 としてRRタイプの存在ビットが続く。 8. リソースレコードの正規形式と配列 このセクションは、Domain Name System (DNS)のセキュリティを目的として、 リソース レコード(RR)、名前の配列、全体の配列の正規形式を明記する。正 規の名前の配列は、NXT名前チェインの構成に必要である。RRset内での正規形 式および配列は、SIG RRを一貫した形で構成し検証するのに必要である。名前 内でのタイプの正規配列は、増分転送(セクション5.6.2参照)との関連で必要 とされる。 8.1 RRの正規形式 DNSセキュリティを目的として、RRの正規形式はRRの接続形式であり、ドメイ ン名は(1) 完全に拡張された名前(ポインタを介した圧縮は行われない)、(2) すべての文字が小文字に設定されたドメイン名、(3) マスタ ファイル形式に よる所有者名のワイルドカード(*に対する置換は行われない)、(4) 現在のTTL と置き換えられた元のTTLとなる。 Eastlake Standards Track [Page 36] RFC 2535 DNS Security Extensions March 1999 8.2 正規のDNS名配列 DNSセキュリティを目的する所有者名の正規配列の方法は、無署名の正当なオ クテット文字列として個々のラベルを並び替えることである。この場合、オク テットの不在が値0のオクテットの前に並び替えられ、大文字は小文字として 扱われる。ゾーン内の名前は、最上位のレベルにあるラベルで並び替えられる。 次に同じ最上位レベルの名前でその次に低いレベルによって並び替えが行われ、 並び替えがリーフ ノード ラベルにまで及ぶ。ゾーン内では、ゾーン名自体が 常に存在し、より低いレベルのラベルのプレフィックスを持つ他のすべての名 前はゾーン名となる。したがって、ゾーン名自体は常に先頭に並び替えられる。 例: foo.example a.foo.example yljkjljk.a.foo.example Z.a.foo.example zABC.a.FOO.EXAMPLE z.foo.example *.z.foo.example \200.z.foo.example 8.3 RRsetにおけるRRの正規配列 特定の所有者名およびタイプでは、RRはRDATAによって並び替えられる。左端 に揃えられた符号なしのオクテット シーケンスとして、オクテットの不在が0 オクテットの前に並び替えられる。 8.4 RRタイプの正規配列 名前は同一だがタイプが異なるRRを順序付ける必要がある場合、SIG RRが対象 タイプの直後に置かれている場合を除き、そのタイプが符号なしの整数型であ ると見なして、タイプによって順序付けられる。したがって、たとえば、Aレ コードはMXの前に置かれる。Aはタイプ1であり、MXはタイプ15であるが、共に 署名されていれば順序はA < SIG(A) < MX < SIG(MX)となるからである。 9. 適合性 サーバおよびリゾルバの適合性のレベルが以下で説明される。 9.1 サーバの適合性 DNSセキュリティに対するサーバの適合性についての2つのレベルは以下のよ うに説明される。 Eastlake Standards Track [Page 37] RFC 2535 DNS Security Extensions March 1999 基本: 基本的なサーバの適合性は、SIG、KEY、NXT RRの格納と取得(ゾーン 転送を含む)ができることである。安全なゾーンのためのセカンダリまたはキ ャッシング サーバは、少なくとも基本的な適合性を備えていなければなら ない。その場合でも、安全なCNAMEなど、完全な適合性がなければ動作しない 機能もある。 完全: 完全なサーバの適合性は、基本的適合性に以下を加える。つまり、 (1) ゾーン ファイルのSIG、KEY、NXT RRを読み取る機能、(2) ゾーン ファイ ルとプライベート キーがあるときに、場合によっては個別のアプリケーショ ンを介して、適切なSIGおよびNXT RRを追加する機能、(3) 応答においてSIG、 KEY、NXT RRの適切な自動挿入、(4) セキュリティ タイプRRの取得後における CNAMEの圧縮、(5) CD問い合わせヘッダ ビットの認識と、AD問い合わせヘッダ ビットの適切な設定、(6) 委任ポイントにおける2つのNXT RRの適切な処理で ある。安全なゾーンのプライマリ サーバは完全な準拠性を備えなければな らない。完全なセキュリティ操作、すべてのセカンダリ サーバ、キャッシ ング サーバ、その他のサーバの処理のため、ゾーンも完全に適合性を備 えるべきである。 9.2 リゾルバの適合性 DNSセキュリティにはリゾルバ(サーバのリゾルバ部分を含む)の適合性の2つ のレベルが定義されている。 基本: 基本的適合性を持つリゾルバは、SIG、KEY、NXT RRを明示的に要求され たときにそれらを扱うことができる。 完全: 完全な適合性を持つリゾルバは、(1) 少なくとも固定アルゴリズムのた めのSIGの検証を含むKEY、SIG、NXT RRを認識し、(2) どのRRが認証されたか、 またそれらがどの程度まで認証されたかを示す適切な情報をローカル キャッ シュとデータベースに保持し、(3) KEY、SIG、またはNXT RRが必要になったと きにそれらの取得を試みるために必要に応じて追加の問い合わせを実行し、(4) 通常の場合にその問い合わせにCD問い合わせヘッダ ビットを設定する。 10. セキュリティに関する考慮点 このドキュメントは、データ整合性とデータ発信元の認証、パブリック キー の配布、オプションのトランザクションおよび要求のセキュリティを提供する Domain Name System (DNS)プロトコルの拡張を規定したものである。 これらの拡張は、最大で、DNSから取得されたリソース レコード(KEYリソース レコードを含む)の有効性を保証するものであることに注意すべきである。こ れらは、自動的に他のセキュリティ問題を解決することはない。たとえば、安 全なDNSを使用すれば、ホスト名のために取得するIPアドレスについて高い信 頼性を得ることができるが、これは、誰かがそのアドレスで権限のないホスト を代わりに使用したり、 Eastlake Standards Track [Page 38] RFC 2535 DNS Security Extensions March 1999 そのアドレスに送られたパケットを取得し、そのアドレスから送られたように 見えるパケットで不正に応答することを止めることはできない。適切なセキュ リティ システムは、DNS外のインターネットについて多くの追加的側面の保護 を要求する。 ここで説明するNXT RRの実装により、リゾルバは、ゾーン転送が禁止されてい る場合でもゾーン内のすべての名前を判断することができる(セクション5.6)。 これは進行中の作業分野であり変更されることがある。 DNSの実装における多くの予防措置は、不正操作に対して安全でないDNSを強化 するため長年にわたって発展してきたものである。これらの予防措置は、放棄 されるべきではないが、安全なDNSに重大な危険が生じる場合に追加の予防措 置を提供するために検討されるべきである。 11. IANAに関する考慮点 KEY RRフラグ ビット2および8-11とすべてのフラグ拡張フィールド ビットは、 RFC 2434に説明されるように、IETFの合意によって割り当てることができる。 NAMTYPフラグ フィールドの残りとフラグ ビット4および5(これらは場合によ ってNAMTYPフィールドの拡張になることもある)は、IETF Standards Action [RFC 2434]によってのみ割当てることができる。 アルゴリズム番号5から251は、十分な理由が生じた場合、割当てが可能である。 しかし、新しいアルゴリズムの指定により相互運用性に大きな影響が生じるこ とがあり、IETF Standards Action [RFC 2434]が必要とされる。プライベート アルゴリズム タイプ253および254の存在により、プライベートおよび専用ア ルゴリズムのほとんどの必要が満たされなければならない。 Protocol Octet (5-254)の追加の値は、IETF Consensus [RFC 2434]によって 割り当てられる。 1であるNXT RR「タイプ ビット マップ」の先頭ビットの意味は、標準作業に よって割り当てることができる。 参照 [RFC 1033] Lottor, M., "Domain Administrators Operations Guide", RFC 1033, November 1987. [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [RFC 1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987. Eastlake Standards Track [Page 39] RFC 2535 DNS Security Extensions March 1999 [RFC 1305] Mills, D., "Network Time Protocol (v3)", RFC 1305, March 1992. [RFC 1530] Malamud, C. and M. Rose, "Principles of Operation for the TPC.INT Subdomain: General Principles and Policy", RFC 1530, October 1993. [RFC 2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, September 1996. [RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996. [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996. [RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC 2065] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC 2137] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC 2137, April 1997. [RFC 2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC 2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)", RFC 2537, March 1999. [RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", RFC 2539, March 1999. Eastlake Standards Track [Page 40] RFC 2535 DNS Security Extensions March 1999 [RFC 2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999. [RFC 2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System", RFC 2538, March 1999. [RFC 2541] Eastlake, D., "DNS Operational Security Considerations", RFC 2541, March 1999. [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting. Author's Address Donald E. Eastlake 3rd IBM 65 Shindegan Hill Road RR #1 Carmel, NY 10512 Phone: +1-914-784-7913 (w) +1-914-276-2668 (h) Fax: +1-914-784-3833 (w-fax) EMail: dee3@us.ibm.com Eastlake Standards Track [Page 41] RFC 2535 DNS Security Extensions March 1999 付録A: Base 64エンコード 次のエンコード方式は、N. BorensteinとN. Freedによる[RFC 2045]から得ら れたものである。ここでは便宜上、形式を編集して再現している。 出力可能な文字ごとに6ビットが表現できるように、US-ASCIIの65文字のサブ セットが使用される。(追加の65番目の文字「=」は、特別な処理機能を指定す るために使用される)。 エンコード　プロセスは、24ビットのグループの入力ビットを表現する。24 ビット入力グループは、左から右に進み、3つの8ビット入力グループを連結し て形成される。これらの24ビットは次に、4つの連結6ビット グループとして 扱われ、それぞれBase 64アルファベットの単一の数字に変換される。 6ビット グループのそれぞれは、64の出力可能文字の配列に対するインデック スとして使用される。インデックスによって参照される文字は、出力文字列に 置かれる。 表1: Base 64アルファベット 値 エンコード 値 エンコード 値 エンコード 値 エンコード 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (pad) = 15 P 32 g 49 x 16 Q 33 h 50 y エンコードされるデータの末尾で24より少ないビットが利用可能である場合、 特別な処理が実行される。完全なエンコード クォンタムは常に値の末尾で完 了する。24より少ない入力ビットが入力グループで使用可能である場合、0ビ ットが(右に)追加され、6ビット グループの整数型を形成する。データの末尾 では「=」文字を使用してパディングが実行される。すべてのBase 64入力はオ クテットの整数型であるため、次の状況のみが発生する。 Eastlake Standards Track [Page 42] RFC 2535 DNS Security Extensions March 1999 (1) エンコード入力の末尾のクォンタムが、整数型の倍数になる。ここで、エ ンコードされる出力の最終単位は、「=」のパディングのない4文字の整数型の 倍数になる。(2) エンコード入力の最終的なクォンタムがちょうど8ビットにな る。ここで、エンコードされる出力の最終単位は、2つの文字とそれに続く2つ の「=」パディング文字になる。(3) エンコード入力の最終的なクォンタムが ちょうど16ビットになる。ここで、エンコードされる出力の最終単位は、3つ の文字とそれに続く1つの「=」パディング文字になる。 Eastlake Standards Track [Page 43] RFC 2535 DNS Security Extensions March 1999 付録B: RFC 0265からの変更 このセクションは、RFC 2065以降に加えられた最も重要な変更の概要である。 1. 「操作上の考慮点」という[RFC 2065] のセクション7のほとんどは削除さ れ、別のドキュメント[RFC 2541]で説明されている場合がある。 2. KEY RRの変更は、(2a)「試験的」フラグを排除した、(2b) フラグ拡張のた めのフラグ ビットを予約した、(2c) 現在導入されている限定コードによっ て実際に使用されている未変更ビットを残すように多くのビット フィール ドをよりコンパクトにエンコードした、(2d) プロトコル フィールドの値 によって置き換えられるIPSECと電子メール フラグ ビットを省きDNSセキュ リティ自体のプロトコル フィールド値を追加した、(2e) ゾーンKEY RRが 委任ポイントのみで発生することを示すデータを追加した、(2f) RSA/MD5 アルゴリズムの記述を省き個別のドキュメント[RFC 2537]にしたことであ る。「no-key」およびキーがあるKEY RRのさまざまな組合せの意味を説明 したセクション3.4が追加されて、ゾーンが安全か安全でないかという状況 がアルゴリズムごとに明らかにされている。 3. SIG RRの変更は、(3a) 「time signed」フィールドから「signature inception」フィールドに名前が変更された、(3b) 署名開始および終了が シリアル番号循環計算を使用することを明らかにした、(3c) 1以外のアル ゴリズムのキー フットプリント/タグの定義を変更し、その計算を明らか にするため付録Cを追加したことである。また、タイプAXFRを扱うSIGが除 かれ、IXFR [RFC 1995]を扱うものが追加された(セクション5.6参照)。 4. アルゴリズム3になるDSAアルゴリズムは、強制的に実装されるアルゴリズ ムとして指定されている。アルゴリズム1になるRSA/MD5 アルゴリズムは、 推奨オプションとなっている。アルゴリズム2および4は、それぞれ Diffie-Hellmanキーおよび楕円暗号アルゴリズムであり、いずれも別のド キュメントで説明される。アルゴリズム コード ポイント252は、 「indirect」キーを示すよう指定され、実際のキーが他の場所となってい る別のドキュメントで定義される。KEYおよびSIG RRの定義は共に、[RFC 2065]で定義される「null」アルゴリズム253を省くことで簡素化されてい る。このアルゴリズムは、当時DNS動的更新[RFC 2136]で有効であると考え られたため入れられた。実際にはそれほど使用されず、DNSセキュリティを 簡素化するために省かれている。しかし、そのアルゴリズム番号は、ドメ イン名がアルゴリズムを指定するプライベート アルゴリズムを示すために 再利用されている。 Eastlake Standards Track [Page 44] RFC 2535 DNS Security Extensions March 1999 5. NXT RRの変更により、(5a) ゾーン内のNXT RRが、他の場合には名前が表示 されないglueアドレス レコードを除き、拡張のないそのままの名前として ワイルドカードを含むすべての名前を扱うようになった、(5b) 先頭のオク テットがビット0であるすべてのNXTビット マップ領域が、将来の定義のた めに予約された、(5c) ワイルドカード名との関連でNXTが返されなければ ならない状況が拡大された、(5d) ビット マップとの関連で、WKS RRへの 参照が排除され、ASCII表現のRRタイプ ニーモニックの間に垂直バー「|」 が追加された。 6. 正規形式とRRの配列に関する情報が個別のセクション8に移動された。 7. 増分または全体ゾーン転送を扱う下位セクションがセクション5に追加され た。 8. DNSチェインに関して、安全な解決についてのさらに詳細な指示とポリシー の推奨事項が主にセクション6.3.1に追加された。これは、認証されたデー タが認証チェインにおいてSIG RRの有効期間にまたがる有効期間を持って いることを明示している。ゾーンの認証サーバのすべてでゾーンによっ て署名された上位ゾーンのキーを静的に構成する必要はなくなっている。 安全でないゾーンによりDNSツリーの他の部分から切り離されたDNSデータ の安全地帯においてDNSセキュリティ チェックを継続し、キーが静的に構 成されていないゾーンを含まないようにするという推奨事項が省かれた。 9. 応答におけるADビットの存在は追加情報セクションあるいはglueアドレス または委任ポイントNS RRに適用されないことが明らかにされた。ADビット は、応答の回答および認証セクションが正当なものであることのみを示す。 10. KEY RRとNXT RRがゾーン レベル キーによってのみ署名されることが要求 されている。 11. IANAに関する考慮点のセクションとRFC 2434への参照を追加した。 Eastlake Standards Track [Page 45] RFC 2535 DNS Security Extensions March 1999 付録C: キー タグの計算 SIG RRのキー タグ フィールドは、署名を検証する場合などにKEY RRの候補が 複数あるときに使用する、正しいKEY RRをより効率的に選択する1つの手段で ある。複数の候補キーが同じタグを持つことは可能であり、この場合、1つが 機能するか全部が失敗するまで各キーが試されなければならない。キー タグ を計算する方法についての次の参照先は、アルゴリズム1を除くすべてのアル ゴリズムを対象としたもので、ANSI Cによるものである。これは効率ではなく 明瞭さを考慮してコード化されている。(アルゴリズム1のキーのキー タグを 判断する方法についてはセクション4.1.6を参照) /* intは最低16ビットとする キー タグの最初のバイトは戻り値の中で最も重要なバイトである キー タグの2番目のバイトは戻り値の中で最も重要でないバイトである */ int keytag ( unsigned char key[], /* the RDATA part of the KEY RR */ unsigned int keysize, /* the RDLENGTH */ ) { long int ac; /* assumed to be 32 bits or larger */ for ( ac = 0, i = 0; i < keysize; ++i ) ac += (i&1) ? key[i] : key[i]<<8; ac += (ac>>16) & 0xFFFF; return ac & 0xFFFF; } Eastlake Standards Track [Page 46] RFC 2535 DNS Security Extensions March 1999 著作権表示の全文 Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Eastlake Standards Track [Page 47] RFC2535-ja.txt revision 1.0 この翻訳文に関するお問い合わせは dnstech-info@jprs.jp までご連絡下さい。 Japan Registry Service Co., Ltd. http://jprs.jp/tech/