ネットワークワーキンググループ 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セキュリティ拡張で使用するリソースレコード 本文書の位置づけ 本文書はインターネットコミュニティーのためにインターネット標準化過程に あるプロトコルを規定し、その向上のために議論と提案を求めるものである。 このプロトコルの標準化の状況については"Internet Official Protocol Standards"(STD 1)の最新版を参照のこと。本文書の配布は制限されない。 著作権表示 Copyright (C) The Internet Society (2005). 要旨 本文書はDNSセキュリティ拡張(DNSSEC)について規定する文書群の1つである。 DNSセキュリティ拡張は、データ生成元の認証を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. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. 必須の参考文献 . . . . . . . . . . . . . . . . . . . . 22 10.2. 有用な参考文献 . . . . . . . . . . . . . . . . . . . . 23 A. DNSSECが使用するアルゴリズム・ダイジェストタイプ . . . . . . 24 A.1. DNSSECアルゴリズムタイプ . . . . . . . . . . . . . . . 24 A.1.1. プライベートアルゴリズムタイプ . . . . . . . . 25 A.2. DNSSECダイジェストタイプ . . . . . . . . . . . . . . . 25 B. 鍵タグの計算. . . . . . . . . . . . . . . . . . . . . . . . . 25 1. はじめに DNSSEC(DNS Security Extensions)は新しい4つのDNSリソースレコードタイプ、 DNSKEY(DNS Public Key)、RRSIG(Resource Record Signature)、NSEC (Next Secure)およびDS(Delegation Signer)を導入する。本文書は各リソース レコード(RR)の目的と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)の署名および 認証を行う。公開鍵はDNSKEYリソースレコードに保存され、[RFC4035]が規定する DNSSEC認証で使用される。ゾーンは、ゾーン内にある権威を持つRRsetに秘密鍵で 署名し、対応する公開鍵を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はゾーン鍵フラグである。ビット7が1ならばDNSKEY レコードはDNSゾーン鍵を保持する。その場合DNSKEY RRの所有者名はゾーンの名前 でなければならない(MUST)。ビット7が0ならばDNSKEYレコードはDNSゾーン鍵以外の 公開鍵を保持する。したがってRRsetの署名を持つRRSIGの検証に使用しては ならない(MUST NOT)。 Arends, et al. Standards Track [Page 4] RFC 4034 DNSSEC Resource Records March 2005 フラグフィールドのビット15は[RFC3757]が規定する安全なエントリー地点 (SEP: Secure Entry Point)フラグである。ビット15が1ならばDNSKEYレコードは 安全なエントリー地点として使用される鍵を保持する。このフラグは、ゾーン署名 またはデバッグを行うソフトウェアに対して、そのDNSKEYレコードが 適切に使われているかに関するヒントを与えるだけのものである。 したがって、検証者はこのビットが設定されているかに応じて署名検証処理を 変化させてはならない(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)。署名検証時に プロトコルフィールドが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への署名および認証を行う。電子署名は RRSIGリソースレコードに保存され、[RFC4035]が規定するDNSSEC認証で 使用される。検証者はRRSIG RRを使用して、RRsetがそのゾーンの出自であると 認証することができる。RRSIG RRは、安全なDNS運用のために使用する検証素材 (電子署名)を運ぶ目的だけのために使用されなければならない(MUST)。 RRSIGレコードは特定の名前、クラスおよびタイプのRRsetの署名を持つ。 RRSIG RRは、署名の有効期間、使用アルゴリズムおよび署名者名と、検証者が 署名検証で使用する公開鍵を持つDNSKEY RRを特定する鍵タグ(Key Tag)を 指定する。 一つのゾーン内では、権威を持つ全てのRRsetは電子署名で保護されなければ ならないため、CNAME RRを含む名前に対してRRSIG RRが存在しなければならない。 これは従来のDNS仕様[RFC1034]からの変更点である。従来のDNS仕様では、 ある名前に対して別名が存在する場合、それ以外の型はその名前に対して 存在を許されていなかった。署名付きゾーンでは、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である場合、個々の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の完全修飾所有者名(fully qualified owner name) を正規形式(ワイルドカードを含む所有者名の場合、ワイルドカード ラベルも所有者名に含められる)で表現したもの。 各RRの所有者名はRRSIG RRの所有者名と同じでなければならない (MUST)。 各RRのクラスはRRSIG RRのクラスと同じでなければならない (MUST)。 RRset内の各RRはRRSIG RRの署名対象フィールドに記載された 一覧に含まれるRRタイプでなければならない(MUST)。 RRset内の各RRはRRSIG RRのオリジナルTTLフィールドに記載された 一覧に含まれるTTLでなければならない。 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つは権威を持つデータ または委任点のNS RRsetを持つ(ゾーンの正規順序における)次の所有者名 であり、もう1つはNSEC RRの所有者名に関連づけられるRRタイプの集合である。 ゾーン内のNSEC RRの完全な集合は、ゾーン内に存在する権威を持つRRsetが どれかを示すと同時に、ゾーン内の権威を持つ所有者名の連鎖を形成する。 この情報を使用して[RFC4035]が規定するDNSデータの不在証明を行う。 一つのゾーン内では、権威を持つ全ての名前はNSEC連鎖の一部でなければ ならないため、CNAME RRを含む名前に対してNSEC RRが存在しなければ ならない。これは従来のDNS仕様[RFC1034]からの変更点である。従来の DNS仕様では、ある名前に対して別名が存在する場合、それ以外の型は その名前に対して存在を許されていなかった。署名付きゾーンでは、 CNAMEリソースレコードを持つ同じ名前に対してRRSIG(セクション3参照)と NSECが存在しなければならない(MUST)。 ゾーンに設定する必要があるNSEC RRをゾーン署名者が厳密に決定する方法に ついては、[RFC4035]を参照のこと。 NSEC RRのタイプ値は47である。 NSEC RRはクラス非依存である。 NSEC RRはSOAの最小TTLフィールドの値と同じTTLを持つべき(SHOULD)である。 これはネガティブキャッシュ([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. 次ドメイン名フィールド 次ドメイン名フィールドは、権威を持つデータまたは委任点となる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つ持つブロックは、ウインドウ番号(0〜255)1オクテット、ビットマップの オクテット数を示すビットマップ長(1〜32)1オクテットに最大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が存在することを意味する。 擬似RRタイプ(pseudo-type)はゾーンデータには表れないので、これを表現する ビットはクリアされていなければならない(MUST)。該当ビットが設定されていた 場合は、読み出し時に無視しなければならない(MUST)。 タイプを持たないブロックを含めてはならない(MUST NOT)。ビットマップ内の 末尾ゼロ(trailing-zero)オクテットは省略しなければならない(MUST)。 各ブロックのビットマップ長は、NSEC RRの所有者名に対して設定される RRタイプ値の中で、そのブロックが表現しようとするタイプコードの最大値に 応じて決定される。明示的に指定されない末尾ゼロオクテットは ゼロオクテットとして解釈されなければならない(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の完全修飾所有者名と その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名の正規順序づけ DNSセキュリティ拡張では、所有者名を構成する個々のラベルを符号無し 左揃えのオクテット文字列として扱い、これを順序づけする。オクテットが 存在しない場合、ゼロ値のオクテットの前に順序づけられ、また大文字の 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の正規形式 DNSセキュリティを実現するために必要なRRの正規形式は、以下の条件を満たす RRのワイヤーフォーマットである。 1. RR内の各ドメイン名は完全に展開され(DNS名前圧縮を使用せず)、完全修飾 されている。 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の正規順序づけ DNSセキュリティ拡張では、同じ所有者名、クラスおよびタイプを持つRRは 正規形式化したRDATA部を左揃えのオクテット列として扱うことによって 順序づけする。オクテットが存在しない場合はゼロ値のオクテットの前に 順序づけられる。 [RFC2181]の規定では、RRsetは重複したレコード(同じ所有者名、クラス、 タイプおよびRDATAを持つ複数のRR)を持つことができない。したがって、実装が RRsetを正規形式に変換する際に重複したRRを検知したならば、プロトコル エラーとして処理しなければならない(MUST)。実装がこのプロトコルエラーを 堅牢性の原則(受け付ける時は寛大に、送る時は保守的に)にしたがって処理する ことを選択したならば、RRsetの正規形式を算出するために複数のRRは1つを除いて 全て除去しなければならない(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セキュリティ拡張でどう使われるか に関するフラグを含めた。各アルゴリズムエントリはゾーン署名、 トランザクションセキュリティ([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. セキュリティに関する考慮点 本文書はDNSセキュリティ拡張で使用する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. 謝辞 本文書はDNS Extensionsワーキンググループメンバおよびワーキンググループ メーリングリストのインプットとアイディアから作成された。セキュリティ拡張 仕様改訂の間にもらったコメントと提案に対して、編者らは感謝の意を表する。 DNSSECが開発途上であった10年間に貢献してくれた全員を列挙することは できないが、[RFC4033]で一連の文書群に対して充分なコメントをくれた人たちの 一覧を提示している。 10. 参考文献 10.1. 必須の参考文献 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [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. 有用な参考文献 [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が使用するアルゴリズム・ダイジェストタイプ DNSセキュリティ拡張は、使用する暗号アルゴリズムから独立であるように 設計されている。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レコードを一意に特定するものではない。 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ビットとして定義 される。(言い換えると、公開鍵ビット列表現の後ろから3番目と2番目(*1)の オクテットである)。 《(*1)訳注》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 著者の連絡先 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 完全な著作権表示 Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 知的所有権に関する表示 The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 謝辞 RFCエディタの活動に対する資金は現在Internet Societyによって提供されて いる。 Arends, et al. Standards Track [Page 29] RFC4034-ja.txt revision 1.1 この翻訳文に関するお問い合わせは dnstech-info@jprs.jp までご連絡下さい。 Japan Registry Service Co., Ltd. http://jprs.jp/tech/