Network Working Group D. Eastlake Request for Comments: 2535 IBM Obsoletes: 2065 March 1999 Updates: 2181, 1035, 1034 Category: Standards Track ドメインネームシステムのセキュリティ拡張 このメモの位置づけ このドキュメントはインターネットコミュニティのためのインターネッ ト標準プロトコルを記すとともに、改善のための議論および提案を要求 するものです。標準化状況と、このプロトコルの位置づけは、「インター ネット公式プロトコル標準」(STD 1) を参照してください。このメモの 配布に制限はありません。 概要 Domain Name System(DNS) への拡張は、データの完全性や暗号化デジタ ル署名の使用による "security aware" なリゾルバやアプリケーション へのセキュリティへの証明の提供について述べられています。これらの デジタル署名はリソースレコードとしてのセキュアなゾーン中に含まれ ます。また、セキュリティはいくつかのケースにおいて "non-security aware" な DNS サーバによっても提供可能です。 拡張は DNS における公開暗号鍵の格納場所を提供します。この鍵の格納 により DNS セキュリティと同様に公開鍵配布サービスをサポートするこ とができます。格納された鍵は、"security aware" なリゾルバに対し、 それらが初期生成されるものに加えてゾーンの証明キーを学習させるこ とができます。 DNSネームに関連した鍵は他のプロトコルをサポートす るために検索されることが可能です。様々なキータイプやアルゴリズム に対する規定がなされています。 さらに、セキュリティ拡張は DNS プロトコル処理およびリクエストの付 加的な証明を提供します。 このドキュメントは、初期の実装者や潜在的ユーザからの RFC2065 上の フィードバックを統合しています。 以下に記す方々(アルファベット順)による 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 TTL(生存時間) に付随する特別に考慮すべき点...........7 2.3.4 委譲ポイントにおける特別な考慮点.....................8 2.3.5 CNAME にまつわる特別な考慮点.........................8 2.3.6 ゾーン以外の署名者...................................9 2.4 DNS トランザクション、リクエスト証明...................9 3. KEY リソースレコード...................................10 3.1 KEY リソースデータフォーマット........................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 「保護タイプ」フィールド............................18 4.1.2 アルゴリズム番号フィールド..........................18 4.1.3 ラベルフィールド....................................18 4.1.4 オリジナル TTL フィールド...........................19 4.1.5 署名満了、開始フィールド............................19 4.1.6 キー・タグフィールド................................20 4.1.7 署名者ネーム フィールド.............................20 4.1.8 署名フィールドd.....................................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 KEY を通した連鎖....................................31 6.3.2 Conflicting Data....................................33 6.4 安全な時間............................................33 7. ASCII Representation of Security RRs...................34 7.1 Presentation of KEY RRs...............................34 7.2 Presentation of SIG RRs...............................35 7.3 Presentation of NXT RRs...............................36 8. リソースレコードの正規形と正規順.......................36 8.1 正規リソースレコード形................................36 8.2 正規 DNS ネーム順.....................................37 8.3 Rset 内の 正規リソースレコード順......................37 8.4 Canonical Ordering of RR Types........................37 9. Conformance............................................37 9.1 Server Conformance....................................37 9.2 Resolver Conformance..................................38 10. Security Considerations...............................38 11. IANA Considerations...................................39 References................................................39 Author's Address..........................................41 Appendix A: Base 64 Encoding..............................42 Appendix B: Changes from RFC 2065.........................44 Appendix C: Key Tag Calculation...........................46 Full Copyright Statement..................................47 1. あらすじ このドキュメントは DNS セキュリティと公開鍵配布のサポートを行う DNS プロトコルへの拡張を標準化するものです。DNS (RFC1033、1034、 1035、およびその後の RFC) に親しんでいる読者を想定しています。こ の拡張の初期バージョンは RFC2065 にて登場しました。RFC2065 への置 き換えには潜在的ユーザからの初期実装の経験や要求を織り込んでいま す。 セクション 2 は拡張のあらすじ、鍵配布、データ元証明、それらが実行 するトランザクションやリクエストセキュリティを提供します。 セクション 3 は KEY リソースレコード、その構造、DNS 応答における 使用法について議論します。このリソースレコードは DNS において名前 付けされた要素の公開鍵を表し、鍵配布のために利用されます。 セクション 4 は SIG デジタル署名リソースレコード、その構造、DNS 応答における使用法について議論します。このリソースレコードは DNS 中の他のリソースレコードを証明するのに使われたり、補助的に DNS の トランザクションやリクエスト証明に利用されます。 セクション 5 は NXT リソースレコードと、完全および増分ゾーン転送 を含む DNS 応答における利用について議論します。NXT レコードは、証 明による名前の存在や既存の名前に対するリソースレコードタイプの否 認を許可します。 セクション 6 ではリゾルバがどのように鍵とともに初期化されるか、ま たセキュアな DNS リクエストの解決を始めるかについて議論します。リ ゾルバとサーバ間の挙動は、 "security aware" と "security non-aware" の様々な組合せとともに議論されています。2つの追加 DNS ヘッダビットがリゾルバとサーバとの間のシグナリングのために定義さ れています。 セクション 7 では、マスターファイルや他のところでセキュリティリソー スレコードを使用するための ASCII 表現について議論しています。 セクション 8 は DNS のセキュリティ目的のためのリソースレコードの 正規形や順番を定義しています。 セクション 9 ではリゾルバとサーバの適合レベルを定義しています。 セクション 10 はいくつかのセキュリティ上の考慮点を挙げています。 セクション 11 はこのドキュメントで定義されたパラメータの追加場所 に対する IANA の考察を示しています。 付録 A はこのドキュメント中で定義されたいくつかの RR の表現をファ イル中で使用するときに利用される base64 エンコーディングの詳細を 与えています。 付録 B は RFC2065 とこのメモ間の相違点をまとめています。 付録 C はほとんどの SIG RR 中のキー・タグとして使われる簡単なチェッ クサムの計算方法を明記しています。 このドキュメント中のキーワードである、"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は、[RFC 2119] で述べられている ように解釈されます。 2. DNS 拡張のあらすじ DNS プロトコルのセキュリティ拡張は 3つ (セクション 2.2 で述べられ る鍵配布、セクション 2.3 で述べられるデータ元証明、セクション 2.4 で述べられるトランザクション、リクエスト証明) のサービスを提供し ます。 「生存時間 (TTL)」や CNAME 、委譲ポイントに関連する特別な考察もセ クション 2.3 で述べられています。 2.1 提供されていないサービス その中のデータがパブリックであり、全ての問い合わせに対し同じ回答 を与えることは DNS の設計哲学の一部です。この哲学にならい、アクセ スコントロールリストや問い合わせの差別化のための他の方法を含める 試みはなされていません。 問い合わせや応答の秘匿性のための努力はなされたことがありません。 (このサービスは IPSEC [RFC2401] や、TLS、他のプロトコルによって可 能です。) DoS 攻撃に対する防御策も提供されていません。 2.2 鍵の配布 リソースレコードのフォーマットは DNS ネームに鍵を関連づけるよう定 義されます。これにより DNS が DNS セキュリティや他のプロトコルの サポートにおいて公開鍵を配布する機構として使われることが可能にな ります。 KEY リソースレコードの文法はセクション 3 にて述べられています。そ れには、アルゴリズム、実際の公開鍵パラメータ、実体に関連した鍵か 否かを表す様々なフラグが含まれます。 セクション 3.5 で述べられている条件の下では、"security aware" な DNS サーバは (最低限の問い合わせのために) 実際の要求されたリソー スレコードと一緒に付加情報として KEY リソースを返すよう自動的に試 みるであろう、と記述されています。 2.3 データ元の証明と完全性 証明は生成された DNS 暗号デジタル署名中でリソースレコードセット (RRsets [RFC2181]) に関連付けされて提供されます。一般的に、ゾーン 全体を証明する単一の秘密鍵が存在するでしょう (異なったアルゴリズ ムや署名者による複数の鍵は存在するかもしれません) 。もし、 "security aware" なリゾルバが確実にゾーンの公開鍵をそのゾーンから 読み込んだ署名済データのために学習すれば、それが適切に認可された ことを証明することができます。最もセキュアな実装はゾーンの秘密鍵 をオフラインに保ち、定期的にゾーン中のすべてのレコードを再署名す る仕組みです。しかし、動的更新 [RFCs 2136,2137] のように DNS 秘密 鍵がオンラインである必要のある [RFC 2541] 場合があります。 データ元証明鍵はデータのコピーが保存されているサーバにではなくゾー ンに関連しています。このことは、セカンダリサーバの妥協、または、 もし鍵がオフラインで維持されかつゾーン用のプライマリサーバであっ たとしても、データが本物であるかを決定する機能をリゾルバが持って いるという保証度合に必ずしも影響しないことを意味します。 リゾルバはゾーンの公開鍵を DNS から読み込むか、静的に設定されるこ とによって学習することができます。DNS からの読み込みにより確実に 公開鍵を学習するために、鍵自身がリゾルバが信頼する鍵により署名さ れなければなりません。リゾルバは出発点として、1つのゾーンを証明す る少なくとも 1つの公開鍵で形成されるはずです。そこから、DNS ツリー の中間ゾーンがセキュアでありまたそれらの署名済の鍵にアクセス可能 であれば、他のゾーンの公開鍵を安全に読むことができます。 データ元証明と完全性の追加には、鍵配布に必要な署名リソースタイプ と鍵リソースタイプの追加の他には既存の DNS プロトコルの変更を必要 としません (データ非存在証明は NXT RR (セクション 2.3.2) を必要と します)。このサービスは現存するリゾルバやキャッシュサーバ実装が 付加リソースタイプ (セクション 9 を参照) をサポートできる限りサポー トされます。一つ例外として、"non-security aware" なサーバからのセ キュアゾーン中の CNAME 参照は証明されません (セクション 2.3.5 を 参照)。 もし、署名が別々に検索されたり、証明する情報を検索しているときに 証明された場合、サーバに余計な処理が発生し、パフォーマンスに影響 を及ぼします。"security aware" なサーバは必要な分の署名を送ること によりそのような状況悪化を軽減します (セクション 4.2 を参照)。 2.3.1 SIGリソースレコード SIG リソースレコード (署名) の文法はセクション 4 にて紹介されてい ます。SIG RR は署名者や有効期限に署名されている RRset を暗号に結 びつけます。 セキュアゾーン中の各々の名前は、グルーレコードと委譲ポイント NS レコード以外のその名前下のリソースタイプ毎のために少なくとも 1つ の SIG RR と関連づけられているでしょう。"security aware" なサーバ は検索された RR と共に対応した SIG を返そうとします。もし "security aware" なサーバでなければ、リゾルバは名前のために全ての SIG レコードを検索し、リゾルバが関心をもつリソースレコードセット を署名したものを選択しなければならなりません。 2.3.2 存在しない名前やタイプへの証明 上記のセキュリティ機構はゾーンに存在する RRset へ署名する方法を提 供しているに過ぎません。「データ元」証明はゾーン中に存在しないド メインネームや、存在しないタイプを持つドメインネームには明らかに 提供されません。このギャップは、(ゾーン中の非存在名の範囲やその範 囲の直前の存在する名前に対する非存在タイプを確信を持って主張する) NXT RR により満たされます。 セクション 5 以下で NXT RR をカバーしています。 2.3.3 TTL(生存時間) に付随する特別に考慮すべき点 データが最初に署名された時から署名が検証される時までにそのデータ に変更が加わっていた場合、デジタル署名は失敗します。これは、我々 が期待している、キャッシュされている間カチカチと減っていくリソー スレコードの TTL (生存時間) フィールドの存在と矛盾してしまいます。 これは生存時間をデジタル署名から除外すれば回避できますが、検出さ れない勝手に長い TTL 値を設定している良心的でないサーバを許可して しまうことになります。代わりに、「オリジナル」 TTL を署名に含める ことで正しい TTL を持つデータとコミュニケートできます。このような 企みをもった良心的でないサーバは TTL を操作できますが、"security aware" なリゾルバは TTL を突き返し、署名された値を使います。署名 は 「署名開始時間」 と 「署名満了時間」 を別々に含んでいます。絶 対時間を知っているリゾルバは、署名が有効かどうかを安全に判断する ことができます。TTL は本来データベースに存する機構であり、 "non-security aware" サーバは TTL がサポートされていることを前提 にしているので、単独で TTL の代わりに署名の満了時間に依存すること はできません。 2.3.4 委譲ポイントにおける特別な考慮点 DNS セキュリティは、完全にゾーン・マネージャーによって握られた特 別な秘密鍵によって署名された各エントリー (RRset) を持つゾーン所有 者の管理下でデータのユニットとして各ゾーンを見たいでしょう。しか し、DNS プロトコルはゾーンの葉ノード (それはまた、サブゾーンの頂 点ノード (つまり委譲ポイント) でもある) を「実際」にサブゾーンに 属していると見なします。 スーパーゾーンがセキュアな場合、各サブゾーンにはスーパーゾーンに よって署名されたゾーン KEY RR がなければいけません (MUST)。しかし、 セキュリティ用の RR が追加されたり変更されることがないようなセキュ アでないサブゾーンの場合は、サブゾーンがセキュアでないことを宣言 する KEY がスーパーゾーンの署名とともにスーパーゾーンになくてはい けません (MUST)。サブゾーン KEY RR だけはスーパーゾーンにより署名 されるべきですが、それ以外の全ての RR についてサブゾーンからのデー タは権威的です。NS RR といくつかの グルーアドレス RR はサブゾーン 内でのみ署名されるべきです (SHOULD)。 所有者としてゾーン名を持つ SOA RR と他のいくつかの RR はサブゾーンにのみ現れるべきであり、以 上のようにここでのみ署名されます。セクション 5 で述べるように、スー パーゾーンとサブゾーンが両方とも安全な場合、 NXT RR タイプは両方 において常に権威的でかつ異なって現れる異例です。 2.3.5 CNAME にまつわる特別な考慮点 セキュリティが CNAME RR として関連づけた同所有者名を持つ RR を "security aware" でないサーバから検索した時に問題が発生します。特 に、最初の CNAME や他のタイプの検索は、関連する SIG RR や KEY RR, NXT RR を検索しないかもしれません。CNAME 以外の検索されたタイプに ついては、CNAME (または CNAME の連鎖) のターゲット名でそのタイプ を検索し、さらに CNAME を返すでしょう。特に、特定のタイプ SIG の 検索はオリジナル CNAME ドメインネーム、正確にはターゲット名に対す る SIG を (もしあったとしても) 得ることはないでしょう。 "security aware" なサーバは DNS における CNAME を安全なものとする ため使用されなければなりません。"security aware" なサーバは (1) CNAME RR と一緒についてくる KEY, SIG, NXT RR を許可しなくては いけません (MUST)。 (2) CNAME の検索と同様にこれらの検索上の CNAME を抑制しなければな りません (MUST)。 (3) 問い合わせの解決において遭遇した CNAME を証明した SIG RR を自 動的に返さなければなりません (MUST)。 これは、CNAME RR が存在するノードにおいて他の RR タイプを禁止して いたこれまでの DNS 標準 [RFCs 1034/1035] からの変更です。 2.3.6 ゾーン以外の署名者 SIG リソースレコードの署名者がゾーンを証明するのに使われた秘密鍵 以外である場合が存在します。 一つは、エンティティがそのレコードを証明および更新することを許可 されており [RFC 2137]、ゾーン・キーがオンラインでないモードでゾー ンが操作されている場合における動的更新 [RFC 2136] (または、セキュ アな証明を要求する将来のリクエスト) のための場合です。エンティティ の公開鍵は DNS 中に現れなければならなく、またゾーンレベルの鍵によ り署名されていなければなりませんが、他の RR はエンティティの鍵で 署名されても構いません。 二つめのケースは、セクション 2.4 で述べられているトランザクション やリクエスト証明のサポートです。 備考として、署名は DNS 以外のアプリケーションで利用されるために DNS リソースレコードに含まれる可能性があります。DNS が関連付けた 署名は、ゾーン所有者の権威をもつ起源データや、適切なエンティティ によるリクエストやトランザクションであることを証明します。他の署 名は他の保証タイプを提供することができます。 2.4 DNS トランザクション、リクエスト証明 上で述べたデータ元証明サービスは検索されたリソースレコードと存在 しないリソースレコードを保護しますが、DNS リクエストやメッセージ ヘッダの保護は提供しません。 もし悪いサーバにより間違ってヘッダビットがセットされていたとして も、できることはほとんどありません。しかし、トランザクション証明 を追加することは可能です。このような証明は、リゾルバにとって少な くともサーバからの要求に対するメッセージを受け取ることや、送信し た問い合わせからの応答 (これらのメッセージは通過途中で改ざんされ ていない) であることを確信させるものです。これは、リゾルバの問い 合わせやサーバの応答の連続性を電子的に署名するリプライの最後につ く特別な SIG リソースレコードを任意的に付け加えることによって達成 されます。 リクエストもまた、その最後に特別な SIG RR を含めることで証明でき ます。リクエストを証明することは古い DNS サーバでは機能せず、空で ない付加情報部はエラーを返させるか、ほとんどの場合無視されるでしょ う。しかし、このリクエストを署名するシンタックスは、セキュアな動 的更新リクエスト [RFC 2137] を証明する方法や、将来の証明要求リク エストとして定義されています。 トランザクション・セキュリティ中で使われる秘密鍵は含まれるゾーン ではなく、リプライを構成するエンティティに属します。リクエスト証 明もまた、確立のために要求されるリクエストの権威に依存するホスト の秘密鍵や他のリクエストを構成するエンティティや他の秘密鍵を含む かもしれません。対応する公開鍵は通常、検証のために DNS へ格納され DNS から検索されます。 リクエストとリプライはかなり変化するのでメッセージ証明 SIG をあら かじめ計算することができません。このように、秘密鍵をオンライン、 例えばソフトウェアや直接接続されたハードウェアの一部で保持するこ とが必要でしょう。 3. KEY リソースレコード KEY リソースレコード (RR) は DNS ネームに関連している公開鍵を格納 するために利用されます。これはゾーンの公開鍵、ユーザやホストや他 のエンドエンティティの公開鍵であるでしょう。"security aware" な DNS 実装は少なくとも 2 つの同時に有効な同じ名前に関連付けられた同 じタイプの鍵を扱うよう設計されなければいけません (MUST)。 KEY RR のタイプ番号は 25 です。 KEY RR は、他の RR のように SIG RR によって証明されます。KEY RR はゾーンレベルの鍵で署名されなければなりません。 3.1 KEY リソースデータフォーマット KEY RR のリソースデータはフラグ、プロトコルオクテット、アルゴリズ ム番号オクテット、公開鍵自身から成ります。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | protocol | algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / / public key / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| KEY RR は証明書の格納を意図していません。また、個別の証明書 RR は [RFC 2538] で定義されており、その目的のために開発されています 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) ユーザの DNS ネー ムにマッピングされるか、アカウント foo@host.example であるかもし れません。 このように、以下に述べるようにこれらの KEY RR 中のフラ グビットは所有者名と公開鍵が関連付けられているこれらの役割を示し ています。適切なゾーン KEY RR はセキュアなゾーンの頂点ノードで生 じなければならなく (MUST) 、またゾーン 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 は鍵タイプビットであり、値により以下の意味を持ちます。 10: 証明のための鍵の使用は禁止されます。 11: 機密性のための鍵の使用は禁止されます。 00: 証明および (または) 機密性のための鍵の使用が許可され ます。DNS セキュリティが証明のためだけに鍵を使用する ことに注意してください。機密性利用フラグは他のプロト コルでの鍵の使用のために提供されます。機密性のための 鍵配布のサポートを意図していない実装は、それらが提供 する鍵のために機密性使用禁止フラグを on にすることを 要求するかもしれません。 11: 両方のビットが1である場合、「鍵なし」ということで、鍵 情報はなく、アルゴリズムオクテットの後ろで RR は終り ます。この「鍵なし」値を使用することによって、署名さ れた KEY RR は例えばゾーンが安全ではないことを確信を もって主張することができます。 ビット 2 は予約されていて 0 です。 ビット 3 は、フラグ拡張ビットとして予約されいます。もしそれが 1 であれば、2 番目の 16 ビットフラグフィールドはアルゴリズムオクテッ トの後ろ、鍵データの前に追加されます。一つ以上のこのような追加ビッ トが定義されてない、もしくは 0 である場合は、このビットをセットし てはいけません (MUST NOT)。 ビット 4-5 は予約されていて 0 です。 ビット 6 と 7 は、名前タイプをエンコードするフィールドを形成しま す。フィールドの値は以下の意味を持っています。 00: 鍵がエンドエンティティ、通常ホストのユーザやアカウン トに関連付けられていることを示しています。コード化さ れた所有者名は SOA や RP RR 中の信頼できる個々のメー ルボックスのために使用されています - 所有者名は、エン ティティ名におけるのノードの名前であるユーザ名にあた ります。例えば、host.subdomain.example 上の "j_random_user" というユーザは、 j_random_user.host.subdomain.example という名前を持つ KEY RR を通して関連付けられた公開鍵を持ち得ます。ユー ザの証明がどこで要求されたかをセキュリティプロトコル の中で使用することができるかもしれません。この鍵は IP あるいはユーザレベルサービス (telnet, ftp, rloginなど) のための他のセキュリティにおいても有用かもしれません。 01: 名前が KEY RR 所有者名であるゾーンのためのゾーン・キー であることを示しています。この鍵は、データ元証明の主 要な DNS セキュリティ仕様のために使用される公開鍵です。 ゾーン KEY RR は委譲ポイントでのみ生じます。 10: 名前が RR 所有者名である非ゾーンエンティティに関連付 けられた鍵であることを示しています。これは一般にはホ ストですが、DNS ツリーの一部において、電話番号 [RFC 1530] や数値の IP アドレスといった他のエンティティタ イプでもあり得ます。この鍵は 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 email 3 dnssec 4 IPSEC 5-254 - IANAによる割り当て利用 255 全て さらに詳しく、 1 は TLS 接続のために予約されています。 2 は電子メール接続のために予約されています。 3 は DNS セキュリティのために使用されます。DNS セキュリティ で使用されるゾーン・キーや他の鍵のためにプロトコルフィール ドはこの値にセットすべきです (SHOULD) 。この鍵が、フラグが それをゾーン・キーに分類するか、署名者フラグフィールドが 0 でないという事実による DNS セキュリティ鍵であることを決定 できる実装系は、プロトコルフィールドを検査するために必須で はありません (NOT REQUIRED)。 4 は Oakley/IPSEC [RFC 2401] プロトコルを参照するのに予約さ れ、この鍵がセキュリティ標準と共に利用するのに有効であるこ とを示しています。エンティティもしくはユーザフラグビットが 立っている場合、名前が 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 です。アルゴリズム 2 は Diffie-Hellman key を示し、アルゴリズ ム 4 は 楕円曲線暗号のために予約されています。 アルゴリズム番号 252 は間接キー (実際の鍵材料が他の場所にある) を 示します。このフォーマットは別ドキュメントで定義されています。 アルゴリズム番号 253 と 254 は、プライベート使用のために予約され ており、特定のアルゴリズムに割り当てられることはありません。253番 に関して、公開鍵エリアおよび署名は wire エンコード化されたドメイ ンネームから始まります。ローカルドメインネームの圧縮だけが許され ます。ドメインネームは使用するプライベートアルゴリズムを表し、公 開鍵エリアの残りはそのアルゴリズムにより必要とされるものすべてで す。254番に関しては、KEY RR のための公開鍵エリアおよび署名は BER エンコードされたオブジェクトID (ISO OID) に符号なしバイト長で続き ます。OID は使用中のプライベートアルゴリズムを示し、エリアの残り はそのアルゴリズムにより必要とされるものすべてです。エンティティ は、プライベートアルゴリズムの指定を制御するドメインネームや OID を単に使用するにとどめておくべきです。 0 と 255 は予約されていますが、0 はアルゴリズムフィールドにてその フィールドが利用されていないときに使われます。例として、鍵が存在 しないところでは、 KEY RR のトップの 2つのフラグビットは on ( "no-key" 値) です。 3.3 フラグ、アルゴリズム、プロトコルバイトの相互作用 鍵なしタイプフラグ、アルゴリズムバイト、プロトコルバイトや将来割 り当てプロトコルを示すフラグの様々な組み合わせが可能です。 NK = 鍵なしタイプ (0 と 1 フラグビットが on) AL = アルゴリズムタイプ PR = プロトコルバイトや将来割り当てフラグに示されているプロトコル x 非ゼロ値が有効であることを表す 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 ゾーンのセキュア/非セキュア状態の決定 「鍵なし」タイプフィールド値 (両方の鍵タイプフラグビット 0, 1 が on) であるゾーン KEY RR は、たとえ鍵を持つゾーン KEY RR がセキュ アゾーンだと主張しても、それは非セキュアゾーンを示します。ゾーン 状態のセキュア、非セキュアは異なる暗号アルゴリズムによって変わり ます。同じアルゴリズムであっても、矛盾するゾーン KEY RR が現れる かもしれません。 全ての RR のように、それらが信頼する公開暗号鍵をリゾルバが持って おり署名者フィールドが署名者である SIG RR によって証明される場合 や、リゾルバのポリシーが鍵所有者名に対し署名者が署名することを許 可しているところにおいてのみゾーン KEY RR は信頼されます。非セキュ アゾーン KEY RR はゾーンのセキュリティ状態決定において無視されな ければなりません (MUST)。しかし、異なるアルゴリズムや署名者などを 持つゾーンにおける信頼されたゾーン KEY RR の多数のセットがあり得 ます。 いくつかの特定アルゴリズムにおいて、ゾーンは (1) セキュア (受け取った RR は SIG RR により証明されているはずで ある、または偽物として廃棄されることを示す) (2) 非セキュア (SIG RR は期待されていないか、ゾーンから受け取った RR のために要求されていることを示す) (3) 試行的セキュア (SIG RR は現れるかもしくは現れないが、見つかれ ば必ずチェックされる) であるでしょう。ゾーンの状態は以下のように決定されます -- 1. もし、ゾーンやアルゴリズムにおいて、各々の信頼されたゾーンへの ゾーン KEY RR がゾーンへの鍵がないと言った場合には、そのアルゴ リズムに対してはセキュアではない。 2. もし、少なくとも 1つの信頼された「鍵無し」ゾーン KEY RR と一つ の信頼されたゾーン KEY RR を明示している鍵があれば、そのゾーン はそのアルゴリズムに対して試行的にセキュアである。証明済や未証 明の両方のそれ用の RR はリゾルバによって受け付けられるべきであ る。 3. もしゾーンやアルゴリズムが持つ各々の信頼されたゾーン KEY RR が 鍵指定である場合、そのアルゴリズムに対してはセキュアであり、そ れから証明された RR のみが受け付けられるでしょう。 例: (1) リゾルバは最初に、DNS 階層内のゾーン Z のスーパーゾーンによる 署名だけを信頼します。したがって、リゾルバはスーパーゾーンに よって署名される KEY RR のみを見るでしょう。もしリゾルバが 「鍵なし」 KEY RR だけを見つけた場合、ゾーンがセキュアでない と見なします。もし「鍵指定」KEY RR だけを見つけた場合には、そ のゾーンがセキュアと見なし署名されていない応答を拒否します。 両方みつけた場合は、ゾーンが試行的なセキュアであると見なしま す。 (2) リゾルバがゾーン Z (リゾルバがそのローカルゾーンから安全に受 け取った) のスーパーゾーンや第三者、cert-auth.example を信頼 します。ゾーン Z からのデータを考慮する場合、それは Z のスー パーゾーンによって、cert-auth.example によって、また他のもの によって署名されるかもしれません。以下の表はゾーン Z の署名さ れたゾーン KEY RR によって、セキュアとみなせるか、試行的セキュ アであるとみなせるか、非セキュアであるとみなせるかを示すもの です。 c e r t - a u t h . e x a m p l e KEY RRs| な し | 鍵なし | 混合 | 鍵あり | --+-----------+-----------+----------+----------+ ス なし | 不適合 | 非セキュア| 試行的 | セキュア | ｜ --+-----------+-----------+----------+----------+ パ 鍵なし | 非セキュア| 非セキュア| 試行的 | セキュア | ｜ --+-----------+-----------+----------+----------+ ゾ 混合 | 試行的 | 試行的 | 試行的 | セキュア | ｜ --+-----------+-----------+----------+----------+ ン 鍵あり | セキュア | セキュア | セキュア | セキュア | +-----------+-----------+----------+----------+ 3.5 応答の構造内における KEY RR KEY RR への明白なリクエストは、(もちろん) "security aware" なサー バからの対応する SIG RR (セクション 4.2 を参照) 以外には特別な付 加情報の処理は起こりません。 "security aware" な DNS サーバは 以下のケースにおいて、鍵が有効で あるところにおいて KEY RR を 付加情報として応答の中に含めます。 (1) SOA や NS RR の検索上で、同じ名前 (恐らく単なるゾーン・キー) を備えた KEY RRset はスペースが利用可能な場合、付加情報として 含まれるべきです (SHOULD)。もし全ての付加情報が収まらなければ、 A や AAAA グルーレコード RR は KEY RR よりも優先されます。 (2) A や AAAA RR の検索上で、同じ名前 (普段は単なるホスト RR であ り、通常異なる名前を持つゾーン・キーではない) を備えた KEY RRset はスペースが利用可能な場合、含まれるべきです (SHOULD)。 付加情報として A または AAAA RR を含む場合には、同じ名前を持 つ KEY RRset もまた A や AAAA RR より低いプライオリティである が含まれるべきです。 4. SIG リソースレコード SIG または 「署名」リソースレコード (RR) は、セキュアドメインネー ムシステム (DNS) にてデータが証明されることの基本にあたる方法です。 つまり、セキュリティ提供の心臓部です。 SIG RR は、容赦なく特定のタイプ、クラスおよび名前の RRset [RFC 2181] を証明し、時間間隔や署名者のドメインネームにそれを結び付け ます。これは、暗号技術や署名者の秘密鍵を使うことで行われます。署 名者はたびたび、RR が発生したゾーンの所有者です。 SIG RR タイプ番号は 24 です。 4.1 SIG RDATA フォーマット SIG RR の RDATA 部分は以下に示すとおりです。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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type covered | algorithm | labels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | original TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signature expiration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signature inception | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key tag | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name + | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ / / / signature / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.1 「保護タイプ」フィールド 「保護タイプ」 は、この SIG により保護されている他の RR のタイプ です。 4.1.2 アルゴリズム番号フィールド このオクテットは、セクション 3.2 にて記述されています。 4.1.3 ラベルフィールド 「ラベル」オクテットは、ルートのための無効ラベルや、ワイルドカー ド用の "*" を勘定しない、オリジナルの SIG RR 所有者名にどれだけの ラベルがあるかの符号なしの数です。もし、セキュアな検索がワイルド カードによる置き換えの結果であれば、リゾルバにとって、デジタル署 名の検証においてその名前の元のフォームを使用する必要があります。 このフィールドは元のフォームを決定するのを簡単にします。 もし検索において、RR が 「ラベル」により示されるものよりも長い名 前を持っているよう現れる場合、リゾルバはそれがワイルドカードによ る置き換えの結果であることがわかります。もし RR 所有者名が ラベル カウントより短ければ、SIG RR は改ざんとみなされ無視されます。現在 の DNS が許容するラベルの最大数は 127 ですが、全体のオクテットは 予約されており、要求されれば DNS ネーム は常に 255 ラベルまで拡張 されるべきでしょう。以下の表はいくつかの例を挙げてます。「ラベル」 の値は最上段に、検索された所有者名は左に、表の中身は RR が 改ざん されたこと意味する "bad" を除いて、署名検証に使われる名前です。 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 オリジナル TTL フィールド 「オリジナル TTL」フィールドは、 (1) 実際の TTL フィールドを減じることによってキャッシュサーバが引 き起こす証明の問題 (2) 実際の TTL フィールドを操作することによって良心的でないサーバ が引き起こすセキュリティ問題 を避けるために RDATA 部に含まれています。このオリジナル TTL は現 在の TTL フィールドがそうでない間、署名により保護されています。 注: 署名の検証時に、「オリジナル TTL」フィールドは保護された RR へと戻されなければなりません (セクション 8 を参照)。これは一般的 に、特定のタイプ、名前およびクラス (任意の RRset のすべてのRR) 用 の RRがすべて同じ開始 TTL を持っていることを意味しています。 4.1.5 署名満了、開始フィールド SIG は 「署名開始」時間から「署名満了」時間まで有効です。両方とも、 グリニッジ時間の 1970 年 1 月 1 日からの符号なしの秒数 (閏秒は無 視)です (セクション 4.4 も参照のこと) 。繰り返しの計算の仕方は DNS SOA シリアル番号 [RFC 1982] (これは過去や将来に渡り、約 68 年 以上であり得ないことを意味します) のものが使われます。このことは、 モジュロ演算の結果である 136.09 年が多義にとれることを意味します。 しかしながら、鍵は少なくとも 5年ごとに新しいランダム・キーに変更 されるよう要求される [RFC 2541] ので、セキュリティの欠陥はありま せん。このことは、 N*136.09 年後に同じ鍵が使われている確率が、任 意の予想があたる確率に等しいであろうことを意味します。 SIG RR は、時間が 32 ビット境界に近いところにあり、また、署名が長 期間にわたって持続している場合には、開始時間より数量的に小さい満 了時間を持ってもいいことになっています。 (ゾーンの動的更新のためのネットワーク・リクエストのミスオーダーを 避けるために、署名開始時間の単調増加は必要かもしれません) セキュアゾーンは、そのデータが更新されるときだけでなく新しい SIG RR が挿入されるとき (ゾーンあるいは他の部分も再署名されます)、SOA シリアル番号目的のための変更を考慮されなければなりません。 4.1.6 キー・タグフィールド 「キー・タグ」は 2 バイト量であり、適用可能であろう複数の鍵と、署 名が利用可能かチェックする計算上高価な仕事のために使用されようと している公開鍵のチェックとの間の効果的な選択肢として利用されます。 [RFC 2537] で記述されているアルゴリズム 1 (MD5/RSA) については、 署名を複合するのに必要な公開鍵係数の底の隣から 2 バイトになります。 すなわち、ネットワークオーダー (ビッグエンディアン) においては、 係数の最下位 24 ビットの上位 16 ビットです。他の全てのプライベー トアルゴリズムを含んだアルゴリズムについては、付録 C で記述されて いる 単純な KEY RR のチェックサムとして計算されます。 4.1.7 署名者ネーム フィールド 「署名者ネーム」フィールドは、SIG RR を生成した署名者のドメインネー ムです。これはパブリックな KEY RR の所有者名であり、署名を検証す るのに使われます。それは、しばしば証明された RRset を含んだゾーン です。どの署名者も署名のために証明されるはずであり、これは重大な リゾルバポリシー問題としてセクション 6 で議論されています。ネット ワークを通して転送される時は、署名者の名前は標準 DNS ネーム圧縮で 圧縮されます。 4.1.8 署名フィールド SIG RR の実際の署名部分は、その所有者名およびクラスで「保護タイプ」 RR の RRset に他の RDATA フィールドを結びつけます。 data = RDATA | RR(s)... "|" は連結を表す RDATA は SIG RR 自身 (署名者の名前の正規形を含む) 中の全て、しか し署名を除いた RDATA フィールドの wire フォーマットです。 RR(s)とは、セクション 8 の中で定義されている正規形および順に、SIG RR として同じ所有者名およびクラスで保護されていたタイプの RR(s) の RRset です。 どのようにデータ・シーケンスが署名へと処理されるかはアルゴリズム 依存です。これらのアルゴリズム依存のフォーマットや手順は別のドキュ メントに記述されています (セクション 3.2 )。 SIG は ANY, AXFR などといった任意の「メタタイプ」のゾーンに含まれ るべきではありません (SHOULD NOT) (しかし、IXFR 関連についてはセ クション 5.6.2 を参照)。 4.1.8.1 トランザクションおよびリクエスト SIG の計算 "security aware" なサーバからの応答メッセージは、トランザクション を証明するために付加情報部の末尾に特別な SIG をオプション的に含め ても構いません。 この SIG は 「タイプ保護」フィールドが 0 (有効な RR タイプではな い) です。リプライ RR 数がトランザクション SIG の挿入により調整さ れる前に、この応答をもたらした DNS 問い合わせメッセージ (問い合わ せの DNS ヘッダとリクエスト SIG を含むが IP ヘッダを含まない) 全 体が結合された DNS 問い合わせメッセージ (DNS ヘッダを含むが、IP ヘッダは含まない) 全体の "data" (セクション 4.1.8 を参照) を用い て計算されます。 data = フルレスポンス (トランザクション SIG を除く) | フルクエリ リクエストを行うリゾルバによるトランザクション SIG (ゾーン・キー でなく、サーバのホスト・キーで署名されている) の検証は、通信中に 問い合わせや応答が干渉されていないこと、応答が意図した問い合わせ に対応すること、また、応答が尋ねられたサーバーから来ていることを 示します。 DNS リクエストはオプション的に、問い合わせの末尾に一つ、もしくは 複数の SIG を含めて署名されても構いません。そのような SIG は、 「タイプ保護」フィールドに 0 を持つことで見分けられます。それらは、 リクエスト SIG の挿入によりリクエスト RR 数が調整される前に、先の DNS リクエストメッセージ (DNS ヘッダを含むが、IP ヘッダは含まれな い) または末尾のリクエスト SIG を署名します。 注意: リクエスト SIG は 更新 [RFC 2136, 2137] 以外で現在定義され ているリクエストには必要なく、いくつかの古い DNS サーバへはエラー リターンや問い合わせの無視といったことを引き起こします。しかし、 そのような SIG も将来他のリクエストのために必要になるでしょう。 更新証明や同様の優先されたリクエストが必要とされる場所を除いては、 サーバがリクエスト SIG をチェックすることは要求されていません。 4.2 応答の構造内における SIG RR 証明された RRset 毎に問い合わせを返す "security aware" な DNS サー バ は、リクエストされた RRset を証明する有効な SIG RR を送信しよ うと試みるべきです (SHOULD)。以下のルールが応答における SIG RR の 挿入に対し適用されます - 1. RRset が応答中にあるとき、その SIG RR は、含める必要があるか もしれない付加 RR よりも挿入に対し高いプライオリティを持ちま す。もしスペース的に挿入が許可されない場合は、下の 2 を除い て応答が切り詰められることを考慮しなければなりません (MUST)。 2. SIG RR が付加情報部 RR のためにゾーンに現れたとき、応答を単 に切り詰めることを考えてはいけません (MUST NOT)。なぜなら、 スペース的に付加情報を伴った SIG RR の挿入は許可されないから です。 3. 委譲ポイントにおけるサブゾーンのためのグルーレコード や NS RR を証明する SIG は必要なく、送信されてもいけません (MUST NOT)。 4. もし SIG が応答の回答部にある任意の RR を保護する場合、その 自動挿入は回答部内でなければなりません (MUST)。もしそれが権 威部に現れる RR を保護するのであれば、その自動挿入は権威部内 でなければなりません (MUST)。もし付加情報部内に現れる RR を 保護するのであれば、それは付加情報部内に現れなければなりませ ん (MUST)。これは、権威部に NS と SOA RR のみを期待する現在 の標準 [RFC 1034, 1035] への変更です。 5. オプション的に、DNS トランザクションは応答の末尾における付加 情報部内の SIG RR によって証明されても構いません (セクション 4.1.8.1)。そのような SIG RR は応答の出もとである DNS サーバ によって署名されます。署名者フィールドは出もとであるサーバホ ストの名前でなければなりません (MUST) が、所有者名、クラス、 TTL や オリジナル TTL は無意味になります。クラス、 TTL フィー ルドは 0 であるべきです (SHOULD)。スペースの節約のため、所有 者名は root ( 0 で埋められた 1 オクテット) であるべきです (SHOULD)。もしトランザクション証明が望まれる場合、その SIG RR は挿入に対して高いプライオリティを考慮されなければなりま せん。 4.3 応答、SIG RR の処理 以下のルールが応答中に含まれた SIG RR の処理に適用されます - 1. "security aware" なサーバからセキュアなやりとりを経由して AD ビット (セクション 6.1 を参照) がセットされた応答を受け取る "security aware" なリゾルバは、ゾーン SIG RR 検証なしに受け 取った RR を受理するか選択しても構いません (MAY)。 2. その他の場合においては、"security aware" なリゾルバは関心の ある RR の SIG RR を検証するべきです (SHOULD)。特にセキュリ ティを実装していないサーバからの応答を受け取る場合には、SIG や KEY RR のための追加問い合わせの発生を伴っても構いません。 (上の 2.3.5 で説明したように、セキュアでないリゾルバにより提 示される CNAME を保証することはできません。) 注: 実装者には上記の SHOULD(〜すべき) を MUST(〜ねばならない) とすることが望まれます。しかし、ローカルポリシーやアプリケー ションの呼び出しはセキュリティサービスを要求しません。 3. もし SIG RR が、SIG タイプを明示したユーザの問い合わせへの応 答において受け取られた場合には特別な処理は要求されません。 もしメッセージが完全性のチェックをパスしなかったり、SIG が 署名済 RR に対してチェックを行わない場合、SIG RR は無効であるか無視され るべきです。もし RRset を証明したと主張する SIG RR の全てが無効で あれば、RRset は証明されません。 もし SIG RR が応答中の付加情報部の末尾の RR であり、保護タイプが 0 である場合、それは応答、または応答の元になった問い合わせのトラ ンザクション署名です。それはオプション的にチェックされてもよく (MAY)、チェックが失敗した場合メッセージは廃棄されます。しかし、 チェックが成功したとしても、そのようなトランザクション証明 SIG は メッセージ中の任意の RR を直接証明することはありません (NOT)。リ ゾルバポリシー (セクション 6 を参照) に関連して、ゾーンにより署名 された適切な SIG RR 、あるいはゾーンまで権威をたどる鍵、あるいは 静的なリゾルバの設定によってのみ直接 RR を証明することが可能です。 もしリゾルバがトランザクション、リクエスト SIG を実装してない場合 は、それらをエラー無しに無視しなければなりません (MUST)。 もし全てのチェックが SIG RR が有効であると示す場合、それにより検 証された RR は証明されることを考慮するべきです。 4.4 署名の生存時間、満了、TTL、有効性 "security aware" サーバは SIG RR に対し、その署名開始以前もしくは 署名満了以後に何かを署名させようと考えてはいけません (MUST NOT) (セクション 6 も参照のこと)。"security aware" なサーバは任意の RR に対し、その全ての署名が満了になった後に証明されると考えてはいけ ません (MUST NOT)。セキュアなサーバが証明されたデータをキャッシュ している時に TTL が証明満了時間より以前に満了になっても、サーバは キャッシュエントリ上の TTL を証明満了時間まで拡張しないように調節 すべきです (SHOULD)。これらの制約内にて、サーバは DNS TTL の老化 に従い続けるべきです。したがって、権威サーバはゾーンのリフレッシュ や満了パラメータに従い続けるべきであり、非権威サーバは TTL を秒読 みするべきで、 TTL が (SIG がまだその証明満了時間に到達していなく とも) 0 になったときには RR を廃棄すべきです。付け加えると、RR が 問い合わせ応答中を転送されるとき、TTL は 現在の時間との和が証明満 了時間を越えないように調節されるべきです。このように、一般的には 転送される RR 上の TTL はこうなります。 min(authExpTim,max(zoneMinTTL,min(originalTTL,currentTTL))) 署名が生成される時、署名満了時間は古いものが満了する前に新しい署 名が生成されることが明確であるよう十分先にセットすべきです。しか し、あまりにも先に長すぎる満了時間を設定することは、不適格なデー タや生成された署名を消し去るのに長い時間がかかることを意味します。 署名生存時間は、合理的な最大再署名期間より小さくなく、ゾーンの満 了時間よりも小さくない、 TTL の小さな倍数 (ie, TTL の 4 〜 16 倍) であることが推奨されます。 5. 存在しない名前とタイプ 上のセクション 4 で述べられた SIG RR の機構は、ゾーンに存在する RR の強い証明を提供します。しかし、上述のゾーン中の名前もしくは、 存在する名前へのタイプの検証を通して拒否する方法を明確にしません。 ゾーンに存在しない名前は、存在しない名前を含む "name interval" の ための NXT ("next") RR によって示されます。NXT RR や RR やそれら の SIG は、もしサーバが "security aware" であれば、エラーを伴って 権威部に返されます。NXT を伴う空の回答部以外にエラー表示がないこ とを除けば、存在する名前下の非存在タイプについても同じことが言え ます。これは、権威部に NS と SOA RR のみを期待している現在の標準 [RFC 1034/1035] への変更です。 NXT RR は、NXT タイプを明示的に促 す問い合わせにも返されます。 ゾーン中の NXT レコードの完全なセットの存在は、もし問い合わせが委 譲ポイント NS や グルー A もしくは AAAA RR でなければ、ゾーンを提 供している "security aware" なサーバへの名前やタイプへの問い合わ せが、少なくとも一つの署名された RR を含むリプライに帰着すること を意味します。 5.1 NXT リソースレコード NXT リソースレコードは、一定の name interval 中の所有者名を持つ RR がゾーンに存在しないことをセキュア的に示したり、どの RR タイプ が既存の名前のために存在するかを示すのに使われます。 NXT RR の所有者名は、ゾーンに存在する名前です。その RDATA は、 「次」の名前とタイプビットマップです。このように、ゾーンの NXT RR は、そのゾーン (展開されていないワイルドカードを含むが、他の方法 で挿入されてなければグルーアドレスレコードの所有者名を省略してい る) の文字上の所有者名の全ての連鎖を作りだします。これは、セクショ ン 8 で述べられている、ゾーンの全てのドメインネームの正規化された 順番を暗示しています。NXT RR の存在は、その所有者名とその RDATA エリア中の名前の間に名前が存在せず、他のタイプがその所有者名の下 に存在しないことを意味します。 ゾーンの最後の NXT に伴う潜在的な問題として、正規順の最後の既存名 である所有者名を持ちたいが (これは簡単なことだが)、全体の名前空間 の残りを示すために RDATA にどの名前を入れればいいか明白でない、と いうことがあります。これについては、名前空間を循環的なものとみな し、ゾーン・ネームを最後の NXT の RDATA に入れることで解決されて います。 ゾーンの NXT RR は、自動的に計算され、SIG が追加される時は自動的 ゾーンに追加されるべきです (SHOULD)。NXT RR の TTL は、ゾーンの最 小 TTL を越えないべきです (SHOULD)。 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 ビットです。一つのビットは、その所有 者名に対し少なくとも一つのそのタイプの RR が存在することを示して います。 0 はそのような RR がないことを示します。ビットマップの境 界を越えているので指定されない全てのビットは 0 と見なされます。 NXT のビット 30 は、最小のビットマップ長が実際は 4 オクテットであ るため、常に on であることを注意してください。このフォーマットに おいて 0 オクテットをひきずるのは禁止されています。最初のビットは RR タイプ 0 (存在できない不適格なタイプ) を表し、したがってこの フォーマットにおいては 0 になります。このフォーマットは、127 より 大きいタイプ番号を持つ RR が存在する場合には使われません。もし、 タイプビットマップの 0 ビット目が 1 であれば、タイプ番号が 127 よ り大きいものが現れれば、常にそのケースとねる異なるフォーマットが 使われていることを示します。 ドメインネームはネットワーク上を転送されているときは、標準 DNS ネー ム圧縮により圧縮されています。ビットマップのサイズは、RDLENGTH か 次のドメインネームの長さにより推測され得ます。 5.3 ワイルドカードによる複雑さの増加 存在しない名前の応答が正しい、もしくはワイルドカードの展開の応答 が正しいことの証明は、物事を少し複雑にさせます。 とくに、存在しない名前の応答が返って来たとき、NXT は問い合わされ た正確な名前が存在しなかったことを示しつつ返されるはずであり、一 般的に、NXT が必要とする一つもしくは複数の付加情報が、展開が返っ てくるべきであるワイルドカードがないことを証明するためにも返され ます。(同じ NXT の複数のコピーが返される必要はありません。) これ らの NXT は、もしあれば、応答の権威部に返されます。 さらに、もしワイルドカードの展開が応答中に返された場合、一般的に 一つもしくは複数の NXT が、(ゾーンにおける可能なかぎりの特定のワ イルドカードを含む) 応答に基づいて特定の名前がもはや存在しないこ とを証明するために権威部に返される必要があります。 5.4 例 ゾーン foo.nil が big.foo.nil, medium.foo.nil. small.foo.nil. tiny.foo.nil. といったエントリを持っていると仮定します。 それから、"security aware" サーバへの huge.foo.nil に対する問い合 わせが RCODE of DOMAIN を伴うエラーリプライや以下のような何かを含 んでいる権威部データが返されたとします。 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 タイプに関連していることをこの応答が示唆していることに注意 してください。しかし、NXT (とその SIG) RR のみが、この huge.foo.nil (存在しない名前) への問い合わせの応答中に現れます。 5.5 委譲ポイントにおける特別な考慮点 ゾーンの頭の名前 (root 以外) はスーパーゾーンの葉ノードとしても現 れます。両方ともセキュアであれば、常に同じ名前を持った二つの異な る NXT RR があるでしょう。それらは、それらの署名者や、次のドメイ ンネームフィールドや、SOA タイプビットの存在などにより簡単に識別 できます。もし利用可能であれば、明示的な NXT タイプへの問い合わせ において、"security aware" サーバは名前の非存在と両方の NXT の証 明を要求されたときには自動的に正しい NXT を返すべきです。 "Non-security aware" なサーバは NXT を自動的に返すことは決してな いですし、いくつかの古い実装は明示的な問い合わせにおいてはサブゾー ンから NXT のみを返すかもしれません。 5.6 ゾーン転送 下のサブセクションは、如何に完全およびは増分ゾーン転送が保証され るかを述べています。 SIG RR は、完全、増分 [RFC 1995] ゾーン転送の両方により転送される 全ての権威 RR を保証します。NXT RR はセキュアゾーン転送になくては ならない要素であり、各権威ネームやタイプが存在するであろうと仮定 しています - しかし、もし同じ名前やタイプ保護を伴った複数の SIG がある場合、一つでも存在さえすれば SIG のサブセットが送られ、署名 されていない委譲ポイント NS や グルー A もしくは AAAA RR の場合は、 これらのサブセットか、あるいは少なくともどれか一つのタイプが含ま れていれば単に修正済のセット送られます。 サーバのゾーンコピーよりも新しいバージョン番号か同じものを伴った 増分もしくは完全ゾーン転送リクエストを受け取ったときは、そのサー バの現在のバージョンの SOA RR と その SOA RR を検証している SIG RRset のみを伴ってリプライされます。 このドキュメントで記述されている完全な NXT 連鎖は、NXT によって繋 がれる連続的な問い合わせにより、ゾーン転送が禁止されていようとも リゾルバにゾーン中の全ての名前を得させることを可能にします。異な る NXT フォーマットが将来、これを避けるために明記されるかもしれま せん。 5.6.1 完全ゾーン転送 完全な転送が生じることにおいてサーバ証明を提供するために、トラン ザクション証明は完全ゾーン転送において使用されるべきです (SHOULD)。 これは転送中のゾーン全体の保護に基づいた強いサーバをもたらします。 5.6.2 増分ゾーン転送 増分転送 (IXFR) [RFC 1995] 中の個々の RR は完全ゾーン転送と同じ方 法をもって検証され、増分 RR が削除もしくは追加した後に、NXT ネー ムの連鎖の完全性やゾーンに対する NXT タイプビットの正当性が更新さ れたゾーンの各々のばらばらなエリアをチェックすることができます。 しかし、通常削除された RR 部も追加された RR 部も完全なゾーン NXT 連鎖を持たないので、増分転送の完全性を確認できません。結果として、 IXFR の安全性をサポートするサーバは、それが維持をする各増分転送セッ トのための IXFR SIG RR を扱わなければなりません。 IXFR SIG は、転送順に - 古い SOA の次に RR が削除され、それから新 しい SOA と RR が追加される - RR の 増分ゾーン更新のコレクション によって計算されます。各セクション内において、 RR は セクション 8 で記述されるよう規則正しくなければなりません。もし、隣接した増分 更新セットの凝縮がゾーン所有者によって行われた場合、その凝縮に含 まれる各セットのオリジナル IXFR SIG は廃棄され、結果を保護するた めに計算された 新しい IXFR SIG がセットを凝縮します。 全体として、IXFR SIG は実際にはゾーン・ネームではなく、ゾーンに属 しています。しかしながら、ゾーン・ネームには正しくあるべき (SHOULD) ですが、そうでなければ IXFR SIG のラベルフィールドは無意 味です。IXFR SIG は単に増分ゾーン転送の一部として送られます。IXFR SIG の確認後、転送された RR は、サーバにおいてそのような信頼性が ローカルポリシーと一致する場合は内部 SIG の検証なしに有効とみなし ても構いません (MAY)。 6. 安全な解決方法と AD, CD ビット ドメインネームシステム (DNS) からのセキュアなデータの検索や解決は、 リゾルバにおいて静的に設定された一つ以上の信頼された公開鍵による 開始を引き起こします。開始する信頼された鍵をもって、進んで暗号化 を実行するリゾルバは、セクション 6.3 で述べられるような関心をもつ ゾーンへのセキュアな DNS 構造を安全に突き進んでいくことができます。 そのような信頼された公開鍵は通常、セクション 6.2 で述べられる方法 に近いやり方で設定されます。しかし実際問題として、"security aware" なリゾルバは、もしそれが鍵で設定されていないが静的に設定さ れたかのようにローカルの well-known なサーバから得たものを信頼す る場合においてでさえも、返される結果の秘匿性にはまだ有利です。 "security aware" なサーバに格納されるデータは、内部で 「Authenticated (証明済)」、「Pending (保留)」、「Insecure (非セ キュア)」に分類される必要があります。また、データに対して全ての SIG チェックがはっきりと失敗したことを示す、4 つ目の一時的な「Bad (悪い)」状態が存在します。そのような "Bad" データは "security aware" なサーバでは保持されません。証明された、ということは、静的 にリゾルバにて設定されたキーへのポリシーにより認可された 0個 また はたくさんの SIG や KEY RR の連鎖を通して追跡可能であるキーのもと でデータが有効であることを示します。保留中のデータは、証明された SIG は持っておらず、リゾルバが今だ証明しようとしている付加 SIG は 少なくとも一つ持っています。安全でないデータとは、証明されていな い、もしくはそれが見つかったゾーンにて "Bad" データであることが 決して指摘されないとわかっているデータのことです。なぜなら、それ は安全でないゾーンにあったか、そこからやってきたからであり、もし くは、署名されていない glue アドレスか委譲ポイント NS データであ るからです。そのようなデータラベルの操作や、それに基づいたフラグ の操作に関する振る舞いは、セクション 6.1 で述べられています。 署名の適切な確認は、セクション 6.4 で述べられているようなリゾルバ とサーバ間の絶対時間の評価を共有した合理的な安全性を必要とします。 6.1 AD, CD ヘッダビット 2つの前もって未使用としていたビットが、DNS 問い合わせ/応答フォー マットヘッダの外に割り当てられています。応答における AD (確実なデー タ) ビットは、回答にふくまれるデータと応答の権威部のすべてがその サーバのポリシーにより証明されたことを示しています。問い合わせに おける CD (チェック無効) ビットは、その問い合わせを送ったリゾルバ に対して "Pending" (未証明) データが受容されることを示します。 これらのビットは以下のように、前もって 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 です。したがって、 "security aware" なリゾルバへの古いサーバの応答は証明されたという フラギングがされず、"non-security aware" なリゾルバからの問い合わ せはチェック無効ビットを主張しません。それは "Authenticated" もし くは "Insecure" データのみを持つ "security aware" なサーバにより 答えられるでしょう。 "security aware" なリゾルバは、もしそれが話 しかけているサーバを信頼していないか、セキュアパスを持っているか DNS トランザクションセキュリティを利用しているのでもなければ、AD ビットを信頼してはなりません (MUST NOT)。 暗号化を進んで行うあらゆる "security aware" なリゾルバは、すべて の問い合わせにてそれ自身のポリシーをそれに強いることを許可させる ため、また "security aware" なサーバに "Pending" データを回答する ことを許すことにより DNS 潜伏時間を減らすため、CD ビットを主張す るべき (SHOULD) です。 "security aware" なサーバは "Bad" データを返してはいけません (MUST NOT)。CD ビットクリア状態にてサービスをリクエストする "non-security aware" なリゾルバもしくは "security aware" なリゾルバにおいて、 "security aware" なサーバは、回答中にて "Authenticated" か "Insecure" データのみを、応答中にて AD ビットがセットされた権威部 を返さなければなりません (MUST)。 "security aware" なサーバは、 (応答の AD ビットをクリアして ) "Pending" データをリクエスト中の CD ビットを主張してこのサービスにリクエストしてきた "security aware" なサーバに返すべき (SHOULD) です。もしすべての回答中の RR や応答中の権威部が "Authenticated" か "Insecure" のどちらかでなけ れば、AD ビットは応答にてセットされてはなりません (MUST)。 6.2 静的設定キー ゾーンを証明する公開鍵は、ゾーンが証明されうるために、プライマリ サーバにて読み込まれる前にローカル設定ファイルにて定義されている べきです (SHOULD)。 root ゾーンに関連した公開鍵でスタートすることや、各リゾルバにてこ れを静的に設定しておくことは一見論理的に見えますが、これには問題 があります。世界中のすべての DNS リゾルバが常にキーを変更する更新 ロジスティックは極めてシビアです。さらに、多くの組織が彼らの所有 する DNS サーバだけを完全に信頼するための「内部」DNS 実装を明示的 に望むことでしょう。そのような組織の内部リゾルバは、組織ドメイン 外のデータへアクセスするために組織のゾーンサーバを通り抜けること ができ、組織の頂点の DNS にキーを設定する必要がありません。 比較的大きな組織の一部でないホストリゾルバは、彼らのローカル ISP (彼らがその ISP のリカーシブセキュア DNS キャッシュサーバを使って いる) ドメインのためにキーを設定するかもしれません。 6.3 DNS を通した連鎖 任意のゾーンに対し 1 つ以上の信頼されたキーで開始するにおいて、そ のゾーンのキーを持つサブゾーンに対し署名されたキーを受け取ること が可能です。セキュアなサブゾーンは、サブゾーン中の NS RR と共に現 われるヌルでないキー情報を持つ KEY RR (親にも現われるかもしれない) によって示されます。これらはゾーンツリー内を下っていくことを可能 にします。 6.3.1 KEY を通した連鎖 一般に、あなたがセキュア DNS において有効にしたい RRset は、1 つ 以上の SIG RR により署名されるでしょう。これらの SIG RR の各々は、 そのネームが SIG を証明するのに使われる格納された公開鍵であること を下にそれぞれ署名者を持ちます。それらの KEY の一つ一つもまた、一 般的に、SIG で署名されるでしょう。そして、それらの SIG は KEY へ も参照している署名者ネームを持つでしょう。... 結果として証明は、 信頼性が明らかな元データや証明を実装しているリゾルバにおいて静的 に設定されたいくつかの信頼されたキーとなる最後の KEY を署名する最 初の SIG を伴ったあらゆる SIG や KEY RR の連鎖をもたらします。 そのような連鎖のテストの際に、遭遇した SIG の有効期限がデータの証 明有効期限を決定するために遮られなければなりません (純粋なアルゴ リズム処理)。付け加えると、KEY への参照を伴ったデータを越える各 SIG の有効性検証は 6.4 安全な時間 SIG RR 中の時間フィールドの調整された解釈は、DNS セキュリティ拡張 が実装されたホストに対し合理的に矛盾しない時間が利用可能であるこ とを必要とします。 Network Time Protocol (NTP [RFC 1305, 2030]) を含む、様々な時刻同 期プロトコルが存在します。そのようなプロトコルが使用されている場 合、時間が改ざんされないよう安全的に利用されなければならなりませ ん (MUST)。 さもなければ、例えば、ホストが戻って来た時刻を得、かつては有効で あったが今ではそうではない古い SIG RR (やそれらにより証明されたデー タ) を信じることになります。 7. ASCII Representation of Security RRs This section discusses the format for master file and other ASCII presentation of the three DNS security resource records. The algorithm field in KEY and SIG RRs can be represented as either an unsigned integer or symbolicly. The following initial symbols are defined as indicated: Value Symbol 001 RSAMD5 002 DH 003 DSA 004 ECC 252 INDIRECT 253 PRIVATEDNS 254 PRIVATEOID 7.1 Presentation of KEY RRs KEY RRs may appear as single logical lines in a zone data master file [RFC 1033]. The flag field is represented as an unsigned integer or a sequence of mnemonics as follows separated by instances of the verticle bar ("|") character: BIT Mnemonic Explanation 0-1 key type NOCONF =1 confidentiality use prohibited NOAUTH =2 authentication use prohibited NOKEY =3 no key present 2 FLAG2 - reserved 3 EXTEND flags extension 4 FLAG4 - reserved 5 FLAG5 - reserved 6-7 name type USER =0 (default, may be omitted) ZONE =1 HOST =2 (host or other end entity) NTYP3 - reserved 8 FLAG8 - reserved 9 FLAG9 - reserved 10 FLAG10 - reserved 11 FLAG11 - reserved 12-15 signatory field, values 0 to 15 can be represented by SIG0, SIG1, ... SIG15 No flag mnemonic need be present if the bit or field it represents is zero. The protocol octet can be represented as either an unsigned integer or symbolicly. The following initial symbols are defined: 000 NONE 001 TLS 002 EMAIL 003 DNSSEC 004 IPSEC 255 ALL Note that if the type flags field has the NOKEY value, nothing appears after the algorithm octet. The remaining public key portion is represented in base 64 (see Appendix A) and may be divided up into any number of white space separated substrings, down to single base 64 digits, which are concatenated to obtain the full signature. These substrings can span lines using the standard parenthesis. Note that the public key may have internal sub-fields but these do not appear in the master file representation. For example, with algorithm 1 there is a public exponent size, then a public exponent, and then a modulus. With algorithm 254, there will be an OID size, an OID, and algorithm dependent information. But in both cases only a single logical base 64 string will appear in the master file. 7.2 Presentation of SIG RRs A data SIG RR may be represented as a single logical line in a zone data file [RFC 1033] but there are some special considerations as described below. (It does not make sense to include a transaction or request authenticating SIG RR in a file as they are a transient authentication that covers data including an ephemeral transaction number and so must be calculated in real time.) There is no particular problem with the signer, covered type, and times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY is the year, the first MM is the month number (01-12), DD is the day of the month (01-31), HH is the hour in 24 hours notation (00-23), the second MM is the minute (00-59), and SS is the second (00-59). The original TTL field appears as an unsigned integer. If the original TTL, which applies to the type signed, is the same as the TTL of the SIG RR itself, it may be omitted. The date field which follows it is larger than the maximum possible TTL so there is no ambiguity. The "labels" field appears as an unsigned integer. The key tag appears as an unsigned number. However, the signature itself can be very long. It is the last data field and is represented in base 64 (see Appendix A) and may be divided up into any number of white space separated substrings, down to single base 64 digits, which are concatenated to obtain the full signature. These substrings can be split between lines using the standard parenthesis. 7.3 Presentation of NXT RRs NXT RRs do not appear in original unsigned zone master files since they should be derived from the zone as it is being signed. If a signed file with NXTs added is printed or NXTs are printed by debugging code, they appear as the next domain name followed by the RR type present bits as an unsigned interger or sequence of RR mnemonics. 8. リソースレコードの正規形と正規順 このセクションは、ドメインネームシステム (DNS) のセキュリティ目的 のために、リソースレコードの正規形やそれらの名前の順番、全体にわ たる順番を明記します。正規名前順は NXT 名前連鎖の構築に必要です。 RRset 内の正規形や順番は、矛盾のない SIG RR の構築や検証に必要で す。名前におけるタイプの正規順は増分転送を伴う接続に要求されます (セクション 5.6.2)。 8.1 正規リソースレコード形 DNS セキュリティの目的として、RR としての正規形は ドメインネーム をともなった wire フォーマットであり、 (1) 完全に展開されている (ポインタ経由の名前圧縮はなし) (2) 全てのドメインネームは小文字にセット (3) マスタファイル形式中の所有者名ワイルドカード(* の代用品は作ら れていない) (4) オリジナル TTL が現在の TTL の代わりをしている 8.2 正規 DNS ネーム順 DNS セキュリティの目的として、所有者名の正規順は、ゼロ値のオクテッ トや大文字が小文字として扱われる前にオクテットの欠如がソートする ところにおいて、符号なしの左揃えオクテット文字列として個々のラベ ルをソートすることです。ゾーンの名前は、最も高いレベルのラベルを ソートすることによりソートされます。それから、同じレベルをもつ同 志で次のレベルのラベルといった感じで末端ノードラベルにわたってソー トされていきます。ゾーン内ではゾーンネーム自身は常に存在し、他の 全ての名前は低レベルラベルのプレフィックスを伴うゾーンネームにな ります。したがって、ゾーンネーム自身は常に一番目にソートされます。 例: 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 はゼロオクテットの前にオクテッ トの欠如がソートするところで、左揃えされた符号なしオクテットシー ケンスとしてソートされます。 8.4 Canonical Ordering of RR Types When RRs of the same name but different types must be ordered, they are ordered by type, considering the type to be an unsigned integer, except that SIG RRs are placed immediately after the type they cover. Thus, for example, an A record would be put before an MX record because A is type 1 and MX is type 15 but if both were signed, the order would be A < SIG(A) < MX < SIG(MX). 9. Conformance Levels of server and resolver conformance are defined below. 9.1 Server Conformance Two levels of server conformance for DNS security are defined as follows: BASIC: Basic server compliance is the ability to store and retrieve (including zone transfer) SIG, KEY, and NXT RRs. Any secondary or caching server for a secure zone MUST have at least basic compliance and even then some things, such as secure CNAMEs, will not work without full compliance. FULL: Full server compliance adds the following to basic compliance: (1) ability to read SIG, KEY, and NXT RRs in zone files and (2) ability, given a zone file and private key, to add appropriate SIG and NXT RRs, possibly via a separate application, (3) proper automatic inclusion of SIG, KEY, and NXT RRs in responses, (4) suppression of CNAME following on retrieval of the security type RRs, (5) recognize the CD query header bit and set the AD query header bit, as appropriate, and (6) proper handling of the two NXT RRs at delegation points. Primary servers for secure zones MUST be fully compliant and for complete secure operation, all secondary, caching, and other servers handling the zone SHOULD be fully compliant as well. 9.2 Resolver Conformance Two levels of resolver compliance (including the resolver portion of a server) are defined for DNS Security: BASIC: A basic compliance resolver can handle SIG, KEY, and NXT RRs when they are explicitly requested. FULL: A fully compliant resolver (1) understands KEY, SIG, and NXT RRs including verification of SIGs at least for the mandatory algorithm, (2) maintains appropriate information in its local caches and database to indicate which RRs have been authenticated and to what extent they have been authenticated, (3) performs additional queries as necessary to attempt to obtain KEY, SIG, or NXT RRs when needed, (4) normally sets the CD query header bit on its queries. 10. Security Considerations This document specifies extensions to the Domain Name System (DNS) protocol to provide data integrity and data origin authentication, public key distribution, and optional transaction and request security. It should be noted that, at most, these extensions guarantee the validity of resource records, including KEY resource records, retrieved from the DNS. They do not magically solve other security problems. For example, using secure DNS you can have high confidence in the IP address you retrieve for a host name; however, this does not stop someone for substituting an unauthorized host at that address or capturing packets sent to that address and falsely responding with packets apparently from that address. Any reasonably complete security system will require the protection of many additional facets of the Internet beyond DNS. The implementation of NXT RRs as described herein enables a resolver to determine all the names in a zone even if zone transfers are prohibited (section 5.6). This is an active area of work and may change. A number of precautions in DNS implementation have evolved over the years to harden the insecure DNS against spoofing. These precautions should not be abandoned but should be considered to provide additional protection in case of key compromise in secure DNS. 11. IANA Considerations KEY RR flag bits 2 and 8-11 and all flag extension field bits can be assigned by IETF consensus as defined in RFC 2434. The remaining values of the NAMTYP flag field and flag bits 4 and 5 (which could conceivably become an extension of the NAMTYP field) can only be assigned by an IETF Standards Action [RFC 2434]. Algorithm numbers 5 through 251 are available for assignment should sufficient reason arise. However, the designation of a new algorithm could have a major impact on interoperability and requires an IETF Standards Action [RFC 2434]. The existence of the private algorithm types 253 and 254 should satify most needs for private or proprietary algorithms. Additional values of the Protocol Octet (5-254) can be assigned by IETF Consensus [RFC 2434]. The meaning of the first bit of the NXT RR "type bit map" being a one can only be assigned by a standards action. References [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. [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. [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 Appendix A: Base 64 Encoding The following encoding technique is taken from [RFC 2045] by N. Borenstein and N. Freed. It is reproduced here in an edited form for convenience. A 65-character subset of US-ASCII is used, enabling 6 bits to be represented per printable character. (The extra 65th character, "=", is used to signify a special processing function.) The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right, a 24-bit input group is formed by concatenating 3 8-bit input groups. These 24 bits are then treated as 4 concatenated 6-bit groups, each of which is translated into a single digit in the base 64 alphabet. Each 6-bit group is used as an index into an array of 64 printable characters. The character referenced by the index is placed in the output string. Table 1: The Base 64 Alphabet Value Encoding Value Encoding Value Encoding Value Encoding 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 Special processing is performed if fewer than 24 bits are available at the end of the data being encoded. A full encoding quantum is always completed at the end of a quantity. When fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral number of 6-bit groups. Padding at the end of the data is performed using the '=' character. Since all base 64 input is an integral number of octets, only the following cases can arise: (1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding, (2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters, or (3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character. Appendix B: Changes from RFC 2065 This section summarizes the most important changes that have been made since RFC 2065. 1. Most of Section 7 of [RFC 2065] called "Operational Considerations", has been removed and may be made into a separate document [RFC 2541]. 2. The KEY RR has been changed by (2a) eliminating the "experimental" flag as unnecessary, (2b) reserving a flag bit for flags expansion, (2c) more compactly encoding a number of bit fields in such a way as to leave unchanged bits actually used by the limited code currently deployed, (2d) eliminating the IPSEC and email flag bits which are replaced by values of the protocol field and adding a protocol field value for DNS security itself, (2e) adding material to indicate that zone KEY RRs occur only at delegation points, and (2f) removing the description of the RSA/MD5 algorithm to a separate document [RFC 2537]. Section 3.4 describing the meaning of various combinations of "no-key" and key present KEY RRs has been added and the secure / unsecure status of a zone has been clarified as being per algorithm. 3. The SIG RR has been changed by (3a) renaming the "time signed" field to be the "signature inception" field, (3b) clarifying that signature expiration and inception use serial number ring arithmetic, (3c) changing the definition of the key footprint/tag for algorithms other than 1 and adding Appendix C to specify its calculation. In addition, the SIG covering type AXFR has been eliminated while one covering IXFR [RFC 1995] has been added (see section 5.6). 4. Algorithm 3, the DSA algorithm, is now designated as the mandatory to implement algorithm. Algorithm 1, the RSA/MD5 algorithm, is now a recommended option. Algorithm 2 and 4 are designated as the Diffie-Hellman key and elliptic cryptography algorithms respectively, all to be defined in separate documents. Algorithm code point 252 is designated to indicate "indirect" keys, to be defined in a separate document, where the actual key is elsewhere. Both the KEY and SIG RR definitions have been simplified by eliminating the "null" algorithm 253 as defined in [RFC 2065]. That algorithm had been included because at the time it was thought it might be useful in DNS dynamic update [RFC 2136]. It was in fact not so used and it is dropped to simplify DNS security. Howver, that algorithm number has been re-used to indicate private algorithms where a domain name specifies the algorithm. 5. The NXT RR has been changed so that (5a) the NXT RRs in a zone cover all names, including wildcards as literal names without expansion, except for glue address records whose names would not otherwise appear, (5b) all NXT bit map areas whose first octet has bit zero set have been reserved for future definition, (5c) the number of and circumstances under which an NXT must be returned in connection with wildcard names has been extended, and (5d) in connection with the bit map, references to the WKS RR have been removed and verticle bars ("|") have been added between the RR type mnemonics in the ASCII representation. 6. Information on the canonical form and ordering of RRs has been moved into a separate Section 8. 7. A subsection covering incremental and full zone transfer has been added in Section 5. 8. Concerning DNS chaining: Further specification and policy recommendations on secure resolution have been added, primarily in Section 6.3.1. It is now clearly stated that authenticated data has a validity period of the intersection of the validity periods of the SIG RRs in its authentication chain. The requirement to staticly configure a superzone's key signed by a zone in all of the zone's authoritative servers has been removed. The recommendation to continue DNS security checks in a secure island of DNS data that is separated from other parts of the DNS tree by insecure zones and does not contain a zone for which a key has been staticly configured was dropped. 9. It was clarified that the presence of the AD bit in a response does not apply to the additional information section or to glue address or delegation point NS RRs. The AD bit only indicates that the answer and authority sections of the response are authoritative. 10. It is now required that KEY RRs and NXT RRs be signed only with zone-level keys. 11. Add IANA Considerations section and references to RFC 2434. Appendix C: Key Tag Calculation The key tag field in the SIG RR is just a means of more efficiently selecting the correct KEY RR to use when there is more than one KEY RR candidate available, for example, in verifying a signature. It is possible for more than one candidate key to have the same tag, in which case each must be tried until one works or all fail. The following reference implementation of how to calculate the Key Tag, for all algorithms other than algorithm 1, is in ANSI C. It is coded for clarity, not efficiency. (See section 4.1.6 for how to determine the Key Tag of an algorithm 1 key.) /* assumes int is at least 16 bits first byte of the key tag is the most significant byte of return value second byte of the key tag is the least significant byte of return value */ 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; } Full Copyright Statement 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. -- translated by takato satsuma