ネットワークワーキンググループ R. Arends Request for Comments: 4034 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)を規定する文書群の1つである。 DNSSECは、データの出自の認証をDNSに提供するリソースレコードと プロトコル変更をまとめたものである。本文書は、DNSKEY(公開鍵)、 Delegation Signer(DS)、RRSIG(リソースレコードの電子署名)および NSEC(データの不在証明)リソースレコードを定義する。 また各リソースレコードの目的と書式を詳細に規定し、リソースレコードの 例を提示する。 本文書はRFC 2535を廃止し、RFC 2535の更新全てを取り込んでいる。 Arends, et al. Standards Track [Page 1] RFC 4034 DNSSEC Resource Records March 2005 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. 背景と関連文書 . . . . . . . . . . . . . . . . . . . . 3 1.2. 予約語 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. DNSKEYリソースレコード . . . . . . . . . . . . . . . . . . . 4 2.1. DNSKEY RDATAのワイヤーフォーマット . . . . . . . . . . 4 2.1.1. フラグフィールド . . . . . . . . . . . . . . . 4 2.1.2. プロトコルフィールド . . . . . . . . . . . . . 5 2.1.3. アルゴリズムフィールド . . . . . . . . . . . . 5 2.1.4. 公開鍵フィールド . . . . . . . . . . . . . . . 5 2.1.5. DNSKEYのRDATA設計に関する注記. . . . . . . . . 5 2.2. DNSKEY RRの表記形式. . . . . . . . . . . . . . . . . . 5 2.3. DNSKEY RRの例. . . . . . . . . . . . . . . . . . . . . 6 3. RRSIGリソースレコード. . . . . . . . . . . . . . . . . . . . 6 3.1. RRSIG RDATAのワイヤーフォーマット. . . . . . . . . . . 7 3.1.1. 署名対象(Type Covered)フィールド . . . . . . . 7 3.1.2. アルゴリズム番号フィールド . . . . . . . . . . 8 3.1.3. ラベルフィールド . . . . . . . . . . . . . . . 8 3.1.4. オリジナルTTLフィールド. . . . . . . . . . . . 8 3.1.5. 有効期間終了フィールド・有効期間開始フィールド 9 3.1.6. 鍵タグフィールド . . . . . . . . . . . . . . . 9 3.1.7. 署名者名フィールド . . . . . . . . . . . . . . 9 3.1.8. 署名フィールド . . . . . . . . . . . . . . . . 9 3.2. RRSIG RRの表記形式 . . . . . . . . . . . . . . . . . . 10 3.3. RRSIG RRの例 . . . . . . . . . . . . . . . . . . . . . 11 4. NSECリソースレコード . . . . . . . . . . . . . . . . . . . . 12 4.1. NSEC RDATAのワイヤーフォーマット . . . . . . . . . . . 13 4.1.1. 次ドメイン名フィールド . . . . . . . . . . . . 13 4.1.2. タイプビットマップフィールド . . . . . . . . . 13 4.1.3. NSEC RDATAへのワイルドカード名保存 . . . . . . 14 4.2. NSEC RRの表記形式. . . . . . . . . . . . . . . . . . . 14 4.3. NSEC RRの例. . . . . . . . . . . . . . . . . . . . . . 15 5. DSリソースレコード . . . . . . . . . . . . . . . . . . . . . 15 5.1. DS RDATAのワイヤーフォーマット . . . . . . . . . . . . 16 5.1.1. 鍵タグフィールド . . . . . . . . . . . . . . . 16 5.1.2. アルゴリズムフィールド . . . . . . . . . . . . 16 5.1.3. ダイジェストタイプフィールド . . . . . . . . . 17 5.1.4. ダイジェストフィールド . . . . . . . . . . . . 17 5.2. 応答検証時におけるDS RRの処理. . . . . . . . . . . . . 17 5.3. DS RRの表記形式. . . . . . . . . . . . . . . . . . . . 17 5.4. DS RRの例. . . . . . . . . . . . . . . . . . . . . . . 18 6. リソースレコードの正規形式および正規順序づけ . . . . . . . . 18 6.1. DNS名の正規順序づけ. . . . . . . . . . . . . . . . . . 18 6.2. RRの正規形式 . . . . . . . . . . . . . . . . . . . . . 19 6.3. RRset内におけるRRの正規順序づけ. . . . . . . . . . . . 20 7. IANAに関する考慮点 . . . . . . . . . . . . . . . . . . . . . 20 8. セキュリティに関する考慮点 . . . . . . . . . . . . . . . . . 21 Arends, et al. Standards Track [Page 2] RFC 4034 DNSSEC Resource Records March 2005 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . 23 A. DNSSECが使用するアルゴリズム・ダイジェストタイプ . . . . . . 24 A.1. DNSSECアルゴリズムタイプ . . . . . . . . . . . . . . . 24 A.1.1. プライベートアルゴリズムタイプ . . . . . . . . 25 A.2. DNSSECダイジェストタイプ . . . . . . . . . . . . . . . 25 B. 鍵タグの計算. . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 29 1. はじめに DNSセキュリティ拡張(DNSSEC)は新しい4つのDNSリソースレコードタイプ、 すなわち DNSKEY(DNS Public Key)、RRSIG(Resource Record Signature)、 NSEC(Next Secure)およびDS(Delegation Signer)を導入する。 本文書は、各リソースレコードの趣旨とRDATAの書式、(ASCII表現の) 表記形式を定義する。 1.1. 背景と関連文書 本文書はDNSSECを定義する一連の文書群の一部であるから、読者は他の文書も 併せて読むべきである。 [RFC4033]はDNSSECを紹介し、DNSSECで共通に使用される用語を定義する。 読者はこの文書を理解しているものとする。[RFC4033]は本文書と関連文書 によって更新または廃止される文書の一覧も提供する。 [RFC4035]はDNSSECプロトコル処理を定義する。 また読者は[RFC1034]、[RFC1035]が規定する基本的なDNSの概念と、後にそれを 更新した文書群、特に[RFC2181]と[RFC2308]を理解しているものとする。 本文書はDNSSECリソースレコードを定義する。本文書で使用するDNSタイプコード の数値は10進の整数である。 1.2. 予約語 本文書におけるキーワード"しなければならない(MUST)"、"してはならない (MUST NOT)"、"要求される(REQUIRED)"、"するものとする(SHALL)"、"しな いものとする(SHALL NOT)"、"すべきである(SHOULD)"、"すべきでない (SHOULD NOT)"、"推奨される(RECOMMENDED)"、"してもよい/することがで きる(MAY)"、"任意である(OPTIONAL)"は、[RFC2119]に記述されているとお りに解釈するものとする。 Arends, et al. Standards Track [Page 3] RFC 4034 DNSSEC Resource Records March 2005 2. DNSKEYリソースレコード DNSSECは、公開鍵暗号を使用してDNSリソースレコードセット(RRset)への 署名と、RRsetの認証を行う。公開鍵はDNSKEYリソースレコードに保存され、 [RFC4035]が規定するDNSSEC認証で使用される。 具体的に、ゾーンは権威を持つRRsetに秘密鍵で署名し、その秘密鍵と対の 公開鍵をDNSKEY RRに保存する。すると、リゾルバはDNSKEY RRに保存された 公開鍵を使用してゾーンのRRsetに付けられた署名を検証し、それらを 認証することができるようになる。 DNSKEY RRは任意の公開鍵を保存するレコードとして使用することを意図して いないので、DNEKEY RRに証明書(certificate)やDNSインフラと直接関係しない 公開鍵を保存してはならない(MUST NOT)。 DNSKEY RRのタイプ値は48である。 DNSKEY RRはクラス非依存である。 DNSKEY RRは特別なTTL要件を持たない。 2.1. DNSKEY RDATAのワイヤーフォーマット DNSKEY RRのRDATAは、2オクテットのフラグフィールド、1オクテットの プロトコルフィールド、1オクテットのアルゴリズムフィールドおよび 公開鍵フィールドから構成される。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | フラグ | プロトコル | アルゴリズム | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / 公開鍵 / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.1.1. フラグフィールド フラグフィールドのビット7は署名鍵(ZSKまたはKSK)フラグである。ビット7が 1ならば、DNSKEYレコードはそのゾーンの署名鍵を保持する。 その場合DNSKEY RRの所有者名はゾーンの名前でなければならない(MUST)。 ビット7が0ならばDNSKEYレコードは署名鍵ではない公開鍵を保持する。 したがって、RRsetの署名を持つRRSIGの検証に使用してはならない(MUST NOT)。 Arends, et al. Standards Track [Page 4] RFC 4034 DNSSEC Resource Records March 2005 フラグフィールドのビット15は[RFC3757]が規定するセキュアエントリーポイント (SEP)フラグである。ビット15が1ならば、DNSKEYレコードはSEPとして使用される 鍵を保持する。このフラグは、ゾーン署名またはデバッグを行うソフトウェアに 対して、そのDNSKEYレコードが適切に使われているかに関するヒントを与える だけのものである。したがって、バリデータ(validator: 署名検証モジュール)は このビットが設定されているかによって署名検証処理を変化させてはならない (MUST NOT)。これは同時に、SEPビット付きのDNSKEY RRが署名を正当に生成する ためには、署名鍵フラグを設定する必要があることを意味する。SEPビットは設定 されていても署名鍵フラグが設定されていない場合、そのDNSKEY RRをRRsetに 付けられたRRSIGの検証に使用してはならない(MUST NOT)。 ビット0-6と8-14は予約済である。これらのビットはDNSKEY RR生成時に0に設定 されなければならず(MUST)、受信時は無視されなければならない(MUST)。 2.1.2. プロトコルフィールド プロトコルフィールド値は3でなければならない(MUST)。署名検証時に 　DNSKEY RRのプロトコルフィールドが3以外の値の場合、そのDNSKEY RRは 無効なものと扱わなければならない(MUST)。 2.1.3. アルゴリズムフィールド アルゴリズムフィールドは公開鍵の暗号アルゴリズムを特定し、公開鍵 フィールドの書式を決定する。DNSSECで使用するアルゴリズムタイプに ついては付録A.1を参照のこと。 2.1.4. 公開鍵フィールド 公開鍵フィールドは公開鍵の鍵情報(key material)を保持する。書式は 保存する鍵のアルゴリズムに依存し、独立した文書で規定される。 2.1.5. DNSKEYのRDATA設計に関する注記 プロトコルフィールドは常に値3だが、以前存在していたKEYレコードとの 後方互換性は維持される。 2.2. DNSKEY RRの表記形式 RDATA部の表記形式は以下のとおりである。 フラグフィールドは符号無し10進整数で表記しなければならない(MUST)。 現在定義されているフラグ値は0, 256, 257である。 プロトコルフィールドは符号無し10進整数の3と表記しなければならない(MUST)。 アルゴリズムフィールドは符号無し10進整数か、付録A.1で規定する アルゴリズムのニーモニック(アルゴリズムを簡略化して表記した文字列) のどちらかで表記しなければならない(MUST)。 Arends, et al. Standards Track [Page 5] RFC 4034 DNSSEC Resource Records March 2005 公開鍵フィールドは公開鍵をBase64符号化したもので表記しなければ ならない(MUST)。Base64テキストには空白(whitespace)を使用できる。 Base64符号化の定義については[RFC3548]を参照のこと。 2.3. DNSKEY RRの例 以下に示すDNSKEY RRはexample.com.の署名鍵を保存している。 example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 Cbl+BBZH4b/0PY1kxkmvHjcZc8no kfzj31GajIQKY+5CptLr3buXA10h WqTkF7H6RfoRqXQeogmMHfpftf6z Mv1LyBUgia7za6ZEzOJBOztyvhjL 742iU/TpPSEDhm2SNKLijfUppn1U aNvv4w== ) 初めの4つの項はそれぞれ所有者名、TTL、クラスおよびRRタイプ(DNSKEY)を 指定する。値256は、フラグフィールドの署名鍵ビット(ビット7)が設定 されていることを示す。値3はプロトコルフィールドの固定値である。 値5は公開鍵アルゴリズムを示す。付録 A.1で示すとおり、 アルゴリズムタイプ 5は RSA/SHA1であり、公開鍵フィールドの書式は [RFC3110]で定義される。残りの部分は公開鍵をBase64符号化したものである。 3. RRSIGリソースレコード DNSSECは公開鍵暗号を使用してDNS RRsetへの署名と、RRsetの認証を行う。 電子署名はRRSIGリソースレコードに保存され、[RFC4035]が規定する DNSSEC認証で使用される。バリデータはRRSIG RRを使用して、RRsetが そのゾーンの出自だと認証することができる。RRSIG RRは、DNSSECが使用する 検証情報(デジタル署名)を運ぶ目的のためだけに使用されなければならない (MUST)。 RRSIGレコードは特定の名前、クラスおよびタイプのRRsetの署名を持つ。 RRSIG RRは、署名の有効期間、使用アルゴリズム、署名者名(Signer's Name)と 鍵タグ(Key Tag)を指定する。鍵タグはバリデータが署名検証で使用する公開鍵を 持つDNSKEY RRを特定するためのものである。 ゾーンで権威を持つ全てのRRsetがデジタル署名で保護されなければならないため、 CNAME RRを持つ名前に対してもRRSIG RRが存在しなければならない。 これは従来のDNS仕様[RFC1034]の変更である。従来のDNS仕様では、ある名前が CNAMEを持つ場合、それ以外のタイプをその名前に対して設定することは 許容されなかった。署名ゾーンでは、CNAMEリソースレコードを持つ名前に 対して、同じ名前を持つRRSIGとNSECセクション4参照)が存在しなければ ならない(MUST)。 Arends, et al. Standards Track [Page 6] RFC 4034 DNSSEC Resource Records March 2005 RRSIG RRのタイプ値は46である。 RRSIG RRはクラス非依存である。 RRSIG RRは署名対象のRRsetと同じクラスでなければならない(MUST)。 RRSIG RRのTTL値は、署名対象のRRsetのTTL値と一致しなければならない(MUST)。 これは[RFC2181]が規定する、RRset内の個々のRRのTTL値に関する規則の例外 である。署名対象の複数のRRsetがそれぞれ異なるTTLである場合、 (訳注: 同じ所有者名・クラス・タイプを持つ、つまりRRsetの要件を満たす) 個々のRRSIG RRは異なるTTL値を持つ。 3.1. RRSIG RDATAのワイヤーフォーマット RRSIG RRのRDATAは、2オクテットの署名対象タイプ(Type Covered)、 1オクテットのアルゴリズムフィールド、1オクテットのラベルフィールド、 4オクテットのオリジナルTTLフィールド、4オクテットの有効期間終了 フィールド、4オクテットの有効期間開始フィールド、2オクテットの 鍵タグフィールド、署名者名フィールドおよび署名フィールドから構成される。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 署名対象タイプ | アルゴリズム | ラベル | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オリジナルTTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 有効期間終了 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 有効期間開始 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 鍵タグ | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 署名者名 / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / 署名 / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.1.1. 署名対象(Type Covered)フィールド 署名対象フィールドは、RRSIGレコードの署名がつけられるRRsetの タイプを特定する。 Arends, et al. Standards Track [Page 7] RFC 4034 DNSSEC Resource Records March 2005 3.1.2. アルゴリズム番号フィールド アルゴリズム番号フィールドは、署名生成に使用した暗号アルゴリズムを 特定する。DNSSECで使するアルゴリズムタイプについては付録A.1を参照のこと。 3.1.3. ラベルフィールド ラベルフィールドは、オリジナルのRRSIG RRの所有者名のラベル数を指定する。 このフィールドの意義は、このフィールドを使用することにより、回答が ワイルドカードから合成されたものであるかをバリデータが判断できること にある。回答がワイルドカードから合成されたものである場合、バリデータは このフィールドを使用して、署名を生成した時点の所有者名を決定する ことができる。 バリデータが署名を検証するためには、署名を生成した時点での所有者名、 すわなちオリジナルの所有者名が必要である。オリジナルの所有者名が ワイルドカードラベル("*")を含む場合、応答処理の際にサーバが所有者名を 展開しているかもしれない。その場合、バリデータは署名を検証するために オリジナルの所有者名を再構成する必要がある。 [RFC4035]でオリジナルの所有者名を再構成する際にラベルフィールドを 使用する方法を規定している。 ラベルフィールド値は、所有者名の終わりにあるヌル(ルート)ラベルや (存在する場合)ワイルドカードラベルを勘定に含めてはならない(MUST NOT)。 ラベルフィールド値はRRSIGの所有者名のラベル数以下でなければ ならない(MUST)。例えば、"www.example.com."のラベルフィールド値は3 であり、"*.example.com"のラベルフィールド値は2である。ルート(".")の ラベルフィールド値は0になる。 RRSIG RRのラベルフィールド値はワイルドカードを勘定に含めていないが、 署名生成時あるいは検証時にはワイルドカードはRRsetの所有者名の一部として 扱われる。 3.1.4. オリジナルTTLフィールド オリジナルTTLフィールドは、権威を持つゾーンで署名対象のRRsetに対して 設定されるTTLを指定する。 キャッシングリゾルバはキャッシュしたRRsetのTTLを減少させるので、 オリジナルTTLフィールドは必要不可欠である。バリデータが署名を 検証するにはオリジナルTTLが必要である。[RFC4035]でオリジナルTTLを 再構成する際にオリジナルTTLフィールドを使用する方法を規定している。 Arends, et al. Standards Track [Page 8] RFC 4034 DNSSEC Resource Records March 2005 3.1.5. 有効期間終了フィールド・有効期間開始フィールド 有効期間終了フィールドと有効期間開始フィールドにより、署名の有効期間が 指定される。有効期間の開始前あるいは終了後にRRSIGレコードを使用した 認証を行ってはならない(MUST NOT)。 有効期間終了フィールドと有効期間開始フィールドは、どちらも1970年1月1日 0時0分0秒(UTC)から経過した時間をうるう秒を無視した秒数で指定したもの である。32ビットの符号無し整数の形態で、ネットワークバイトオーダで 保存される。周回(wrapping)無しで表現可能な最長の有効期間は約136年である。 有効期間終了フィールドの値が32ビットの周回点近傍である場合や、 署名が長期間有効である場合、RRSIG RRの有効期間終了フィールド値が 有効期間開始フィールド値よりも数値的に小さくなることもあり得る。 このため、これらのフィールド値を比較する場合、[RFC1982]が定義する "シリアル番号計算"を使用しなければならない(MUST)。結果として、 このフィールドが持つ値は68年以上の過去あるいは未来を扱うことが できなくなる。 3.1.6. 鍵タグフィールド 鍵タグフィールドはこの署名を検証するDNSKEY RRの鍵タグ値をネットワークバイト オーダで保存する。鍵タグ値の計算方法は付録Bで説明する。 3.1.7. 署名者名フィールド 署名者名フィールドは、バリデータがこの署名を検証する際に使用する DNSKEY RRの所有者名を特定する。署名者名フィールドは、署名対象の RRsetのゾーン名を保存しなければならない(MUST)。RRSIG RRを転送する際に、 送信者は署名者名にDNS名前圧縮(name compression)を使用してはならない (MUST NOT)。 3.1.8. 署名フィールド 署名フィールドには暗号署名が保存される。署名対象は、(署名フィールドを 除く)RRSIG RDATAと、RRSIGの所有者名・クラス・署名対象フィールドなどで 指定されるRRsetである。 このフィールドの書式は使用するアルゴリズムに依存するものであり、 別の関連文書で規定される。 3.1.8.1. 署名の計算 署名対象は、(署名フィールドを除く)RRSIG RDATAと、RRSIGの所有者名・ クラス・署名対象フィールドなどで指定されるデータRRsetである。 RRsetは正規形式(セクション6参照)であり、RR(1)...RR(n)は以下のように 署名される。 Arends, et al. Standards Track [Page 9] RFC 4034 DNSSEC Resource Records March 2005 署名 = sign(RRSIG_RDATA | RR(1) | RR(2)... ) "|"は連結(concatenation)を表す。 RRSIG_RDATAは、RRSIG RDATAフィールドの署名者名フィールドを 正規形式にし、更に署名フィールドを取り除いた残りの部分を ワイヤーフォーマットで表現したもの。 RR(i) = 所有者名 | タイプ | クラス | TTL | RDATA長 | RDATA "所有者名"はRRsetの所有者名のFQDN表記(fully qualified owner name)を正規形式(ワイルドカードを含む所有者名の場合、 ワイルドカードラベルも所有者名に含める)で表現したもの。 各RRの所有者名はRRSIG RRの所有者名と同じでなければならない (MUST)。 各RRのクラスはRRSIG RRのクラスと同じでなければならない (MUST)。 RRset内の各RRは、RRSIG RRの署名対象フィールドに記載された 一覧に含まれるRRタイプでなければならない(MUST)。 RRset内の各RRはRRSIG RRのオリジナルTTLフィールドに記載された 一覧に含まれるTTLでなければならない。 各RRのRDATAフィールドに含まれるDNS名は正規形式でなければ ならない(MUST)。 RRsetは正規順序で並べられていなければならない(MUST)。 正規形式とRRsetの順序づけについては、セクション6.2と6.3を参照のこと。 3.2. RRSIG RRの表記形式 RDATA部の表記形式は以下のとおりである。 署名対象フィールドはRRタイプをニーモニックで表記する。ニーモニックが 不明な場合、[RFC3597] セクション5で規定するタイプ表記を使用しなければ ならない(MUST)。 アルゴリズムフィールドの値は、符号無し10進整数か、または付録 A.1で 指定するアルゴリズムのニーモニックで表記しなければならない(MUST)。 ラベルフィールドの値は符号無し10進整数で表記しなければならない(MUST)。 Arends, et al. Standards Track [Page 10] RFC 4034 DNSSEC Resource Records March 2005 オリジナルTTLフィールドの値は符号無し10進整数で表記しなければならない (MUST)。 有効期間終了フィールドの値と有効期間開始フィールドの値は、どちらも 1970年1月1日0時0分0秒(UTC)から経過した秒数を符号無し10進整数で表記するか、 またはUTCの YYYYMMDDHHmmSS 形式で表記しなければならない(MUST)。 ここで、YYYYMMDDHHmmSSの意味は以下のとおりである。 YYYY: 年(0001-9999。ただしセクション3.1.5参照のこと) MM: 月(01-12) DD: 日(01-31) HH: 24時間表記の時間(00-23) mm: 分(00-59) SS: 秒(00-59) 2つの書式はいつでも識別可能であることに注意してもらいたい。YYYYMMDDHHmmSS 書式は常に14桁の数であるが、32ビット符号無し整数は決して10桁より長く ならないからである。 鍵タグフィールドは符号無し10進整数で表記しなければならない(MUST)。 署名者名フィールドはドメイン名で表記しなければならない(MUST)。 署名フィールドは署名をBase64で符号化したもので表記する。Base64テキストには 空白を使用できる。セクション2.2参照のこと。 3.3. RRSIG RRの例 以下に示すRRSIG RRはhost.example.comのA RRsetの署名を保存している。 host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( 20030220173103 2642 example.com. oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) 初めの4つの項は、それぞれ所有者名、TTL、クラスおよびRRタイプ(RRSIG)を 指定する。"A"は署名対象タイプフィールドの内容である。値5は署名生成時に 使用したアルゴリズム(RSA/SHA1)を特定する。値3は所有者名のラベル数である。 RRSIG RDATAの値86400は、署名対象のA RRsetのオリジナルTTLである。 20030322173103と20030220173103は、それぞれ有効期間終了時刻、 有効期間開始時刻である。2642は鍵タグであり、example.com.は署名者名である。 残りの部分は署名をBase64符号化したものである。 Arends, et al. Standards Track [Page 11] RFC 4034 DNSSEC Resource Records March 2005 所有者名・クラス・署名対象タイプの組み合わせにより、このRRSIG RRの 署名対象が"host.example.com"のA RRsetであると示唆していることに 注意してもらいたい。また、ラベル値3はワイルドカードの展開がされていない ことを示唆している。さらにアルゴリズム、署名者名および鍵タグにより、 この署名はexample.comゾーンのDNSKEY RRのうち使用アルゴリズムが5で 鍵タグが2642のものによって認証可能であることを示唆している。 4. NSECリソースレコード NSECリソースレコードは2つの独立した情報を提示する。1つめはNSEC RRの 所有者名の(ゾーンの正規順序で)次に来る所有者名で、権威を持つデータ または委任点のNS RRsetを持つものである。2つめはNSRC RRの所有者名に 関連づけられるRRタイプの集合である [RFC3845]。 ゾーン内のNSEC RRの完全な集合は、ゾーン内に存在する権威を持つRRsetが どれかを示すと同時に、ゾーン内の権威を持つ所有者名の連鎖を形成する。 この情報を使用して[RFC4035]が規定するDNSデータの不在証明を行う。 ゾーン内に存在する権威を持つ名前は、全てNSEC連鎖に組み込まれて いなければならないので、CNAME RRを持つ名前に対してもNSEC RRが存在して いなければならない。これは従来のDNS仕様[RFC1034]からの変更である。 従来のDNS仕様では、ある名前がCNAMEを持つ場合、それ以外のタイプを その名前に対して設定することは許容されなかった。署名ゾーンでは、 CNAMEリソースレコードを持つ名前に対して、同じ名前を持つRRSIG (セクション3参照)とNSECが存在しなければならない(MUST)。 ゾーンに設定する必要があるNSEC RRをゾーン署名者が厳密に決定する方法に ついては、[RFC4035]を参照のこと。 NSEC RRのタイプ値は47である。 NSEC RRはクラス非依存である。 NSEC RRはSOAの最小TTLフィールドの値と同じTTLを持つべき(SHOULD)である。 ここで、最小TTLフィールド値はネガティブキャッシュを意味するものとする。 ([RFC2308])。 Arends, et al. Standards Track [Page 12] RFC 4034 DNSSEC Resource Records March 2005 4.1. NSEC RDATAのワイヤーフォーマット NSEC 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 次ドメイン名 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / タイプビットマップ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.1. 次ドメイン名フィールド 次ドメイン名フィールドは、NSEC RRの所有者名の(ゾーンの正規順序で)次に 来る所有者名で、権威を持つデータまたは委任点のNS RRsetを持つものである。 正規的な順序づけについてはセクション6.1を参照のこと。 正規順序で最後に位置するNSECレコードの次ドメイン名フィールド値は、 ゾーン頂点の名前(ゾーンのSOA RRの所有者名)である。 つまり、次ドメイン名フィールド値としてゾーン頂点の名前を持つ NSEC RRの所有者名がゾーンの正規順序における最後の名前ということである。 NSEC RRを転送する際に、送信者は次ドメイン名フィールドに対してDNS名前圧縮を 使用してはならない(MUST NOT)。 RRsetの所有者名が(グルーレコードのように)ゾーンで権威を持たない場合、 同じ所有者名の権威を持つRRsetが1つも無ければ所有者名を次ドメイン名 フィールドに列挙してはならない(MUST NOT)。 4.1.2. タイプビットマップフィールド タイプビットマップフィールドは、そのNSEC RRの所有者名に 関連づけられているRRsetのタイプを特定する。 RRタイプ空間を256のウインドウブロックに分割する。各ブロックは16ビットの RRタイプ空間のうち、下位8ビットを表現する。 アクティブなRRタイプを少なくとも1つ持つブロックは、1オクテットの ウインドウ番号(0～255)、そのブロックが使用するビットマップのオクテット数を 示す1オクテットのビットマップ長(1～32)、最大32オクテット(256ビット)の ビットマップを使用して符号化される。 各ブロックは、ウインドウ番号の小さいものから順にNSEC RR RDATA内に 保存される。 タイプビットマップフィールド = ( ウインドウブロック番号 | ビットマップ長 | ビットマップ )+ "|"は連結を表す。 Arends, et al. Standards Track [Page 13] RFC 4034 DNSSEC Resource Records March 2005 各ビットマップはウインドウブロック内に保存されたRRタイプの下位8ビットを ネットワークビットオーダで符号化したものである。ビットマップの第1ビットが ビット0に相当する。ウインドウブロック0の場合、ビット1はタイプ1(A)に相当し、 ビット2はタイプ2(NS)に相当する。以下同様である。ウインドウブロック1の場合、 ビット1はRRタイプ257に相当し、ビット2はRRタイプ258に相当する。 ビットマップにビットが設定されている場合、NSEC RRの所有者名に対して そのビットが表現するタイプのRRsetが関連づけられていることを意味する。 ビットが設定されていない場合、NSEC RRの所有者名に該当ビットが表現する タイプのRRsetは関連づけられていないことを意味する。 擬似RRタイプ(pseudo-type)はゾーンデータには表れないので、これを表現する ビットはクリアされていなければならない(MUST)。該当ビットが設定されていた 場合は、読み出し時に無視しなければならない(MUST)。 タイプを持たない、つまりビットマップが全て0のブロックを含めては ならない(MUST NOT)。ビットマップ内で末尾に続く0のオクテット列 (trailing zero octets)は省略しなければならない。各ブロックの ビットマップ長は、NSEC RRの所有者名に対して設定されるRRタイプ値の中で、 そのブロックが表現しようとするタイプコードの最大値に応じて決定される。 末尾に続く0のオクテット列が明示的に指定されていないのであれば、それは 存在しない(ゼロオクテット)と解釈しなければならない(MUST)。 委任点にあるNSEC RRのビットマップについては特別な注意が必要である。 委任を行っているNS RRsetと、親ゾーン側が権威を持つデータのRRタイプに ついては、対応するビットを設定しなければならない(MUST)。 一方でNS RRset以外で親ゾーンが権威を持たないRRタイプに相当する ビットはクリアしなければならない(MUST)。 グルーレコードしか保持しないドメイン名に対し、NSEC RRを設定しては ならない(MUST NOT)。 4.1.3. NSEC RDATAへのワイルドカード名保存 ゾーン内にワイルドカード所有者名が存在する場合、ワイルドカードラベル ("*")は文字記号として扱われ、NSEC RR生成時に他の所有者名と全く同じに 処理される。ワイルドカード所有者名はワイルドカード展開をせずにそのまま 次ドメイン名フィールドに保存される。[RFC4035]でワイルドカードが不在証明に 与える影響について記述している。 4.2. NSEC RRの表記形式 RDATA部の表記形式は以下のとおりである。 次ドメイン名フィールドにはドメイン名を表記する。 タイプビットマップはRRタイプのニーモニックを並べて表記する。 ニーモニックが不明な場合は、[RFC3597]のセクション5で規定するタイプ表記を 使用しなければならない(MUST)。 Arends, et al. Standards Track [Page 14] RFC 4034 DNSSEC Resource Records March 2005 4.3. NSEC RRの例 以下に示すNSEC RRはalfa.example.comに関連づけられたRRsetを特定し、 また正規順序でalfa.example.comの次にくる権威ある名前を特定している。 alfa.example.com. 86400 IN NSEC host.example.com. ( A MX RRSIG NSEC TYPE1234 ) 初めの4つの項はそれぞれ名前、TTL、クラスおよびRRタイプ(NSEC)を指定する。 host.example.comという項は、正規順序でalfa.example.comの次にくる 権威ある名前を表す。ニーモニック A、MX、RRSIG、NSEC、TYPE1234は、 alfa.example.comにそれぞれA、MX、RRSIG、NSEC、TYPE1234が関連づけられて いることを示す。 先に示したNSEC RRのRDATA部は以下のように符号化される。 0x04 'h' 'o' 's' 't' 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' 0x03 'c' 'o' 'm' 0x00 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x20 バリデータこのNSECレコードを検証できれば、それによってbeta.example.comが 存在しないことやalfa.example.comにAAAAレコードが存在しないことが証明 される。不在証明については[RFC4035]で議論している。 5. DSリソースレコード DSリソースレコードはDNSKEY RRを参照するもので、これを使用してDNSの DNSKEY認証処理を行う。DS RRは、DNSKEYの鍵タグ、アルゴリズム番号および ダイジェストを保存しており、これらの情報を使用してDNSKEY RRを参照する。 公開鍵を特定するにはダイジェストがあれば充分だが、鍵タグや鍵アルゴリズムを 保存することにより、より効率的な特定処理ができることに注意してもらいたい。 DSレコードを認証することにより、リゾルバはそのDSレコードが参照する DNSKEY RRを認証することができる。鍵の認証処理については[RFC4035]で記述 している。 DS RRとDSが参照するDNSKEY RRは共に同じ所有者名を持つが、両者は異なる 場所に保存される。DS RRは委任の上位(親)側にしか存在せず、親ゾーンが 権威を持つデータである。 例えば"example.com"のDS RRは、"example.com"ゾーン(子ゾーン)ではなく "com"ゾーン(親ゾーン)に保存される。一方で参照されるDNSKEY RRは "example.com"ゾーン(子ゾーン)に保存される。 これにより、DNSゾーン管理とゾーン署名を簡略化できるが、DS RRに関して 特別な応答処理が必要になる。詳細は[RFC4035]に記述する。 Arends, et al. Standards Track [Page 15] RFC 4034 DNSSEC Resource Records March 2005 DS RRのタイプ値は43である。 DS RRはクラス非依存である。 DS RRは特別なTTL要件を持たない。 5.1. DS RDATAのワイヤーフォーマット DS RRのRDATAは2オクテットの鍵タグフィールド、1オクテットのアルゴリズム フィールド、1オクテットのダイジェストタイプフィールドおよびダイジェスト フィールドから構成される。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 鍵タグ | アルゴリズム |ダイジェストタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / ダイジェスト / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1.1. 鍵タグフィールド 鍵タグフィールドは、DS RRが参照するDNSKEY RRの鍵タグをネットワーク バイトオーダで列挙する。 DS RRの鍵タグはRRSIG RRの鍵タグと同一である。付録Bで鍵タグの計算法を 規定する。 5.1.2. アルゴリズムフィールド アルゴリズムフィールドは、DS RRが参照するDNSKEY RRのアルゴリズム番号を 列挙する。 DS RRのアルゴリズム番号はRRSIG RRやDNSKEY RRのアルゴリズム番号と同一 である。付録A.1にアルゴリズム番号タイプを列挙する。 Arends, et al. Standards Track [Page 16] RFC 4034 DNSSEC Resource Records March 2005 5.1.3. ダイジェストタイプフィールド DS RRはDNSKEY RRのダイジェストを持つことにより、そのDNSKEY RRを参照 する。ダイジェストタイプフィールドは、ダイジェスト生成に使用した アルゴリズムを特定する。付録A.2に使用可能なダイジェストアルゴリズム タイプを列挙する。 5.1.4. ダイジェストフィールド DS RRはDNSKEY RRのダイジェストを持つことにより、そのDNSKEY RRを参照 する。 ダイジェストタイプは、正規形式のDNSKEY RRの所有者名のFQDN表記と、 そのDNSKEYのRDATAを連結したものにダイジェストアルゴリズムを適用して 算出する。 ダイジェスト = ダイジェストアルゴリズム(DNSKEY所有者名 | DNSKEY RDATA); "|"は連結(concatenation)を表す。 DNSKEY RDATA = フラグ | プロトコル | アルゴリズム | 公開鍵 ダイジェストのサイズは、ダイジェストアルゴリズムやDNSKEY RRサイズに応じて 変動する。本稿執筆時点において定義されているダイジェストアルゴリズムは SHA-1だけであり、このアルゴリズムは20オクテットのダイジェストを生成する。 5.2. 応答検証時におけるDS RRの処理 DS RRはゾーン境界をまたいで認証の連鎖をリンクするので、DS RRの処理には 特別な配慮が必要である。DS RRが参照するDNSKEY RRはDNSSEC署名鍵で なければならない(MUST)。したがって、フラグフィールドはビット7が 設定されていなければならない(MUST)。 参照するDNSKEY RRのフラグがDNSSEC署名鍵であることを明示していない場合、 署名検証処理にDS RR(とそのDS RRが参照するDNSKEY RR)を使用してはならない (MUST NOT)。 5.3. DS RRの表記形式 RDATA部の表記形式は以下のとおりである。 鍵タグフィールドは符号無し10進整数で表記しなければならない(MUST)。 アルゴリズムフィールド値は符号無し10進整数か、または付録 A.1で規定する アルゴリズムのニーモニックで表記しなければならない(MUST)。 ダイジェストタイプフィールドは符号無し10進整数で表記しなければ ならない(MUST)。 Arends, et al. Standards Track [Page 17] RFC 4034 DNSSEC Resource Records March 2005 ダイジェストは大文字小文字を区別しない(case-insensitive)16進数の並びで 表記しなければならない。16進テキストでは空白を使用できる。 5.4. DS RRの例 以下の例はDNSKEY RRと対応するDS RRを示している。 dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz fwJr1AYtsmx3TGkJaNXVbfi/ 2pHm822aJ5iI9BMzNXxeYCmZ DRD99WYwYqUSdjMmmAphXdvx egXd/M5+X7OrzKBaMbCVdFLU Uh6DhweJBjEVv5f2wwjM9Xzc nOf+EPbtG9DMBmADjFDc2w/r ljwvFw== ) ; key id = 60485 dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A 98631FAD1A292118 ) 初めの4つの項はそれぞれ名前、TTL、クラスおよびRRタイプ(DS)を指定する。 値60485は参照する"dskey.example.com."のDNSKEY RRの鍵タグであり、 値5はそのDNSKEY RRが使用するアルゴリズムを表す。値1はダイジェスト 生成に使用したアルゴリズムであり、残りのRDATAテキストはダイジェストを 16進で表記したものである。 6. リソースレコードの正規形式および正規順序づけ 本セクションは、リソースレコードの正規形式、DNS名の正規順序づけ、 RRset内におけるリソースレコードの正規順序づけについて定義する。 名前の正規順序づけはNSECを使用した名前の連鎖を形成するために必要である。 RRset内におけるRRの正規形式と順序づけは、RRSIG RRを生成および検証 するために必要である。 6.1. DNS名の正規順序づけ DNSSECでは、所有者名を構成する個々のラベルを符号無し左揃えの オクテット列と見なして順序づけを行う。オクテットが存在しない場合、 ゼロ値のオクテットの前に順序づけられ、また大文字のUS-ASCII文字は 小文字のUS-ASCII文字として扱われる。 Arends, et al. Standards Track [Page 18] RFC 4034 DNSSEC Resource Records March 2005 DNS名の集合を正規順序づけする処理は、最上位(一番右の)ラベルに基づいて 名前を順序づけることから始まる。最上位ラベルが同一である場合、次に上位の ラベルに基づいて順序づけを行い、以下同じ処理を繰り返す。 例えば、以下の名前は正規に順序づけされたDNS名である。最上位ラベルは "example"である。この階層では"example"が一番に順序づけられ、 "a.example"で終わる名前が続き、その後に"z.example"で終わる名前がくる。 同じ階層の名前は同様の方法で順序づけがなされる。 example a.example yljkjljk.a.example Z.a.example zABC.a.EXAMPLE z.example \001.z.example *.z.example \200.z.example 6.2. RRの正規形式 DNSSECを実現するために必要なRRの正規形式は、以下の条件を満たす RRのワイヤーフォーマットである。 1. RR内の各ドメイン名は完全に展開され(DNS名前圧縮を使用せず)、 FQDN表記になっている。 2. 所有者名に含まれる大文字のUS-ASCII文字は、小文字のUS-ASCII文字に 置き換えられている。 3. RRのタイプがNS、MD、MF、CNAME、SOA、MB、MG、MR、PTR、HINFO、MINFO、 MX、RP、AFSDB、RT、SIG、PX、NXT、NAPTR、KX、SRV、DNAME、A6、RRSIG、 NSECのどれかである場合、RDATAに含まれるDNS名で大文字のUS-ASCII文字の ものは全て小文字のUS-ASCII文字に置き換えられている。 4. RRの所有者名がワイルドカード名である場合、所有者名は"*"ラベルを 含むオリジナルの未展開の形態になっている(ワイルドカードを 変換していない)。 5. RRのTTLは、そのRRが権威ゾーンで生成された際のオリジナルの値か、または 署名を持つRRSIG RRのオリジナルTTLフィールドと同じ値になっている。 Arends, et al. Standards Track [Page 19] RFC 4034 DNSSEC Resource Records March 2005 6.3. RRset内におけるRRの正規順序づけ DNSSECでは、同じ所有者名、クラスおよびタイプを持つ複数のRRは、 各RRを正規形式化した際のRDATA部を左揃えのオクテット列として扱う ことによって順序づけする。オクテットが存在しない場合はゼロ値の オクテットの前に順序づけられる。 [RFC2181]の規定では、RRsetは重複したレコード(同じ所有者名、クラス、 タイプおよびRDATAを持つ複数のRR)を持つことができない。 したがって、RRsetを正規形式に変換する際に重複したRRをDNSSEC実装が 検知した場合、プロトコルエラーとして処理しなければならない(MUST)。 このプロトコルエラーを堅牢性の原則(「送信には保守的であれ、受信には 寛容であれ」)にしたがって処理することを選択した場合、重複するRRは1つを 除いて全て除去した上でRRsetの正規形式を算出しなければならない(MUST)。 7. IANAに関する考慮点 本文書で使用するプロトコルパラメータは、従来の仕様で全て割り当て済みで あるため、本文書が新たに導入するIANAに関する考慮点は存在しない。 しかし、DNSSECの展開は長期に渡り、また少々入り組んでもいるため、 本セクションではIANAレジストリの状況と、DNSSECに関連する(あるいはかつて 関連した)他のプロトコルパラメータの現状について整理する。 追加のIANAに関する考慮点については[RFC4035]を参照のこと。 DNSリソースレコードタイプ: [RFC2535]でタイプ24、25、30をそれぞれ SIG、KEY、NXT RRに割り当てた。[RFC3658]でタイプ43をDSに割り当てた。 [RFC3755]でタイプ46、47、48をそれぞれRRSIG、NSEC、DNSKEY RRに 割り当てた。 [RFC3755]でタイプ30(NXT)を廃止し、タイプ24(SIG)と25(KEY)の用途を 限定し、[RFC2931]で記述する"SIG(0)"トランザクションセキュリティ プロトコルと[RFC2930]で規定するトランザクションKEY RRだけにした。 DNSセキュリティアルゴリズム番号: [RFC2535]でDNSSECリソースレコード アルゴリズム フィールド番号に関するIANAレジストリを開設し、 1-4と252-255を割り当てた。[RFC3110]で値5を割り当てた。 [RFC3755]でこのレジストリを修正し、DNSセキュリティ拡張(ゾーン署名に 基づくDNSSECとトランザクションセキュリティに基づくSIG(0)等の技術)に おける各アルゴリズムの適用可能性に関するフラグを含めた。 各アルゴリズムエントリは、ゾーン署名、トランザクションセキュリティ ([RFC2931]参照)、またはその両方に使用可能なアルゴリズムを参照する。 値6-251は、値割り当てに関するIETF標準化活動を経た後に使用可能である ([RFC3755])。 本稿執筆時点におけるDNSセキュリティアルゴリズム番号エントリと DNSSECへの適用可能性に関する完全な一覧については、付録Aを参照のこと。 Arends, et al. Standards Track [Page 20] RFC 4034 DNSSEC Resource Records March 2005 [RFC3658]でDNSSEC DSダイジェストタイプに関するIANAレジストリを 開設し、値0を予約済みに、値1をSHA-1に割り当てた。 鍵プロトコル値: [RFC2535]で鍵プロトコル値に関するIANAレジストリを開設 したが、[RFC3445]で3以外の全ての値を予約済みに再割り当てし、IANA レジストリを閉じた。レジストリは閉じたままであり、KEYとDNSKEY レコードは全てプロトコルオクテット値3を使用しなければならない。 KEYおよびDNSKEY RRにおけるフラグビット: [RFC3755]でDNSSEC KEYおよび DNSKEY RRのフラグビットに関するIANAレジストリを開設した。 当座、このレジストリはビット7(署名鍵ビット)とビット15(SEPビット: [RFC3757]参照)だけを保持する。[RFC3755]で記述されるとおり、 ビット0-6と8-14は値割り当てに関するIETF標準化活動を経た後に 使用可能である。 8. セキュリティに関する考慮点 本文書はDNSSECで使用する4つのDNSリソースレコードの書式と、公開鍵の 鍵タグを計算するアルゴリズムを示した。以下に示すものを除けば、 リソースレコードそれ自体はセキュリティに関する考慮点を導入する ものではない。これらのレコード使用に関する付加的なセキュリティに関する 考慮点については、[RFC4033]と[RFC4035]を参照のこと。 DSレコードは、暗号ダイジェスト、鍵アルゴリズムタイプおよび鍵タグを 使用してDNSKEY RRを参照する。DSレコードは既存のDNSKEY RRを 特定することを意図しているが、理論的には攻撃者がDSフィールドと一致する DNSKEYを偽造することは可能である。DSフィールドと一致するDNSKEYを 偽造される確率は、使用するダイジェストアルゴリズムのタイプに依存する。 現在定義されているダイジェストアルゴリズムはSHA-1だけである。 DSレコードが持つアルゴリズム、鍵タグおよびSHA-1ダイジェストと一致する 公開鍵を偽造することは極めて困難であるため、ワーキンググループは 先に述べた攻撃は現状において深刻な脅威にならないと信じている。 鍵タグはDNSKEYリソースレコード選択の効率化を補助するために使用する。 しかし鍵タグは単一のDNSKEYリソースレコードを特定しない。二つの異なる DNSKEY RRが同じ所有者名、同じアルゴリズムタイプおよび同じ鍵タグを持つ 可能性はある。鍵タグだけを使ってDNSKEY RRを選択する実装は、ある状況下 では誤った公開鍵を選択してしまうかもしれない。詳細については付録Bを 参照のこと。 Arends, et al. Standards Track [Page 21] RFC 4034 DNSSEC Resource Records March 2005 付録Aのアルゴリズム表と付録Bの鍵タグ計算アルゴリズムには、完全性を 期すためにRSA/MD5アルゴリズムを含めているが、[RFC3110]で説明されている ようにこれらの使用は推奨されない(NOT RECOMMENDED)。 9. Acknowledgements This document was created from the input and ideas of the members of the DNS Extensions Working Group and working group mailing list. The editors would like to express their thanks for the comments and suggestions received during the revision of these security extension specifications. Although explicitly listing everyone who has contributed during the decade in which DNSSEC has been under development would be impossible, [RFC4033] includes a list of some of the participants who were kind enough to comment on these documents. 10. References 10.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. [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 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. [RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999. [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000. [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001. Arends, et al. Standards Track [Page 22] RFC 4034 DNSSEC Resource Records March 2005 [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002. [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003. [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 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. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, 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. 10.2. Informative References [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2537] Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)", RFC 2537, March 1999. [RFC2539] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", RFC 2539, March 1999. [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000. [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format", RFC 3845, August 2004. Arends, et al. Standards Track [Page 23] RFC 4034 DNSSEC Resource Records March 2005 付録A. DNSSECが使用するアルゴリズム・ダイジェストタイプ DNSSECは使用する暗号アルゴリズムから独立であるように設計されている。 DNSKEY、RRSIGおよびDSリソースレコードは、全てDNSSECアルゴリズム番号で リソースレコードが使用する暗号アルゴリズムを特定する。 また、DSリソースレコードはダイジェストアルゴリズム番号でDSレコード生成に 使用したダイジェストアルゴリズムを特定する。 現在定義されているアルゴリズムおよびダイジェストタイプを以下に列挙する。 暗号技術の進展により、新たなアルゴリズムまたはダイジェストタイプの追加が 正当化されるのであれば、それらが追加されることもあり得る。 DNSSEC対応リゾルバあるいはネームサーバは必須(MANDATORY)アルゴリズムを 全て実装しなければならない(MUST)。 A.1. DNSSECアルゴリズムタイプ DNSKEY、RRSIGおよびDS RRは使用するセキュリティアルゴリズムを特定するために 8ビットの番号を使用する。この値はリソースレコードのRDATA内にある "アルゴリズム番号"フィールドに保存される。 あるアルゴリズムはゾーン署名(DNSSEC)でしか使用できない。あるものは トランザクションセキュリティの仕組み(SIG(0)およびTSIG)でしか使用 できない。またあるものは両方で使用できる。ゾーン署名で使用可能なものは DNSKEY、RRSIGおよびDS RRで使用される。トランザクションセキュリティで 使用可能なものは、[RFC2931]が記述するようにSIG(0)とKEY RRで使用される。 ゾーン 値 アルゴリズム [ニーモニック] 署名 参考文献 状態 ----- -------------------------- --------- ---------- --------- 0 予約済み 1 RSA/MD5 [RSAMD5] n [RFC2537] 推奨されない 2 Diffie-Hellman [DH] n [RFC2539] - 3 DSA/SHA-1 [DSA] y [RFC2536] 任意 4 Elliptic Curve [ECC] 追加予定 - 5 RSA/SHA-1 [RSASHA1] y [RFC3110] 必須 252 Indirect [INDIRECT] n - 253 プライベート [PRIVATEDNS] y 後述 任意 254 プライベート [PRIVATEOID] y 後述 任意 255 予約済み 6 - 251 IETF標準化活動によって割り当て可能 Arends, et al. Standards Track [Page 24] RFC 4034 DNSSEC Resource Records March 2005 A.1.1. プライベートアルゴリズムタイプ アルゴリズム番号253はプライベート使用のために予約済みであり、 特定のアルゴリズムに割り当てられることはない。DNSKEY RRの公開鍵データ部と RRSIG RRの署名データ部はワイヤーエンコードされたドメイン名で開始する。 この際圧縮をしてはならない(MUST NOT)。ドメイン名はプライベートアルゴリズム 使用を示すものであり、公開鍵データ部の残り部分はそのアルゴリズムによって 決定される。プライベートアルゴリズム使用であることを明示する際に、 使用者は自身が制御するドメイン名だけを使用すべきである。 アルゴリズム番号254はプライベート使用のために予約済みであり、 特定のアルゴリズムに割り当てられることはない。 DNSKEY RRの公開鍵データ部とRRSIG RRの署名データ部は、データのバイト長を 符合無し整数で表現したもので開始され、そのバイト長のBER符号化した オブジェクトID(ISO OID)が続く。OIDはプライベートアルゴリズム使用を明示し、 データ部の残り部分はアルゴリズムが必要とするデータである。 使用者は、プライベートアルゴリズム使用であることを明示する際に、 自身が制御するOIDだけを使用すべきである。 A.2. DNSSECダイジェストタイプ DSリソースレコードタイプの"ダイジェストタイプ"フィールドは、リソース レコードが使用する暗号ダイジェストアルゴリズムを特定する。 現在定義されているダイジェストアルゴリズムタイプを以下の表に列挙する。 値 アルゴリズム 状態 0 予約済み - 1 SHA-1 必須 2-255 身割り当て - 付録B. 鍵タグの計算 RRSIGおよびDSリソースレコードタイプの鍵タグフィールドは、公開鍵を効率的に 選択する仕組みを提供する。ほとんどの場合、所有者名、アルゴリズムおよび 鍵タグの組み合わせにより、効率的にDNSKEYレコードを特定することができる。 RRSIGおよびDSリソースレコードはどちらも対応するDNSKEYレコードを持つ。 RRSIGおよびDSレコード内の鍵タグフィールドを使用することにより、複数個の DNSKEY RRが利用可能な場合に効率的に対応するDNSKEY RRを選択することが できる。 しかし、鍵タグが一意なIDではないことに注意することは極めて重要である。 理論的には、2つの異なるDNSKEY RRが同じ所有者名、同じアルゴリズム、同じ 鍵タグを持つことはあり得る。したがって、鍵タグを使用して鍵候補を限定 することはできるが、DNSKEYレコードを一意に特定するものではない。 DNSSEC実装は、鍵タグがDNSKEY RRを一意に特定すると想定してはならない (MUST NOT)。 Arends, et al. Standards Track [Page 25] RFC 4034 DNSSEC Resource Records March 2005 アルゴリズム1を除き、鍵タグは全てのDNSKEYアルゴリズムタイプで同じ 定義を持つ(アルゴリズム1用鍵タグの定義は付録B.1を参照のこと)。 鍵タグアルゴリズムは、DNSKEY RDATAのワイヤーフォーマットを 2オクテット単位のグループに分割し、その和を取るものである。 はじめに、(ワイヤーフォーマットの)RDATAを2オクテット単位のグループの 並びとみなす。次にキャリービットを無視してこれらのグループを順次 足していく。 ANSI Cの関数として実装した鍵タグアルゴリズムのリファレンス実装を 以下に示す。この関数はDNSKEY RRのRDATA部を入力として使用する。 以下のリファレンスコードをそのまま使用する必要はないが、同じ入力に 対してリファレンス実装が生成したのと同じ鍵タグ値を得られなければ ならない(MUST)。 鍵タグ計算アルゴリズムは、多くのインターネットプロトコルが使用する 1の補数を使用したチェックサム計算とほとんど同じではあるが、完全に 同一ではないことに注意してもらいたい。鍵タグは1の補数を使用した チェックサムではなく、ここに記述するアルゴリズムで計算しなければ ならない(MUST)。 以下のANSI Cレファレンス実装は鍵タグ値を計算する。このレファレンス実装は アルゴリズム1(付録B.1参照)以外の全アルゴリズムに適用できる。 入力はDNSKEY RRのRDATA部のワイヤーフォーマットである。コードは明確さを 目標に記述されており、効率性については考慮していない。 /* * intは最低16ビットであるものとする。 * 鍵タグの第1オクテットは戻り値の上位8ビットである。 * 鍵タグの第2オクテットは戻り値の下位8ビットである。 */ unsigned int keytag ( unsigned char key[], /* DNSKEY RRのRDATA部 */ unsigned int keysize /* RDATA部の大きさ */ ) { unsigned long ac; /* 32ビット以上を想定 */ int i; /* ループインデックス */ for ( ac = 0, i = 0; i < keysize; ++i ) ac += (i & 1) ? key[i] : key[i] << 8; ac += (ac >> 16) & 0xFFFF; return ac & 0xFFFF; } Arends, et al. Standards Track [Page 26] RFC 4034 DNSSEC Resource Records March 2005 B.1. アルゴリズム1(RSA/MD5)の鍵タグ アルゴリズム1(RSA/MD5)の鍵タグは、歴史的理由により他の全てのアルゴリズム とは異なる形で定義される。アルゴリズム1を使用するDNSKEY RRの鍵タグは、 公開鍵のModulusの下位24ビットのうち上位16ビットとして定義される。 (言い換えると、公開鍵Modulusオクテット列の最後から3番目と最後から2番目の オクテットである(訳注))。 ========================================================================== ※訳注: 4行目の( )内について。 原文ではin other words, the 4th to last and 3rd to last octets of the public key modulus. となっており、「4番目と3番目」のように 書かれているが、下位24ビットのうち上位16ビットと矛盾するため 翻訳時に「3番目と2番目」に修正した。 ========================================================================== アルゴリズム1は推奨されない(NOT RECOMMENDED)ことに注意してもらいたい。 Arends, et al. Standards Track [Page 27] RFC 4034 DNSSEC Resource Records 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 28] RFC 4034 DNSSEC Resource Records 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 29]