DNS拡張(dnstxt)ワーキンググループ R. Arends インターネットドラフト Telematica Instituut 有効期限: 2004年6月16日 R. Austein ISC M. Larson VeriSign D. Massey USC/ISI S. Rose NIST 2003年12月17日 DNSセキュリティー拡張の紹介とその要件 draft-ietf-dnsext-dnssec-intro-08 本文書の位置づけ 本文書はインターネットドラフトであり、RFC2026のセクション10の 条項全てに準拠するものである。 インターネットドラフトとは、Internet Engineering Task Force (IETF)、 エリア、ワーキンググループの作業文書である。他のグループもまた 作業文書をインターネットドラフトとして配布することがあることに 注意してもらいたい。 インターネットドラフトは最大6ヶ月間有効な草稿文書であり、 いつでも他の文書によって更新、差し替え、または廃止されることがある。 インターネットドラフトを参考文献として使用すること、または "作業中(work in progress)"という状態であることを明示せずに 引用することは不適当である。 現時点におけるインターネットドラフトのリストは下記より入手することが できる。 http://www.ietf.org/ietf/1id-abstracts.txt. Internet-Draft Shadow Directoriesのリストは下記より入手することができる。 http://www.ietf.org/shadow.html. このインターネットドラフトの有効期限は、2004年6月16日である。 著作権表示 Copyright (C) The Internet Society (2003). All Rights Reserved. 要旨 DNS(Domain Name System)セキュリティー拡張(DNSSEC)は、DNSに対して データの起源の認証機能と、データの完全性保護機能を追加するものである。 本文書はこれらの拡張機能を紹介し、その機能と制限について記述する。 また、本文書はDNSセキュリティ拡張がサービスとして提供するもの、 しないものについても記述する。 Arends, et al. Expires June 16, 2004 [Page 1] Internet-Draft DNSSEC Introduction and Requirements December 2003 最後に、本文書はDNSSECについて記述する一連の文書群について、各文書の 相互関係を記述する。 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. 重要なDNSSEC用語の定義 . . . . . . . . . . . . . . . . . . . . 4 3. DNSセキュリティー拡張が提供するサービス. . . . . . . . . . . . 7 3.1 データの起源の認証とデータの完全性保護 . . . . . . . . . . . . 7 3.2 名前とタイプの不存在の認証 . . . . . . . . . . . . . . . . . . 7 4. DNSセキュリティー拡張が提供しないサービス. . . . . . . . . . . 10 5. リゾルバーに関する考察 . . . . . . . . . . . . . . . . . . . . 11 6. スタブリゾルバーに関する考察 . . . . . . . . . . . . . . . . . 12 7. ゾーンに関する考察 . . . . . . . . . . . . . . . . . . . . . . 13 7.1 TTL値とRRSIGの有効期間 . . . . . . . . . . . . . . . . . . . . 13 7.2 新たに発生するゾーンの時間依存問題 . . . . . . . . . . . . . . 13 8. ネームサーバーに関する考察 . . . . . . . . . . . . . . . . . . 14 9. DNSセキュリティー拡張の関連文書. . . . . . . . . . . . . . . . 15 9.1 DNSセキュリティー拡張に関連する文書のロードマップ. . . . . . . 15 9.2 DNSセキュリティー拡張に関連する文書の分類. . . . . . . . . . . 15 10. IANAに関する考察 . . . . . . . . . . . . . . . . . . . . . . . 17 11. セキュリティーに関する考察 . . . . . . . . . . . . . . . . . . 18 12. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 必須の参考文献 . . . . . . . . . . . . . . . . . . . . . . . . 21 有用な参考文献 . . . . . . . . . . . . . . . . . . . . . . . . 22 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . 23 知的所有権と著作権に関する表示 . . . . . . . . . . . . . . . . 25 Arends, et al. Expires June 16, 2004 [Page 2] Internet-Draft DNSSEC Introduction and Requirements December 2003 1. はじめに 本文書はDNS(Domain Name System)セキュリティー拡張(DNSSEC)を紹介する。 本文書と2つの付随する文書([I-D.ietf-dnsext-dnssec-records]と [I-D.ietf-dnsext-dnssec-protocol])は、RFC2535[RFC2535]およりそれ以前の ものにより定義されたセキュリティー拡張を更新し、明確にし、洗練するもの である。これらのセキュリティー拡張は、新しいリソースレコードタイプの 集合と、既存のDNSプロトコル[RFC1035]への修正から構成される。新しい レコードとプロトコルの修正は本文書では完全には記述されず、セクション9で 概説される関連文書の中で完全な記述がなされる。セクション3とセクション4 では、セキュリティー拡張の機能と制限について、より詳細な記述を行う。 セクション5~セクション8では、セキュリティー拡張がリゾルバー、スタブ リゾルバー、ゾーン、ネームサーバーに与えるであろう影響について論じる。 本文書と付随する2つの文書は、RFC2535[RFC2535]、3008[RFC3008]、 3090[RFC3090]、3226[RFC3226]、3445[RFC3445]を更新、廃止するとともに、 作業中の文書である"ADビットの再定義[I-D.ietf-dnsext-ad-is-secure]"、 "旧来のリゾルバーとDelegation Signerとの互換性 [I-D.ietf-dnsext-dnssec-2535typecode-change]"、 "Delegation Signerリソースレコード[I-D.ietf-dnsext-delegation-signer]" をも更新するものである。また、先に示した本文書と付随文書は RFC1034[RFC1034]、1035[RFC1035]、2136[RFC2136]、2182[RFC2181]、 2308[RFC2308]、3597[RFC3597]を更新する。ただし、これらの文書は 廃止されない。 DNSセキュリティー拡張は、DNSデータの起源の認証機能と完全性保護機能を 提供するだけではなく、公開鍵を配布する手段も提供する。これらの拡張は 機密性を提供するものではない。 Arends, et al. Expires June 16, 2004 [Page 3] Internet-Draft DNSSEC Introduction and Requirements December 2003 2. 重要なDNSSEC用語の定義 本セクションでは、本文書を含む一連の文書で使用される数多くの用語を 定義する。この用語定義は、今後一連の文書を読む際に参照元として 有用であることを意図している。読者は最初は本セクションを手短に 読み飛ばしても構わないが、本文書を読み進める段階で、適宜本セクションに 立ち戻ってもらいたい。 認証の連鎖: DNSKEY RRセットとDS RRを交互に繰り返す系列は、署名付きデータの 連鎖を形成する。この連鎖の各リンクは、次のリンク先を保証する。 DNSKEY RRはDS RRの署名を検査するために使用され、DS RRの認証を 可能とする。DS RRは別のDNSKEY RRのハッシュを含み、この新しい DNSKEY RRはDS RR内のハッシュと一致するかどうかによって認証される。 この新しいDNSKEY RRは順次他のDNSKEY RRセットを認証し、このセットに 含まれる幾つかのDNS KEY RRが他のDS RRを認証するために使用される。 この一連の処理が繰り返され、最終的に署名付きデータの連鎖は要求する DNSデータに署名しているDNSKEY RRで終了する。例えば、"example."用の DS RRを認証するために、rootのDNSKEYを使用することができる。 "example."のDS RRは"example."の幾つかのDNSKEYに一致するハッシュを含み、 このDNSKEYは"example."のDNSKEY RRセットに署名する。"example."の DNSKEY RRセットに含まれる秘密鍵は、"www.example."のような データレコードに署名するとともに、"subzone.example."のような 委任に関するDS RRにも署名する。 認証鍵: セキュリティー対応リゾルバーによって検証され、したがって データを認証するために使用することができる公開鍵。セキュリティー対応 リゾルバーは認証鍵を三つの方法で入手することができる。 まず、一般にリゾルバーには少なくとも一つの公開鍵が事前に設定 されている。この事前に設定されるデータは公開鍵そのものか、 DS RRから得た鍵のハッシュかのどちらかである。次に、リゾルバーは 認証された公開鍵を使用してDS RRと、関連するDNSKEY RRを 検証する 場合がある。三つ目の方法として、リゾルバーがあらかじめ検証した 他の鍵によって署名された新しい鍵を使用すると決定できる場合がある。 リゾルバーが新しい鍵を認証するかどうかを判断する際には、 常に局所的なポリシーによって先導されなければならないことに 注意してもらいたい。局所的なポリシーが単にリゾルバーが署名を 検証可能な全ての鍵を認証するというものであったとしても、 これは変わらない。 委任ポイント: ゾーンの分割場所(zone cut)における、親側の名前を表す ために使用する用語。すなわち、"foo.example"の委任ポイントは "example"ゾーンのfoo.exampleノードである。("foo.example"ゾーンの 頂点とは対照的なものである) セキュリティーの島: 署名され、委任されてはいるが、委任した親から 開始される認証の連鎖を持たないゾーンを表すために記述する用語。 すなわち、委任した親側のゾーンには島の公開鍵を含むDS RRが存在しない ([I-D.ietf-dnsext-dnssec-records]参照)。 Arends, et al. Expires June 16, 2004 [Page 4] Internet-Draft DNSSEC Introduction and Requirements December 2003 セキュリティーの島はセキュリティー対応ネームサーバーによって 提供され、任意の委任された子ゾーンへの認証の連鎖を提供する場合がある。 セキュリティーの島またはその子、子の子等からの応答は、DNSプロトコル 以外の何らかの信頼できる手段によってそのゾーンのゾーン鍵を得ることが できる場合に限り有効とされる。 鍵署名鍵(KSK): 1つ以上の認証鍵に署名するために使われる認証鍵。 典型的には、鍵署名鍵はゾーン署名鍵に署名し、そのゾーン署名鍵が 順次他のゾーンデータに署名することになる。局所的なポリシーは ゾーン署名鍵を頻繁に変更するよう求めるかもしれないが、 鍵署名鍵はより安定した安全な入り口をゾーンに提供するために、 より長い有効期間を持ってもよい。ある認証鍵を鍵署名鍵と指定することは 純粋に運用上の問題である。DNSSECにおける検証処理は鍵署名鍵と 他のDNSSEC認証鍵を区別しない。鍵署名鍵については、 [I-D.ietf-dnsext-keyrr-key-signing-flag]でより詳細に検討される。 また、ゾーン署名鍵の項も参照のこと。 セキュリティー対応ネームサーバー: ([RFC1034]のセクション2.4で定義される) ネームサーバーの役割を担い、かつ本文書を含む一連の文書で定義される DNSセキュリティー拡張を理解するもの。より詳しく記述すると、 セキュリティー対応ネームサーバーとはDNSの問い合わせを受信し、 DNS応答を送信し、EDNS0[RFC2671]のメッセージサイズ拡張と DOビット[RFC3225]をサポートし、本文書を含む一連の文書で定義される RRタイプとメッセージヘッダービットをサポートするものである。 セキュリティー対応再帰検索ネームサーバー: セキュリティー対応 ネームサーバーとセキュリティー対応リゾルバー両方の役割を担うもの。 使いにくいが同じ意味の言い回しとしては"再帰的検索サービスを提供する セキュリティー対応ネームサーバー"が考えられる。 セキュリティー対応リゾルバー: ([RFC1034]のセクション2.4で定義される) リゾルバーの役割を担い、かつ本文書を含む一連の文書で定義される DNSセキュリティー拡張を理解するもの。より詳しく記述すると、 セキュリティー対応リゾルバーとはDNSの問い合わせを送信し、DNS応答を 受信し、EDNS0[RFC2671]のメッセージサイズ拡張とDOビット[RFC3225]を サポートし、DNSSECサービスを提供するために本文書を含む一連の文書で 定義されるRRタイプとメッセージヘッダービットを使用することができる ものである。 セキュリティー対応スタブリゾルバー: ([RFC1034]のセクション2.4で定義 される)リゾルバーの役割を担い、かつ本文書を含む一連の文書で定義 されるDNSセキュリティー拡張について少なくとも最低限の理解をすることは できるが、一連の文書で検討されているほとんど全ての作業を実行する ために、自身の代理となる1つ以上のセキュリティー対応再帰検索 ネームサーバーを信頼するもの。より詳しく記述すると、セキュリティー対応 スタブリゾルバーとは、DNS問い合わせを送信し、DNS応答を受信し、 セキュリティー対応リゾルバーに変わってDNSSECサービスを提供する セキュリティー対応再帰検索ネームサーバーに対して適切に安全な 通信路を確立することができるものである。セキュリティー対応リゾルバーと セキュリティー対応スタブリゾルバーとの差異は、基本的なDNS仕様に 含まれる反復モード(iterative-mode)と再帰モード(recursive-mode)との 差異とは違うものであることに注意してもらいたい。 特定のセキュリティー対応リゾルバーは再帰モードでは排他的に 動作する場合があるが、それでも自身が保持するDNSSEC署名の有効性検査は 実行する。一方でセキュリティー対応スタブリゾルバーは、定義により そのような作業は実行しない。 セキュリティー非対応(サーバーまたはリゾルバー): "セキュリティー対応"の 反意語。 署名付きゾーン: RRセットが署名され、また適切に構成されたDNSKEY、RRSIG、 NSEC、(任意で)DSレコードを含むゾーン 署名されていないゾーン: "署名付きゾーン"の反意語。 ゾーン署名鍵: ゾーンに署名するために使用される認証鍵。前述の鍵署名鍵の 項を参照のこと。典型的には、ゾーン署名鍵は、そのゾーン署名鍵に 署名する鍵署名鍵と同じDNSKEY RRセットの一部である。しかし、 ゾーン署名鍵はわずかに異なる目的のために使用されるものであり、 有効期間のように他の点では鍵署名鍵と異なっていてもよい。 鍵署名鍵の項も参照のこと。 Arends, et al. Expires June 16, 2004 [Page 6] Internet-Draft DNSSEC Introduction and Requirements December 2003 3. DNSセキュリティー拡張が提供するサービス DNSセキュリティー拡張はDNSデータに対し、データの起源の認証サービスと 完全性の保護サービスを提供する。これらのサービスには、DNSデータの 存在を認証付きで否定する仕組みも含まれる。この仕組みについては後に 記述する。 これらの仕組みはDNSプロトコルの変更を必要とする。DNSSECは4つの 新しいリソースレコードタイプ(RRSIG、DNSKEY、DS、NSEC)と2つの新しい メッセージヘッダービット(CDとAD)を追加する。DNSSEC RRを追加した結果 より大きくなるDNSメッセージサイズをサポートするために、DNSSECは EDNS0[RFC2671]のサポートも必要とする。最後に、セキュリティー対応 リゾルバーが問い合わせの中で、応答メッセージでDNSSEC RRを受信したい ことを明示できるように、DOビット[RFC3225]のサポートを必要とする。 これらのサービスは、[I-D.ietf-dnsext-dns-threats]で記述されるDNSへの 脅威の大部分を防御する。 3.1 データの起源の認証とデータの完全性保護 DNSSECは暗号技術を使用して生成された電子署名とDNSのRRセットを関連 付けることにより、認証機能を提供する。これらの電子署名は新しい リソースレコードであるRRSIGレコードに保存される。典型的には、ゾーンの データに署名するのは単一の秘密鍵であるが、複数の鍵を使用して署名する ことも可能である。例えば、幾つかの異なる電子署名アルゴリズムに基づく 複数の鍵を使用するといったことが考えられる。 セキュリティー対応リゾルバーが信頼できる手段でゾーンの公開鍵を 学習するならば、リゾルバーはそのゾーンの署名付きデータを認証することが できる。DNSSECの重要な概念は、ゾーンのデータに署名する鍵は ゾーンそれ自体に関連するものであり、ゾーンの権威ネームサーバーには 関連付けられないということである。([RFC2931]に記述されるように、 DNSトランザクションを認証する仕組みで使用される公開鍵はゾーン内に 存在する。しかしDNSSECそれ自体はDNSデータのオブジェクト セキュリティー(*1)に関するものであり、DNSトランザクションの チャネルセキュリティー(*1)に関するものではない)。 《脚注》 *1: 「オブジェクトセキュリティーとチャネルセキュリティー」 オブジェクトセキュリティーとは、データ側で安全を確保しようとする 考え方を指し、チャネルセキュリティーとはデータを転送する経路の 安全を確保するという考え方を指す。 セキュリティー対応リゾルバーは、ゾーンの公開鍵を学習することができる。 学習手段は、事前にリゾルバーの設定として公開鍵を持つか、通常のDNSに よって名前解決をするか、どちらか一方である。後者の手段を可能にするために、 公開鍵が新しいリソースレコードであるDNSKEY RR内に保存される。 ゾーンデータ署名に使用される秘密鍵は安全な状態で維持されなければ ならず、またオフラインに保存することが実際的な場合にはそのように すべきであることに注意してもらいたい。DNSの名前解決を経て公開鍵を 確実に発見するために、検索対象となる鍵は事前に設定された認証鍵か、 またはあらかじめ認証された鍵のどちらかによって署名されている必要がある。 セキュリティー対応リゾルバーは、新しく学習した公開鍵から既知の 認証公開鍵に向けて認証の連鎖を形成することにより、ゾーン情報を認証する。 既知の認証鍵はあらかじめリゾルバーに設定されたものか、事前に学習し 検証されたものかのどちらかでなければならない。 Arends, et al. Expires June 16, 2004 [Page 7] Internet-Draft DNSSEC Introduction and Requirements December 2003 したがって、セキュリティー対応リゾルバーには最低1つの公開鍵または 公開鍵のハッシュが設定されなければならない。あらかじめ設定された鍵が ゾーン署名鍵の場合、その鍵は関連するゾーンを認証する。また、あらかじめ 設定された鍵が鍵署名鍵である場合には、その鍵はゾーン署名鍵を認証する。 リゾルバーに鍵そのものではなく、鍵のハッシュが設定されている場合、 リゾルバーはDNSの問い合わせを経て鍵を得る必要があるかもしれない。 セキュリティー対応リゾルバーがこの認証の連鎖を確立するのを補助する ために、セキュリティー対応ネームサーバーは、DNS応答メッセージに余裕が あれば、ゾーンの公開鍵と共にゾーンの公開鍵を認証するために必要とされる 署名を送信しようと試みる。 Delegation Signer(DS) RRタイプは、組織の境界を越えた委任に署名する際に 必要とされる幾つかの管理作業を簡略化する。DS RRセットは親ゾーンの 委任ポイントに存在し、委任された子ゾーンが子ゾーンの頂点でDNSKEY RRセット に自己署名するために使用する1つまたは複数の鍵を示す。子ゾーンは、 このDNSKEY RRセットに含まれる1つ以上の鍵を使用して順次ゾーンデータを 署名する。したがって、認証の連鎖はDNSKEY->[DS->DNSKEY]*->RRセット という形になる。ここで、"*"は0個または複数個のDS->DNSKEYの副連鎖を 意味する。 セキュリティー対応リゾルバーは通常、あらかじめ設定されたrootの公開鍵の 知識に基づき、DNS階層のrootからリーフゾーンに向けて認証の連鎖を構築する。 しかし、局所的なポリシーにより、セキュリティー対応リゾルバーはrootの 鍵ではなく、1つ以上のあらかじめ設定された鍵(または鍵のハッシュ)を 使用することができる。あるいは、ポリシーによってrootの鍵の情報が事前に 与えられないこともある。また、何らかの理由に基づき、たとえある鍵が 検証可能な署名によって適切に署名されているとしても、ポリシーによって リゾルバーにその鍵の使用を抑制することがある。DNSSECは、セキュリティー 対応リゾルバーが、あるRRセットの署名がDNSSEC的な意味で"有効"であるかを 判定可能な仕組みを提供する。しかし、結局のところDNSの鍵とデータの認証は 局所的ポリシーに依存する事項であるため、本文書を含む一連の文書で 定義されるプロトコル拡張が更に拡張される場合もあるし、無効にされる 場合すらあり得る。 3.2 名前とタイプの不存在の認証 セクション3.1で記述されたセキュリティーの仕組みは、ゾーン内に存在する RRセットに署名する手段を提供するだけである。否定応答に対して同水準の 認証と完全性保護を提供するためには、新しいリソースレコードタイプである、 NSECレコードが必要である。NSECレコードにより、セキュリティー対応 リゾルバーが他のDNS応答を認証する際に使用されるものと同じ仕組みによって、 名前またはタイプのどちらかの不存在が認証可能になる。 NSECレコードを使用するために、ゾーン内のドメイン名が正式に表現され、 かつ順序付けがされている必要がある。NSECレコードの連鎖は、ゾーン内の ドメイン名の間に存在する隔たりまたは"空の空間"を明示的に記述すると共に、 既存の名前空間に存在するRRセットのタイプをリストする。各NSECレコードは、 セクション3.1で記述される仕組みを使用して署名、認証される。 Arends, et al. Expires June 16, 2004 [Page 9] Internet-Draft DNSSEC Introduction and Requirements December 2003 4. DNSセキュリティー拡張が提供しないサービス DNSは本来、誰が問い合わせを行ったかにかかわらず、同じ問い合わせに 対しては同じ応答を返すという前提があり、したがってDNSに含まれる 全てのデータは閲覧可能であるという前提に基づいて設計がなされている。 そのため、DNSSECは機密性やアクセス制御リストを提供したり、問い合わせの 発信元を差別化する他の手段を提供するようには設計されていない。 DNSSECはサービス不能攻撃(denial of service attack)に対する防御手段を 提供しない。セキュリティー対応リゾルバーとセキュリティー対応ネーム サーバーは、暗号操作に基づく付加的なクラスのサービス不能攻撃に 対しては脆弱である。詳細はセクション11を参照のこと。 DNSセキュリティー拡張は、DNSデータとデータの起源の認証機能を提供する。 先に概略を説明した仕組みは、ゾーン転送や動的更新[RFC3007]のような 処理に対する保護機能を拡張するものではない。ゾーン転送や動的更新に 対してセキュリティー処理を施すものは、[RFC2845]と[RFC2931]で記述される メッセージ認証の仕組みである。 Arends, et al. Expires June 16, 2004 [Page 10] Internet-Draft DNSSEC Introduction and Requirements December 2003 5. リゾルバーに関する考察 セキュリティー対応リゾルバーは、少なくとも実装必須(mandatory-to- implement)のアルゴリズムを使用して電子署名を検証するために必要と される暗号機能を実行できる必要がある。セキュリティー対応 リゾルバーは、先に記述したように新たに学習したゾーンから認証鍵への 認証の連鎖を形成できなければならない。この処理は、必要なDNSKEY、DS、 RRSIGレコードを得るために、中間のDNSゾーンに対して追加の問い合わせを 必要とするかもしれない。認証の連鎖を確立する試みを開始するポイント として、セキュリティー対応リゾルバーには、少なくとも1つの認証鍵 または鍵のDS RRハッシュが設定されるべきである。 セキュリティー対応リゾルバー再帰検索ネームサーバーまたは DNSプロキシーとして動作する何らかのデバイスによって適切な権威ネーム サーバーから切り離されている状態で、その再帰検索ネームサーバーまたは プロキシーがセキュリティー対応ではない場合、セキュリティー対応 リゾルバーは安全なモードでは動作できないかもしれない。 例えば、セキュリティー対応リゾルバーのパケットがセキュリティーに 対応していないDNSプロキシー機能を持つネットワークアドレス変換(NAT) デバイスを通してやりとりされる場合、セキュリティー対応リゾルバーが 署名付きDNSデータを得たり、署名付きDNSデータを検証することは 困難であるか不可能だろう。 セキュリティー対応リゾルバーが署名されていないゾーンまたはセキュリティーに 対応していないネームサーバーに依存しなければならない状況では、 リゾルバーはDNS応答を検証できないかもしれない。したがって、 検証されない応答を受理するかどうかに関する局所的ポリシーを必要とする。 セキュリティー対応リゾルバーは、リゾルバーのキャッシュに含まれる データのTTLを決める際に、署名の有効期限を越えて署名付きデータを キャッシュしないように、署名の有効期限を考慮すべきである。 またセキュリティー対応リゾルバー自身の時計が誤っている可能性も 考慮すべきである。したがって、セキュリティー対応再帰検索ネーム サーバー上で動作するセキュリティー対応リゾルバーは、DNSSECの "検査無効(checking disabled)"(CD)ビット[I-D.ietf-dnsext-dnssec-records]に 細心の注意を払う必要がある。この措置は、この再帰検索ネームサーバーの クライアントになっている他のセキュリティー対応リゾルバーが、 このサーバーを通過した有効な署名をブロックするのを避けるためのもの である。安全な再帰検索ネームサーバーがCDビットが設定された問い合わせを どのように処理するかについては[I-D.ietf-dnsext-dnssec-protocol]を 参照のこと。 Arends, et al. Expires June 16, 2004 [Page 11] Internet-Draft DNSSEC Introduction and Requirements December 2003 6. スタブリゾルバーに関する考察 プロトコルによって厳格に要求されているわけではないが、ほとんどの DNSの問い合わせはスタブリゾルバーから発信される。スタブリゾルバーとは、 定義により、DNSリゾルバーとして最低限の機能を持ち、ほとんどの DNS名前解決の作業を再帰検索ネームサーバーに委託するために再帰検索の 問い合わせモードを使用するものである。スタブリゾルバーは広い範囲で 使用されているため、DNSSECアーキテクチャーはスタブリゾルバーを 考慮しなければならない。しかし、スタブリゾルバーで必要とされる セキュリティー機能は、全ての機能を持つセキュリティー対応リゾルバーで 必要とされるセキュリティー機能とは異なるものである。 たとえスタブリゾルバーがセキュリティー機能に対応していないとしても、 リゾルバーが使用する再帰検索ネームサーバーがセキュリティー対応であれば、 DNSSECから幾らかの利益を得られるかもしれない。しかし、スタブリゾルバーが DNSSECサービスにある程度実際の信頼を置くためには、スタブリゾルバーは 使用する再帰検索ネームサーバーと、そのネームサーバーへの通信チャネルの 両方を信頼しなければならないという問題がある。はじめの、使用する再帰検索 ネームサーバーを信頼しなければならないという問題は、局所的ポリシーの 問題といえる。本質的に、セキュリティー機能を意識しないスタブリゾルバーは、 使用する再帰検索ネームサーバーを全面的に信頼する以外に現実的に 選択の余地はない。なぜなら、リゾルバーはDNSSECの有効性検査を 実行しないからである。二つ目の、ネームサーバーへの通信チャネルを 信頼しなければならないという問題は、ある種のチャネルセキュリティーを 必要とする。IPsecを適切に使用するのと同じように、SIG(0)またはTSIGの ようなDNSトランザクションを認証する仕組みを適切に使用すれば充分であろう。 また特定の実装ではオペレーティングシステム固有のプロセス間通信の 仕組みのような他の選択肢が利用できるかもしれない。このチャネルに 機密性は必要ないが、データの完全性保護とメッセージ認証は必要である。 使用する再帰検索ネームサーバーも、そのサーバーへの通信チャネルも、 どちらも信頼するセキュリティー対応スタブリゾルバーは、受信した 応答メッセージのメッセージヘッダー内にADビットが設定されているかを 検査するという選択をしてもよい。応答の回答部(Answer section)と権威部 (Authority section)に含まれるデータ全てについて、再帰検索ネームサーバーが 署名を検証できたのかどうかに関するヒントとして、スタブリゾルバーは このフラグビットを使用することができる。 セキュリティー対応スタブリゾルバーが何らかの理由で使用する再帰検索 ネームサーバーと有用な信頼関係を確立できない場合に、スタブリゾルバーが 選択できるもう1つの方法がある。スタブリゾルバーは、問い合わせメッセージに 検査無効(CD)ビットを設定することにより、自ら署名の検証を実行することが できる。この方法を選択した場合、そのリゾルバーは(本文書を含む一連の 文書で使用される用語では)スタブリゾルバーではなくなり、機能が 幾分限定されたセキュリティー対応リゾルバーとなる。 Arends, et al. Expires June 16, 2004 [Page 12] Internet-Draft DNSSEC Introduction and Requirements December 2003 7. ゾーンに関する考察 署名付きゾーンと署名されていないゾーンの間には幾つかの違いがある。 署名付きゾーンは付加的なセキュリティー関連のレコード(RRSIG、DNSKEY、 DS、NSECレコード)を含む。RRSIGとNSECレコードは、ゾーン提供前に行われる 署名処理によって生成され得る。ゾーンデータに付随するRRSIGレコードは、 あらかじめ定義された開始時間(inception)と終了時間(expiration)を持つ。 これらにより、署名と署名されたゾーンデータの有効期間が定められる。 7.1 TTL値とRRSIGの有効期間 RRセットのTTL値とRRセットに署名するRRSIG RRで指定された署名の有効期間の 違いについて注意することは重要である。DNSSECは、キャッシュ内で データベースの一貫性を維持することを意図するTTL値の定義または機能を 変更しない。キャッシュ機能付リゾルバーは、そのリゾルバーが セキュリティー対応であるかどうかに関わらず、RRセットのTTLフィールドで 指定された期間の終わりまでに、RRセットをキャッシュから消去する。 一方で、RRSIG RRの開始時間フィールドと終了時間フィールド [I-D.ietf-dnsext-dnssec-records]は、署名がRRセットの検証に使用できる 期間を指定する。署名付きゾーンに関する署名は、対応するRRSIG RRのこれらの フィールドで指定された期間だけ有効である。TTL値はリゾルバーの キャッシュ内にある署名付きRRセットの有効期間を延長させることはできない。 しかし、リゾルバーは署名付きRRセットの署名有効期間が終了するまでの 残り時間を、リゾルバーのキャッシュ内にある署名付きRRセットと関連する RRSIG RRのTTLの上限として使用してもよい。 7.2 新たに発生するゾーンの時間依存問題 署名付きゾーンに含まれる情報には、オリジナルのDNSプロトコルには存在 しなかった時間への依存関係が存在する。署名付きゾーンでは、ゾーン内の 各RRセットがそれぞれ現在有効なRRSIG RRを持つことを保証するために、 定期的な保守が必要である。RRSIG RRの署名有効期間は、ある特定の 署名付きRRセットの署名が有効であるとみなされる期間である。したがって、 ゾーン内の異なるRRセットの署名はその署名とは別の時刻に有効期間が 終了するかもしれない。あるゾーンに含まれる1つ以上のRRセットに再署名を 行うと、順次ゾーンが変更されたことを示すためにゾーンのSOAのシリアル 番号の増加とSOA RRセット自身への再署名が必要となる。したがって、 ゾーン内のどのようなRRセットへの再署名であっても、DNS NOTIFYメッセージと ゾーン転送処理の契機となり得る。 Arends, et al. Expires June 16, 2004 [Page 13] Internet-Draft DNSSEC Introduction and Requirements December 2003 8. ネームサーバーに関する考察 リゾルバーは、メッセージサイズ制限を考慮してEDNSヘッダーを使用し、 その中でDOビットを設定することにより、DNSSECレコードの受信の 意志を通知することができる。セキュリティー対応ネームサーバーは、 リゾルバからのそれらの問い合わせに対して、全ての応答に適切な DNSSECレコード(RRSIG、DNSKEY、DS、NSEC)を含めるべきである。 このため、セキュリティー対応ネームサーバーはEDNSの仕組みによる メッセージサイズ拡張をサポートしなければならない。そうでなければ、 DNSSEC RRを含めることにより、容易にUDPメッセージの切り詰め処理 (truncation)と、TCPへの後退が発生してしまうかもしれない。 できるならば、DNSSECの鍵ペアそれぞれについて、秘密鍵はオフラインで 保管されるべきである。しかし、これはDNSの動的更新が利用可能なゾーンでは 不可能である。動的更新を使用する場合、ゾーンのプライマリーマスター サーバーはゾーン更新時にゾーンに再署名しなければならなくなるため、 ゾーン署名鍵の秘密鍵側はオンラインで保管される必要がある。 これはゾーンのDNSKEY RRセットをゾーン署名鍵と鍵署名鍵に分離する機能が 有用な状況の例である。鍵署名鍵は、このような状況であっても依然として オフラインで管理が可能である。 DNSSEC単体では、ゾーン転送処理の際にゾーン全体の完全性を保護するのに 不十分である。署名付きゾーンであっても、ゾーンが子を持つ場合は幾つかの 署名されていないデータを含むからである。したがって、ゾーンの保守作業は 幾つかの付加的な仕組み(おそらくはTSIG、SIG(0)、IPsecのような チャネルセキュリティー方式のものだろう)を必要とするだろう。 Arends, et al. Expires June 16, 2004 [Page 14] Internet-Draft DNSSEC Introduction and Requirements December 2003 9. DNSセキュリティー拡張の関連文書 一連のDNSSEC文書は、図1に示すように5つの主要なグループに分割可能 である。これら全ての文書は、順次DNSの基本プロトコルを記述した文書の より大きな傘の下に入る。 9.1 DNSセキュリティー拡張に関連する文書のロードマップ +------------------------------------+ | 基本的なDNSプロトコルの文書 | | [RFC1035、RFC2181とそれに続くもの] | +------------------------------------+ | | +-----------+ +----------+ | DNSSEC | | 新しい | | プロトコル|--------->| DNSSECの | | 文書 | | 使用法 | +-----------+ +----------+ | | +---------------- - - - - - - -+ | . | . +------------------+ +--------------------+ | 電子署名 | | トランザクションの | | アルゴリズムの | | 認証の実装 | | 実装 | +--------------------+ +------------------+ 9.2 DNSセキュリティー拡張に関連する文書の分類 "DNSSECプロトコルに関する一連の文書"とは、DNSセキュリティー拡張の 中核をなす以下の3つの文書を指す。 1. DNSセキュリティー拡張の紹介とその要件(本文書) 2. DNSセキュリティ拡張用のリソースレコード [I-D.ietf-dnsext-dnssec-records] 3. DNSセキュリティー拡張のためのプロトコル修正 [I-D.ietf-dnsext-dnssec-protocol] "電子署名アルゴリズムの実装"に分類される一連の文書とは、特定の電子署名 アルゴリズムをどのようにしてDNSSECのリソースフォーマットに適合させつつ 実装するかを記述した文書のグループを指す。これらの文書それぞれが、 1つ1つの特定の電子署名アルゴリズムを扱う。 Arends, et al. Expires June 16, 2004 [Page 15] Internet-Draft DNSSEC Introduction and Requirements December 2003 "トランザクションの認証の実装"に分類される一連の文書とは、秘密鍵の 確立と検証を含むDNSメッセージ認証について扱う文書のグループを指す。 これは厳密には本文書を含む一連の文書で規定されるDNSSEC仕様の 一部ではないが、DNSSECとの関係を示すためにこのグループについても 言及した。 最後の"新しいDNSSECの使用法"に分類される一連の文書とは、提案された DNSセキュリティー拡張を他のセキュリティー関連の目的で使用する方法 について模索する文書を指す。DNSSECはこれらの新しい使用法に対して 何か直接的なセキュリティー機能を提供するわけではないが、 それらをサポートするために使用することはできるかもしれない。 ここに分類される文書には、証明書(certificate)を保存、分配するために DNSを使用するもの[RFC2538]が含まれる。 Arends, et al. Expires June 16, 2004 [Page 16] Internet-Draft DNSSEC Introduction and Requirements December 2003 10. IANAに関する考察 DNSSECの概観を記述する本文書では、新たなIANAに関する考察は導入 されない。DNSSECによって導入されるIANAに関する考察の再検討の全容に ついては[I-D.ietf-dnsext-dnssec-records]を参照のこと。 Arends, et al. Expires June 16, 2004 [Page 17] Internet-Draft DNSSEC Introduction and Requirements December 2003 11. セキュリティーに関する考察 本文書はDNSセキュリティー拡張を紹介し、新しいセキュリティーレコードと DNSプロトコルの修正を含む一連の文書について記述している。また、 本文書はこの拡張の機能と制限についても検討した。この拡張は、電子署名を リソースレコードセットに適用することにより、データの起源の認証機能と データの完全性の保護機能を提供するものである。 本文書を含む一連の文書で定義されるように、セキュリティー対応 リゾルバーがDNS応答を検証できるように、全ての中間ゾーンは署名 されなければならない。また全ての中間ネームサーバーはセキュリティー対応 でなければならない。セキュリティー対応リゾルバーは、署名されていない ゾーンから生成された応答を検証することはできない。また、セキュリティー 非対応の再帰検索ネームサーバーを経由してしか応答を得られない場合も、 その応答を検証することはできない。セキュリティー対応リゾルバーが 必要とする認証鍵を得られないか、検証できないといった理由で認証の連鎖に 断絶が存在する場合、セキュリティー対応リゾルバーはその断絶に影響を受ける DNSデータを検証することはできない。 本文書では、DNSの問い合わせにセキュリティーを追加する他の手法について 簡単な検討を行った。他の手法とは、IPsecによって保護されたチャネルを 使用したり、DNSトランザクションを認証する仕組みを使用するものを指す。 しかし、トランザクションセキュリティーはそれ自体DNSSECの一部ではない。 セキュリティー対応スタブリゾルバーは、定義により、それ自身では DNSSECの署名検証を実行しない。したがって、署名検証をリゾルバーの 代わりに実行するセキュリティー対応再帰検索ネームサーバー上における 攻撃(とその結果として生じるサーバーを経由した攻撃)、サーバーまでの 通信路における攻撃などに対して脆弱である。セキュリティー対応スタブ リゾルバーは、後者の脅威を防御するために、何らかの形態のチャネル セキュリティーを使用すべきである。前者の脅威に対する防御方法として 唯一知られているものは、セキュリティー対応スタブリゾルバーが自身で 署名検証を実行することである。この時点で、定義により、このリゾルバーは セキュリティー対応スタブリゾルバーではなくなる。 DNSSECはサービス不能攻撃を防御しない。また、DNSSECを使用する場合、 攻撃者はDNSSECの仕組みを悪用し、被害を受けるマシンのリソース消耗を 試みられることから、DNSSECはセキュリティー対応リゾルバーと セキュリティー対応ネームサーバーに対する暗号操作に基づいた 新しいクラスのサービス不能攻撃に対してDNSを脆弱にするともいえる。 このクラスの攻撃は少なくとも二つの形態がある。攻撃者は、応答メッセージに 含まれるRRSIG RRを改ざんするか、または必要以上に複雑な署名の連鎖を 構成することにより、セキュリティー対応リゾルバーが署名検証コードを 実行する際にリソースを消耗させることができる可能性がある。 また、攻撃者はDNS動的更新をサポートするセキュリティー対応ネームサーバーに 対して更新メッセージのストリームを送信し、本来必要とされるよりも 頻繁にゾーン内のRRセットに再署名することを強制することにより、 サーバーのリソースを消耗させることができる可能性がある。 DNSSECはNSECの連鎖を追うことにより、悪意を持つ者がゾーン内の全ての 名前を列挙できるような機能を付加する。NSEC RRは、ゾーンに含まれる 全ての名前を、既存の名前から既存の名前へと正規的な順序でリンクする ことにより、ゾーン内に存在しない名前を明示する。したがって、攻撃者は NSEC RRに順に問い合わせを行うことにより、ゾーン内の全ての名前を 得ることができる。この結果、DNSそのものへの攻撃ではないが、攻撃者は ゾーンの内容を列挙することにより、ネットワークホストや他のリソースを 把握することができる可能性がある。これに対し、単一ホストからの多数の NSECへの問い合わせの制限、侵入検知ツールの使用等といった、DNS以外の プロトコルを使用した攻撃の制限手法が存在する。 DNSSECはDNSに対して相当の複雑さを持ち込むために、実装時におけるバグや ゾーンが誤って設定される機会等が新たに発生する。 DNSSECは機密性を提供しない。これは設計時の意図的な選択である。 DNSSECは署名されていないゾーンのデータ改ざんを防御しない。ゾーンの 分割場所における権威の無いデータ(親ゾーンにおけるグルーとNS RR)は 署名されない。したがって、DNSSECはRRセットに対してデータの起源の 認証機能とデータ完全性保護機能は提供できるが、ゾーンに対して同じ機能は 提供できないため、ゾーン転送処理を保護するために他の仕組みを 使用しなければならない。 付加的なセキュリティーに関する考察については、 [I-D.ietf-dnsext-dnssec-records]と[I-D.ietf-dnsext-dnssec-protocol]を 参照のこと。 Arends, et al. Expires June 16, 2004 [Page 19] Internet-Draft DNSSEC Introduction and Requirements December 2003 12. 謝辞 本文書はDNS拡張ワーキンググループのメンバーのインプットとアイディアから 作成された。DNSSECが開発途上であった10年間に貢献をしてくれた全員を 明示的にリストすることは不可能な作業であるので、著者は本文書を含む 一連の文書に対して貢献とコメントを提供してくれた、以下の人々に特に 謝意を表したい。Mark Andrews、Derek Atkins、Alan Barrett、 Dan Bernstein、David Blacka、Len Budney、Randy Bush、Francis Dupont、 Donald Eastlake、Miek Gieben、Michael Graff、Olafur Gudmundsson、 Gilles Guette、Andreas Gustafsson、Phillip Hallam-Baker、 Walter Howard、Stephen Jacob、Simon Josefsson、Olaf Kolkman、 Mark Kosters、David Lawrence、Ted Lemon、Ed Lewis、Ted Lindgreen、 Josh Littlefield、Rip Loomis、Bill Manning、Mans Nilsson、 Masataka Ohta、Rob Payne、Jim Reid、Michael Richardson、 Erik Rozendaal、Jakob Schlyter、Mike StJohns、Sam Weiler、 Brian Wellington。 おそらく、上のリストは不完全だろう。我々は除外されてしまった人々に謝罪 するものである。 Arends, et al. Expires June 16, 2004 [Page 20] Internet-Draft DNSSEC Introduction and Requirements December 2003 必須の参考文献 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001. [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver message size requirements", RFC 3226, December 2001. [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002. [I-D.ietf-dnsext-dnssec-records] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "Resource Records for DNS Security Extensions", draft-ietf-dnsext-dnssec-records-05 (work in progress), October 2003. [I-D.ietf-dnsext-dnssec-protocol] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "Protocol Modifications for the DNS Security Extensions", draft-ietf-dnsext-dnssec-protocol-03 (work in progress), October 2003. Arends, et al. Expires June 16, 2004 [Page 21] Internet-Draft DNSSEC Introduction and Requirements December 2003 有用な参考文献 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. [RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System (DNS)", RFC 2538, March 1999. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( SIG(0)s)", RFC 2931, September 2000. [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) Signing Authority", RFC 3008, November 2000. [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone Status", RFC 3090, March 2001. [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. [I-D.ietf-dnsext-dns-threats] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name System", draft-ietf-dnsext-dns-threats-04 (work in progress), October 2003. [I-D.ietf-dnsext-ad-is-secure] Wellington, B. and O. Gudmundsson, "Redefinition of DNS AD bit", draft-ietf-dnsext-ad-is-secure-06 (work in progress), June 2002. [I-D.ietf-dnsext-delegation-signer] Gudmundsson, O., "Delegation Signer Resource Record", draft-ietf-dnsext-delegation-signer-15 (work in progress), June 2003. Arends, et al. Expires June 16, 2004 [Page 22] Internet-Draft DNSSEC Introduction and Requirements December 2003 [I-D.ietf-dnsext-dnssec-2535typecode-change] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work in progress), October 2003. [I-D.ietf-dnsext-keyrr-key-signing-flag] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure Entry Point Flag", draft-ietf-dnsext-keyrr-key-signing-flag-11 (work in progress), October 2003. 著者の連絡先 Roy Arends Telematica Instituut Drienerlolaan 5 7522 NB Enschede NL EMail: roy.arends@telin.nl Rob Austein Internet Software Consortium 40 Gavin Circle Reading, MA 01867 USA EMail: sra@isc.org Matt Larson VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA EMail: mlarson@verisign.com Dan Massey USC Information Sciences Institute 3811 N. Fairfax Drive Arlington, VA 22203 USA EMail: masseyd@isi.edu Arends, et al. Expires June 16, 2004 [Page 23] Internet-Draft DNSSEC Introduction and Requirements December 2003 Scott Rose National Institute for Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899-8920 USA EMail: scott.rose@nist.gov Arends, et al. Expires June 16, 2004 [Page 24] Internet-Draft DNSSEC Introduction and Requirements December 2003 知的所有権に関する表示 IETFは、実装に関する特許の主張や本文書に記述された技術を利用する 他の権利、そのような権利の下で利用可能または利用不可能なライセンスの 範囲について主張される可能性がある知的所有権のあらゆる範囲または 有効性に関して、何ら立場を表明しない。また、そのような権利を識別する ために何らかの努力をしてきたわけでもない。標準化過程と標準化に関連した 文書における権利に関するIETFの手続きについての情報は、BCP-11として 得ることができる。本仕様の実装者または利用者によって行われた作業の 結果として生じた、公開された特許の権利主張のコピー、その権利を 利用可能にするためのあらゆるライセンスの証書、一般的ライセンスまたは 所有権を行使する許可を得ようとする試み等についてはIETF事務局から 得ることができる。 IETFは、あらゆる関係者に対し、あらゆる著作権、特許または特許の実施、 本標準を実践するために必要とされる可能性がある技術をカバーした 所有権等に注目を寄せるよう呼びかける。IETF理事(Executeive Director)に その情報を寄せていただきたい。 完全な著作権表示 Copyright (C) The Internet Society (2003). 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 assignees. 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 Arends, et al. Expires June 16, 2004 [Page 25] Internet-Draft DNSSEC Introduction and Requirements December 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 謝辞 RFCエディターの活動に対する資金は現在Internet Societyによって 提供されている。 Arends, et al. Expires June 16, 2004 [Page 26] draft-ietf-dnsext-dnssec-intro-08-ja.txt revision 1.0 この翻訳文に関するお問い合わせは dnstech-info@jprs.jp までご連絡下さい。 Japan Registry Service Co., Ltd. http://jprs.jp/tech/