この文書はRFC4033の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group R. Arends
Request for Comments: 4033 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
Category: Standards Track D. Massey
Colorado State University
S. Rose
NIST
March 2005
DNS Security Introduction and Requirements
ＤＮＳ安全の紹介と必要条件
Status of This Memo
この文書の状態
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Abstract
要約
The Domain Name System Security Extensions (DNSSEC) add data origin
authentication and data integrity to the Domain Name System. This
document introduces these extensions and describes their capabilities
and limitations. This document also discusses the services that the
DNS security extensions do and do not provide. Last, this document
describes the interrelationships between the documents that
collectively describe DNSSEC.
ドメインネームシステムセキュリティ拡張（ＤＮＳＳＥＣ）はドメインネー
ムシステムにデータ源認証とデータ完全性を加えます。この文書はこれらの
拡張を紹介し、そしてそれらの能力と限界を記述します。この文書は同じく
ＤＮＳセキュリティ拡張が供給するサービスと供給しないサービスを論じま
す。最後に、この文書は共同でＤＮＳＳＥＣを記述する文書の間の相互関係
を記述します。
Table of Contents
目次
1. Introduction
1. はじめに
2. Definitions of Important DNSSEC Terms
2. 重要なＤＮＳＳＥＣ用語の定義
3. Services Provided by DNS Security
3. ＤＮＳセキュリティによって供給されるサービス
3.1. Data Origin Authentication and Data Integrity
3.1. データ源認証]とデータ完全性
3.2. Authenticating Name and Type Non-Existence
3.2. 名前とタイプの非実在証明
4. Services Not Provided by DNS Security
4. ＤＮＳセキュリティで供給されないサービス
5. Scope of the DNSSEC Document Set and Last Hop Issues
5. ＤＮＳＳＥＣ文書群とと最終ホップ問題の範囲
6. Resolver Considerations
6. リゾルバの考察
7. Stub Resolver Considerations
7. スタブリゾルバの考察
8. Zone Considerations
8. ゾーンの考察
8.1. TTL Values vs. RRSIG Validity Period
8.1. ＴＴＬ値と資源レコード署名有効期間
8.2. New Temporal Dependency Issues for Zones
8.2. ゾーンの新しい時間依存問題
9. Name Server Considerations
9. ネームサーバの考察
10. DNS Security Document Family
10. ＤＮＳセキュリティ文書ファミリ
11. IANA Considerations
11. ＩＡＮＡの考慮
12. Security Considerations
12. セキュリティの考察
13. Acknowledgements
13. 謝辞
14. References
14. 参考文献
14.1. Normative References
14.1. 参照する参考文献
14.2. Informative References
14.2. 有益な参考文献
Authors' Addresses
著者のアドレス
Full Copyright Statement
著作権表示全文
1. Introduction
1. はじめに
This document introduces the Domain Name System Security Extensions
(DNSSEC). This document and its two companion documents ([RFC4034]
and [RFC4035]) update, clarify, and refine the security extensions
defined in [RFC2535] and its predecessors. These security extensions
consist of a set of new resource record types and modifications to
the existing DNS protocol ([RFC1035]). The new records and protocol
modifications are not fully described in this document, but are
described in a family of documents outlined in Section 10. Sections
3 and 4 describe the capabilities and limitations of the security
extensions in greater detail. Section 5 discusses the scope of the
document set. Sections 6, 7, 8, and 9 discuss the effect that these
security extensions will have on resolvers, stub resolvers, zones,
and name servers.
この文書はドメインネームシステムセキュリティ拡張（ＤＮＳＳＥＣ）を紹
介します。この文書と２つの仲間文書（([RFC4034]と([RFC4035]）は、
[RFC2535]とその以前のもので定義されたセキュリティ拡張を更新、明確化し、
洗練します。これらのセキュリティ拡張は、新しい資源レコードタイプ、既
存のＤＮＳプロトコル（[RFC1035]）の変更から成り立ちます。新しいレコー
ドとプロトコル変更はこの文書で完全に記述されません、しかし１０章で概
説された文書ファミリーで記述されます。３章と４章がセキュリティ拡張の
能力と限界をより詳細に記述します。５章が文書群の範囲を論じます。６章
と７章と８章と９章がこれらのセキュリティ拡張のリゾルバとスタブリゾル
バとゾーンとネームサーバに対する効果を論じます。
This document and its two companions obsolete [RFC2535], [RFC3008],
[RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and
[RFC3845]. This document set also updates but does not obsolete
[RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225],
[RFC3007], [RFC3597], and the portions of [RFC3226] that deal with
DNSSEC.
この文書と２つの仲間文書は[RFC2535]と[RFC3008]と[RFC3090]と[RFC3445]
と[RFC3655]と[RFC3658]と[RFC3755]と[RFC3757]と[RFC3845]を時代遅れに
します。この文書群は、[RFC1034]と[RFC1035]と[RFC2136]と[RFC2181]と
[RFC2308]と[RFC3225]と[RFC3007]と[RFC3597]と[RFC3226]のＤＮＳＳＥＣ
を扱う部分を更新しますが時代遅れにはしません。
The DNS security extensions provide origin authentication and
integrity protection for DNS data, as well as a means of public key
distribution. These extensions do not provide confidentiality.
ＤＮＳセキュリティ拡張は、公開鍵配布の手段と同様、ＤＮＳデータに起源
認証と完全性保護を提供します。これらの拡張は機密性を供給しません。
2. Definitions of Important DNSSEC Terms
2. 重要なＤＮＳＳＥＣ用語の定義
This section defines a number of terms used in this document set.
Because this is intended to be useful as a reference while reading
the rest of the document set, first-time readers may wish to skim
this section quickly, read the rest of this document, and then come
back to this section.
この章はこの文書群で多くの使われる用語を定義します。これが、文書群の
残りを読む間の、参照として有用であるように意図されるから、初じめて読
む読者がこの章を飛ばして、この文書の残りを読んで、そして次にこの章に
戻ることを望むかもしれません。
Authentication Chain: An alternating sequence of DNS public key
(DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of
signed data, with each link in the chain vouching for the next. A
DNSKEY RR is used to verify the signature covering a DS RR and
allows the DS RR to be authenticated. The DS RR contains a hash
of another DNSKEY RR and this new DNSKEY RR is authenticated by
matching the hash in the DS RR. This new DNSKEY RR in turn
authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in
this set may be used to authenticate another DS RR, and so forth
until the chain finally ends with a DNSKEY RR whose corresponding
private key signs the desired DNS data. For example, the root
DNSKEY RRset can be used to authenticate the DS RRset for
"example." The "example." DS RRset contains a hash that matches
some "example." DNSKEY, and this DNSKEY's corresponding private
key signs the "example." DNSKEY RRset. Private key counterparts
of the "example." DNSKEY RRset sign data records such as
"www.example." and DS RRs for delegations such as
"subzone.example."
認証鎖：ＤＮＳ公開鍵資源レコード集合と委任署名（ＤＳ）資源レコード集
合の交互の連続は、それぞれの鎖のリンクが次を保証する形で、署名され
たデータの鎖を構成します。ＤＮＳＫＥＹ資源レコードが委任署名資源レ
コードの署名の検証に使われ、そして委任署名資源レコードを認証に使う
ことを許します。委任署名資源レコードは他のＤＮＳＫＥＹ資源レコード
のハッシュを含み、そしてこの新しいＤＮＳＫＥＹ資源レコードは委任署
名資源レコードのハッシュと一致することで認証されます。この新しいＤ
ＮＳＫＥＹ資源レコードは順に他のＤＮＳＫＥＹ資源レコード集合を認証
します、そして、順に、この集合のＤＮＳＫＥＹ資源レコードのどれかが
他の委任署名資源レコードを認証するかもしれません、そして鎖は最終的
に、対応する秘密鍵は目的のＤＮＳデータに署名するＤＮＳＫＥＹ資源レ
コードで終わります。例えば、ルートＤＮＳＫＥＹ資源レコード集合は
"example."の委任署名資源レコード集合を認証するために使うことができ
ます。"example."委任署名資源レコード集合は"example."ＤＮＳＫＥＹの
いずれかと一致するハッシュを含み、このＤＮＳＫＥＹに対応する秘密鍵
は"example."ＤＮＳＫＥＹ資源レコード集合を署名します。"example."Ｄ
ＮＳＫＥＹに対応する秘密鍵は"www.example."の様なデータレコードや
"subzone.example."の様な委任署名資源レコードに署名をします。
Authentication Key: A public key that a security-aware resolver has
verified and can therefore use to authenticate data. A
security-aware resolver can obtain authentication keys in three
ways. First, the resolver is generally configured to know about
at least one public key; this configured data is usually either
the public key itself or a hash of the public key as found in the
DS RR (see "trust anchor"). Second, the resolver may use an
authenticated public key to verify a DS RR and the DNSKEY RR to
which the DS RR refers. Third, the resolver may be able to
determine that a new public key has been signed by the private key
corresponding to another public key that the resolver has
verified. Note that the resolver must always be guided by local
policy when deciding whether to authenticate a new public key,
even if the local policy is simply to authenticate any new public
key for which the resolver is able verify the signature.
認証鍵：セキュリティの認識のあるリゾルバが検証し、それ故にデータ認証
に使うことができる公開鍵。セキュリティの認識のあるリゾルバが３つの
方法で認証鍵を得ることができます。最初に、一般にリゾルバは少なくと
も１つの公開鍵を知っているように設定されます；この設定データは通常
公開鍵それ自身あるいは委任署名資源レコードで見つかる公開鍵のハッシュ
です（「信頼固定点」参照）。第二に、リゾルバは委任署名資源レコード
と委任署名資源レコードが参照するＤＮＳＫＥＹ資源レコードを検証する
ために認証された公開鍵を使ってもよいです。第三に、リゾルバは新しい
公開鍵がリゾルバが検証した他の公開鍵に対応している秘密鍵によって署
名されたと決定することが可能であるかもしれません。たとえローカルポ
リシが単純にリゾルバが署名を検証できる新しい公開鍵は全て認証するこ
とであっても、新しい公開鍵を認証するべきかどうか決める時、リゾルバ
が常にローカルポリシに指示されなくてはならないことに注意してくださ
い。
Authoritative RRset: Within the context of a particular zone, an
RRset is "authoritative" if and only if the owner name of the
RRset lies within the subset of the name space that is at or below
the zone apex and at or above the cuts that separate the zone from
its children, if any. All RRsets at the zone apex are
authoritative, except for certain RRsets at this domain name that,
if present, belong to this zone's parent. These RRset could
include a DS RRset, the NSEC RRset referencing this DS RRset (the
"parental NSEC"), and RRSIG RRs associated with these RRsets, all
of which are authoritative in the parent zone. Similarly, if this
zone contains any delegation points, only the parental NSEC RRset,
DS RRsets, and any RRSIG RRs associated with these RRsets are
authoritative for this zone.
正式資源レコード集合：特定のゾーンの中で、もし資源レコード集合の所有
者名が、ゾーンの頂上か下にあり、かつ、子の切断点かその上にある、名
前空間の一部にある場合に、その資源レコード集合は「正式」です。すべ
てのゾーンの頂上の資源レコード集合は、このゾーンの親に属する特定の
資源レコード集合以外、正式です。例外の資源レコード集合には委任署名
資源レコード集合とこの委任署名資源レコード集合を参照しているＮＳＥ
Ｃ資源レコード集合（「親のＮＳＥＣ」）と、これらの資源レコード集合
に関する資源レコード署名資源レコードがあり、このすべては親ゾーンで
正式です。同様に、もしこのゾーンが委任ポイントを含んでいるなら、親
ＮＳＥＣ資源レコード集合と委任署名資源レコード集合とこれらの資源レ
コード集合の資源レコード署名資源レコードはこのゾーンで正式です。
Delegation Point: Term used to describe the name at the parental side
of a zone cut. That is, the delegation point for "foo.example"
would be the foo.example node in the "example" zone (as opposed to
the zone apex of the "foo.example" zone). See also zone apex.
委任点：ゾーン切断の親の側の名前を記述した用語。すなわち、
"foo.example"の委任点は"example"ゾーンのfoo.example節です
（"foo.example"ゾーンの頂上と対照した場合）。同じくゾーン頂上を見
てください。
Island of Security: Term used to describe a signed, delegated zone
that does not have an authentication chain from its delegating
parent. That is, there is no DS RR containing a hash of a DNSKEY
RR for the island in its delegating parent zone (see [RFC4034]).
An island of security is served by security-aware name servers and
may provide authentication chains to any delegated child zones.
Responses from an island of security or its descendents can only
be authenticated if its authentication keys can be authenticated
by some trusted means out of band from the DNS protocol.
セキュリティの孤島：委任の親からの認証鎖を持たない、署名された委任ゾー
ンを記述する用語。すなわち、委任の親ゾーンに孤島のＤＮＳＫＥＹ資
源レコードのハッシュを含む委任署名資源レコードがない場合です
（[RFC4034]参照）。セキュリティの孤島がセキュリティの認識のある
ネームサーバによってサポートされて、そしてどんな委任された子ゾー
ンにでも認証鎖を供給してもよいです。セキュリティの孤島あるいはそ
の下からの回答は、もしその認証鍵がＤＮＳプロトコル以外の信頼でき
る手段によって認証できる場合にだけ、認証できます。
Key Signing Key (KSK): An authentication key that corresponds to a
private key used to sign one or more other authentication keys for
a given zone. Typically, the private key corresponding to a key
signing key will sign a zone signing key, which in turn has a
corresponding private key that will sign other zone data. Local
policy may require that the zone signing key be changed
frequently, while the key signing key may have a longer validity
period in order to provide a more stable secure entry point into
the zone. Designating an authentication key as a key signing key
is purely an operational issue: DNSSEC validation does not
distinguish between key signing keys and other DNSSEC
authentication keys, and it is possible to use a single key as
both a key signing key and a zone signing key. Key signing keys
are discussed in more detail in [RFC3757]. Also see zone signing
key.
鍵調印の鍵（ＫＳＫ）：あるゾーンの他の認証鍵に署名する秘密鍵に対応す
る認証鍵。典型的に、鍵署名鍵に対応している秘密鍵はゾーン署名鍵に署
名をし、そしてゾーン署名鍵は他のゾーンデータに署名する対応する秘密
鍵を持っています。ローカルポリシがゾーン署名鍵を頻繁に変えることを
要求するかもしれないが、鍵署名鍵はゾーンの安定したセキュリティの入
口点を供給するためにより長い有効期間を持つかもしれません。認証鍵を
鍵署名鍵と指名することは純粋に運用上の問題です：ＤＮＳＳＥＣ検証は
鍵署名鍵と他のＤＮＳＳＥＣ認証鍵を区別しません、そしてひとつの鍵を
鍵署名鍵とゾーン署名鍵の両方として用いることは可能です。鍵署名鍵は
[RFC3757]でより多くの詳細が論じられます。同じくゾーン署名鍵を見て
ください。
Non-Validating Security-Aware Stub Resolver: A security-aware stub
resolver that trusts one or more security-aware recursive name
servers to perform most of the tasks discussed in this document
set on its behalf. In particular, a non-validating security-aware
stub resolver is an entity that sends DNS queries, receives DNS
responses, and is capable of establishing an appropriately secured
channel to a security-aware recursive name server that will
provide these services on behalf of the security-aware stub
resolver. See also security-aware stub resolver, validating
security-aware stub resolver.
非検証のセキュリティの認識があるスタブリゾルバ：セキュリティの認識が
ある再帰ネームサーバが、この文書群で論じらた仕事の大部分を行うのを
安心して任す、セキュリティの認識があるスタブリゾルバ。特に、非検証
のセキュリティの認識があるスタブリゾルバは、ＤＮＳの問合せを送り、
ＤＮＳ回答を受け取るスタブリゾルバで、これらのサービスを供給するセ
キュリティの認識がある再帰ネームサーバとの間に適切に安全に保たれた
チャネルを確立することができます。同じくセキュリティの認識があるス
タブリゾルバ、検証をするセキュリティの認識があるスタブリゾルバを見
てください。
Non-Validating Stub Resolver: A less tedious term for a
non-validating security-aware stub resolver.
非検証のスタブリゾルバ：非検証のセキュリティの認識があるスタブリゾル
バの短い言い方。
Security-Aware Name Server: An entity acting in the role of a name
server (defined in section 2.4 of [RFC1034]) that understands the
DNS security extensions defined in this document set. In
particular, a security-aware name server is an entity that
receives DNS queries, sends DNS responses, supports the EDNS0
([RFC2671]) message size extension and the DO bit ([RFC3225]), and
supports the RR types and message header bits defined in this
document set.
セキュリティの認識のあるネームサーバ：この文書群で定義したＤＮＳセキュ
リティ拡張を理解し、（[RFC1034]の２.４章で定義された）ネームサーバ
の役割をするエンティティー。特に、セキュリティの認識のあるネームサー
バはＤＮＳの問合せを受け取るエンティティーで、ＤＮＳ回答を送り、
ＥＤＮＳ０（[RFC2671]）メッセージサイズ拡張とＤＯビット（[RFC3225]）
をサポートし、そしてこの文書群で定義した資源レコードタイプとメッセー
ジヘッダビットをサポートします。
Security-Aware Recursive Name Server: An entity that acts in both the
security-aware name server and security-aware resolver roles. A
more cumbersome but equivalent phrase would be "a security-aware
name server that offers recursive service".
セキュリティの認識がある再帰ネームサーバ：セキュリティの認識のあるネー
ムサーバとセキュリティの認識のあるリゾルバの両方の役割をするエンティ
ティー。難しく言うと「再帰サービスを提供するセキュリティの認識のあ
るネームサーバ」です。
Security-Aware Resolver: An entity acting in the role of a resolver
(defined in section 2.4 of [RFC1034]) that understands the DNS
security extensions defined in this document set. In particular,
a security-aware resolver is an entity that sends DNS queries,
receives DNS responses, supports the EDNS0 ([RFC2671]) message
size extension and the DO bit ([RFC3225]), and is capable of using
the RR types and message header bits defined in this document set
to provide DNSSEC services.
セキュリティの認識のあるリゾルバ：この文書群で定義したＤＮＳセキュリ
ティ拡張を理解する（[RFC1034]の２.４章で定義された）リゾルバの役割
をするエンティティー。特に、セキュリティの認識のあるリゾルバがＤＮ
Ｓの問合せを送り、ＤＮＳ回答を受け取り、ＥＤＮＳ０（[RFC2671]）メッ
セージサイズ拡張とＤＯビット（[RFC3225]）をサポートし、そしてＤＮ
ＳＳＥＣサービスを供給するためにこの文書群で定義した資源レコードタ
イプとメッセージヘッダビットを使うことができます。
Security-Aware Stub Resolver: An entity acting in the role of a stub
resolver (defined in section 5.3.1 of [RFC1034]) that has enough
of an understanding the DNS security extensions defined in this
document set to provide additional services not available from a
security-oblivious stub resolver. Security-aware stub resolvers
may be either "validating" or "non-validating", depending on
whether the stub resolver attempts to verify DNSSEC signatures on
its own or trusts a friendly security-aware name server to do so.
See also validating stub resolver, non-validating stub resolver.
セキュリティの認識があるスタブリゾルバ：セキュリティの認識がないスタ
ブリゾルバから利用可能でない追加のサービスを供給する、この文書群で
定義されたＤＮＳセキュリティ拡張の理解をしている、（[RFC1034]の
５.３.１章で定義された）スタブリゾルバの役割をするエンティティー。
セキュリティの認識があるスタブリゾルバは、スタブリゾルバ自身がＤＮ
ＳＳＥＣ署名を実証しようと試みるか、あるいは友好的なセキュリティの
認識があるネームサーバに安心して任すかによって、「検証をする」か、
あるいは「非検証の」になります。検証をするスタブリゾルバ、非検証の
スタブリゾルバも見てください。
Security-Oblivious <anything>: An <anything> that is not
"security-aware".
セキュリティの認識がない＜何か＞：「セキュリティの認識がある」でない
＜何か＞。
Signed Zone: A zone whose RRsets are signed and that contains
properly constructed DNSKEY, Resource Record Signature (RRSIG),
Next Secure (NSEC), and (optionally) DS records.
署名されたゾーン：そこの資源レコード集合が署名され、正確に組み立てら
れたＤＮＳＫＥＹと資源レコード署名（ＲＲＳＩＧ）と次の安全（ＮＳ
ＥＣ）と（任意で）委任署名レコードを含む、ゾーン。
Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A
validating security-aware resolver uses this public key or hash as
a starting point for building the authentication chain to a signed
DNS response. In general, a validating resolver will have to
obtain the initial values of its trust anchors via some secure or
trusted means outside the DNS protocol. Presence of a trust
anchor also implies that the resolver should expect the zone to
which the trust anchor points to be signed.
信頼固定点：設定されたＤＮＳＫＥＹ資源レコードあるいはＤＮＳＫＥＹ資
源レコードの委任署名資源レコードのハッシュ。検証をするセキュリティ
の認識があるリゾルバは署名されたＤＮＳ回答の認証鎖を作る際に、公開
鍵あるいはハッシュを出発点として用います。一般に、検証をするリゾル
バがＤＮＳプロトコルの外で何か安全あるいは信頼できる手段で、信頼固
定点の最初の値を得なければならないでしょう。信頼固定点の存在は、リ
ゾルバが信頼固定点が示すゾーンが署名されることを期待するべきである
ことを、意味します。
Unsigned Zone: A zone that is not signed.
署名されていないゾーン：署名されていないゾーン。
Validating Security-Aware Stub Resolver: A security-aware resolver
that sends queries in recursive mode but that performs signature
validation on its own rather than just blindly trusting an
upstream security-aware recursive name server. See also
security-aware stub resolver, non-validating security-aware stub
resolver.
検証をするセキュリティの認識があるスタブリゾルバ：質問を再帰モードに
送り、やみくもに上流のセキュリティの認識がある再帰ネームサーバを信
頼するのではなく、自分自身で署名検証を行う、セキュリティの認識のあ
るリゾルバ。セキュリティの認識があるスタブリゾルバ、非検証のセキュ
リティの認識があるスタブリゾルバも見てください。
Validating Stub Resolver: A less tedious term for a validating
security-aware stub resolver.
検証をするスタブリゾルバ：検証をするセキュリティの認識があるスタブリ
ゾルバの短い言い方。
Zone Apex: Term used to describe the name at the child's side of a
zone cut. See also delegation point.
ゾーン頂上：ゾーン切断の子側の名前を記述する用語。委任点も見てくださ
い。
Zone Signing Key (ZSK): An authentication key that corresponds to a
private key used to sign a zone. Typically, a zone signing key
will be part of the same DNSKEY RRset as the key signing key whose
corresponding private key signs this DNSKEY RRset, but the zone
signing key is used for a slightly different purpose and may
differ from the key signing key in other ways, such as validity
lifetime. Designating an authentication key as a zone signing key
is purely an operational issue; DNSSEC validation does not
distinguish between zone signing keys and other DNSSEC
authentication keys, and it is possible to use a single key as
both a key signing key and a zone signing key. See also key
signing key.
ゾーン署名鍵（ＺＳＫ）：ゾーン署名に使う秘密鍵に対応する認証鍵。典型
的に、ゾーン署名鍵はあるＤＮＳＫＥＹ資源レコード集合の一部で、鍵署
名鍵に対応する秘密鍵がこのＤＮＳＫＥＹ資源レコード集合に署名をしま
す、しかしゾーン署名鍵はわずかに異なる目的に使われ、有効期間のよう
な他の部分が鍵署名鍵とは違うかもしれません。認証鍵をゾーン署名鍵と
指名することは純粋に運用上の問題です；ＤＮＳＳＥＣ検証はゾーン署名
鍵と他のＤＮＳＳＥＣ認証鍵を区別しません、そしてひとつの鍵を鍵署名
鍵とゾーン署名鍵両方として用いることは可能です。鍵署名鍵も見てくだ
さい。
3. Services Provided by DNS Security
3. ＤＮＳセキュリティによって供給されるサービス
The Domain Name System (DNS) security extensions provide origin
authentication and integrity assurance services for DNS data,
including mechanisms for authenticated denial of existence of DNS
data. These mechanisms are described below.
ドメインネームシステム（ＤＮＳ）セキュリティ拡張は、ＤＮＳデータの非
存在の証明メカニズムを含め、ＤＮＳデータ情報源認証と完全性を供給しま
す。これらのメカニズムは以下に記述されます。
These mechanisms require changes to the DNS protocol. DNSSEC adds
four new resource record types: Resource Record Signature (RRSIG),
DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure
(NSEC). It also adds two new message header bits: Checking Disabled
(CD) and Authenticated Data (AD). In order to support the larger DNS
message sizes that result from adding the DNSSEC RRs, DNSSEC also
requires EDNS0 support ([RFC2671]). Finally, DNSSEC requires support
for the DNSSEC OK (DO) EDNS header bit ([RFC3225]) so that a
security-aware resolver can indicate in its queries that it wishes to
receive DNSSEC RRs in response messages.
これらのメカニズムはＤＮＳプロトコルに対する変更を必要とします。ＤＮ
ＳＳＥＣは４つの新しい資源レコードタイプを加えます：資源レコード署名
（ＲＲＳＩＧ）、ＤＮＳ公開鍵（ＤＮＳＫＥＹ）、委任署名者（ＤＳ）、次
の安全（ＮＳＥＣ）。同じく２の新しいメッセージヘッダビットを加えます：
検査不要（ＣＤ）、検証済データ（ＡＤ）。ＤＮＳＳＥＣ資源レコードを加
えることで生じるより大きいＤＮＳメッセージサイズをサポートするために、
ＤＮＳＳＥＣはＥＤＮＳ０のサポートを必要とします（[RFC2671]）。
最終的に、ＤＮＳＳＥＣは、セキュリティの認識のあるリゾルバが、回答
メッセージでＤＮＳＳＥＣ資源レコードを受信することを、質問で望むこと
を示すことができるように、ＤＮＳＳＥＣ対応（ＤＯ）ＥＤＮＳヘッダビッ
ト（[RFC3225]）のサポートを必要とします。
These services protect against most of the threats to the Domain Name
System described in [RFC3833]. Please see Section 12 for a
discussion of the limitations of these extensions.
これらのサービスは[RFC3833]で記述されたドメインネームシステムに対す
る脅威の大部分からの保護をします。これらの拡張の限界の論議は１２章を
見てください。
3.1. Data Origin Authentication and Data Integrity
3.1. データ源認証]とデータ完全性
DNSSEC provides authentication by associating cryptographically
generated digital signatures with DNS RRsets. These digital
signatures are stored in a new resource record, the RRSIG record.
Typically, there will be a single private key that signs a zone's
data, but multiple keys are possible. For example, there may be keys
for each of several different digital signature algorithms. If a
security-aware resolver reliably learns a zone's public key, it can
authenticate that zone's signed data. An important DNSSEC concept is
that the key that signs a zone's data is associated with the zone
itself and not with the zone's authoritative name servers. (Public
keys for DNS transaction authentication mechanisms may also appear in
zones, as described in [RFC2931], but DNSSEC itself is concerned with
object security of DNS data, not channel security of DNS
transactions. The keys associated with transaction security may be
stored in different RR types. See [RFC3755] for details.)
ＤＮＳＳＥＣは暗号的に生成されたディジタル署名をＤＮＳ資源レコード集
合と結び付けることによって認証を供給します。これらのディジタル署名は
新しいリソースレコード、資源レコード署名レコードに保存されます。典型
的に、ゾーンのデータに署名する一つの秘密鍵があるでしょう、しかし多数
の鍵は可能です。例えば、いくつかの異なるディジタル署名アルゴリズムの
それぞれのために鍵があるかもしれません。もしセキュリティの認識がある
リゾルバが信頼できる方法でゾーンの公開鍵を学習するなら、リゾルバはそ
のゾーンの署名されたデータを検証することができます。重要なＤＮＳＳＥ
Ｃ概念はゾーンのデータに署名する鍵がゾーン自身に結びつけられて、ゾー
ンの正式なネームサーバと結び付けられていないということです。
（[RFC2931]で記述されるように、ＤＮＳ処理認証メカニズムのための公開鍵
もゾーンに現われるかもしれません、しかしＤＮＳＳＥＣ自身は、ＤＮＳ処
理のチャネルセキュリティではなく、ＤＮＳデータのオブジェクトセキュリ
ティに関連しています。処理セキュリティと結び付けられた鍵は異なる資源
レコードタイプに保存されるかもしれません。詳細は[RFC3755]を見てくださ
い。）
A security-aware resolver can learn a zone's public key either by
having a trust anchor configured into the resolver or by normal DNS
resolution. To allow the latter, public keys are stored in a new
type of resource record, the DNSKEY RR. Note that the private keys
used to sign zone data must be kept secure and should be stored
offline when practical. To discover a public key reliably via DNS
resolution, the target key itself has to be signed by either a
configured authentication key or another key that has been
authenticated previously. Security-aware resolvers authenticate zone
information by forming an authentication chain from a newly learned
public key back to a previously known authentication public key,
which in turn either has been configured into the resolver or must
have been learned and verified previously. Therefore, the resolver
must be configured with at least one trust anchor.
セキュリティの認識があるリゾルバは、信頼固定点をリゾルバに設定す
るか、あるいは標準的なＤＮＳ解決によって、ゾーンの公開鍵を学習す
ることができます。後者を許すために、公開鍵を新しいタイプの資源レ
コード、ＤＮＳＫＥＹ資源レコードに保存します。ゾーンデータの署名
に使用する秘密鍵は安全に保管されなければならず、可能なら、オフラ
インで保管されるべき事に注意してください。ＤＮＳ解決によって信頼
できるように公開鍵を発見するためには、目標の鍵自身が設定された認
証鍵か前に検証された他の鍵によって署名されなければなりません。セ
キュリティの認識があるリゾルバは、新たに学んだ公開鍵から既知の検
証された鍵への認証鎖を形成することでゾーン情報を検証します、既知
の鍵はリゾルバに設定されたか、以前に学び検証されてなければなりま
せん。それ故に、リゾルバは少なくとも１つの信頼固定点を設定しなく
てはなりません。
If the configured trust anchor is a zone signing key, then it will
authenticate the associated zone; if the configured key is a key
signing key, it will authenticate a zone signing key. If the
configured trust anchor is the hash of a key rather than the key
itself, the resolver may have to obtain the key via a DNS query. To
help security-aware resolvers establish this authentication chain,
security-aware name servers attempt to send the signature(s) needed
to authenticate a zone's public key(s) in the DNS reply message along
with the public key itself, provided that there is space available in
the message.
もし設定された信頼固定点がゾーン署名鍵であるなら、それは関連づけられ
たゾーンを認証するでしょう；もし設定された鍵が鍵署名鍵であるなら、そ
れはゾーン署名鍵を認証するでしょう。もし設定された信頼固定点が鍵自身
ではなく鍵のハッシュであるなら、リゾルバはＤＮＳ問合せによって鍵を得
なければならないかもしれません。セキュリティの認識があるリゾルバがこ
の認証鎖を生成するのを手伝うために、セキュリティの認識のあるネームサー
バはメッセージに利用可能な空間があるなら、公開鍵自身とともにゾーンの
公開鍵を認証するために必要な署名をＤＮＳ応答メッセージで送ろうと試み
ます。
The Delegation Signer (DS) RR type simplifies some of the
administrative tasks involved in signing delegations across
organizational boundaries. The DS RRset resides at a delegation
point in a parent zone and indicates the public key(s) corresponding
to the private key(s) used to self-sign the DNSKEY RRset at the
delegated child zone's apex. The administrator of the child zone, in
turn, uses the private key(s) corresponding to one or more of the
public keys in this DNSKEY RRset to sign the child zone's data. The
typical authentication chain is therefore
DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more
DS->DNSKEY subchains. DNSSEC permits more complex authentication
chains, such as additional layers of DNSKEY RRs signing other DNSKEY
RRs within a zone.
委任署名者（ＤＳ）資源レコードタイプは組織の境界を越える委任に関係す
る管理上の仕事を単純化します。委任署名資源レコード集合は親ゾーンの委
任点に存在し、そして委任された子ゾーンの頂上のＤＮＳＫＥＹ資源レコー
ド集合を自己署名する秘密鍵に対応している公開鍵を示します。子ゾーンの
管理者は、順に、子ゾーンのデータに署名するためＤＮＳＫＥＹ資源レコー
ド集合の公開鍵に対応する秘密鍵を使います。典型的な認証鎖はそれ故に、
"*"を０個以上の委任署名→ＤＮＳＫＥＹとしたとき、ＤＮＳＫＥＹ→[委任
署名→ＤＮＳＫＥＹ]*→資源レコード集合になります。ＤＮＳＳＥＣは、ゾー
ン内で他のＤＮＳＫＥＹ資源レコードを署名するＤＮＳＫＥＹ資源レコード
の追加の層のような、より複雑な認証鎖を認めます。
A security-aware resolver normally constructs this authentication
chain from the root of the DNS hierarchy down to the leaf zones based
on configured knowledge of the public key for the root. Local
policy, however, may also allow a security-aware resolver to use one
or more configured public keys (or hashes of public keys) other than
the root public key, may not provide configured knowledge of the root
public key, or may prevent the resolver from using particular public
keys for arbitrary reasons, even if those public keys are properly
signed with verifiable signatures. DNSSEC provides mechanisms by
which a security-aware resolver can determine whether an RRset's
signature is "valid" within the meaning of DNSSEC. In the final
analysis, however, authenticating both DNS keys and data is a matter
of local policy, which may extend or even override the protocol
extensions defined in this document set. See Section 5 for further
discussion.
セキュリティの認識があるリゾルバが、通常、設定されたルートの公開鍵の
知識に基づいて、ルートからリーフゾーンまでＤＮＳ階層構造に従って認証
鎖を作ります。しかしながらローカルポリシが、セキュリティの認識のある
リゾルバにルート以外の公開鍵（あるいは公開鍵のハッシュ）の設定を許す
かもしれず、あるいはルート公開鍵の知識を供給しないかもしれず、あるい
は任意の理由で公開鍵が検証可能な署名で正確に署名されるとしてもリゾル
バが特定の公開鍵を使うのを阻止してもよいです。ＤＮＳＳＥＣはセキュリ
ティの認識があるリゾルバが資源レコード集合の署名がＤＮＳＳＥＣの意味
の中で「有効」かどうか決定することができるメカニズムを供給します。し
かしながら、最終分析で、ＤＮＳ鍵とデータの認証はローカルポリシの問題
で、この文書群で定義されたプロトコル拡張を拡張したり変更したりするか
もしれません。これ以上の論議は５章を見てください。
3.2. Authenticating Name and Type Non-Existence
3.2. 名前とタイプの非実在証明
The security mechanism described in Section 3.1 only provides a way
to sign existing RRsets in a zone. The problem of providing negative
responses with the same level of authentication and integrity
requires the use of another new resource record type, the NSEC
record. The NSEC record allows a security-aware resolver to
authenticate a negative reply for either name or type non-existence
with the same mechanisms used to authenticate other DNS replies. Use
of NSEC records requires a canonical representation and ordering for
domain names in zones. Chains of NSEC records explicitly describe
the gaps, or "empty space", between domain names in a zone and list
the types of RRsets present at existing names. Each NSEC record is
signed and authenticated using the mechanisms described in Section
3.1.
３.１章で記述されたセキュリティメカニズムは、ゾーンの既存の資源レコー
ド集合に署名する方法を供給するだけです。認証と完全性を否定回答に対し
て提供する問題は、他の新しい資源レコードタイプ、ＮＳＥＣレコードの使
用を必要とします。ＮＳＥＣレコードはセキュリティの認識があるリゾルバ
に、他のＤＮＳ応答を本物と証明するために使ったのと同じメカニズムで、
名前あるいはタイプが非実在との否定的な応答を本物と証明することを許し
ます。ＮＳＥＣレコードの使用はゾーンのドメイン名の正規表現と順序を必
要とします。ＮＳＥＣレコードの連鎖がゾーンのドメイン名の間の明示的な
ギャップ、あるいは「空間」、を記述して、そして既存の名前に存在する資
源レコード集合タイプをリストアップします。それぞれのＮＳＥＣレコード
は署名され、そして３.１章で記述されたメカニズムを使って本物と証明され
ます。
4. Services Not Provided by DNS Security
4. ＤＮＳセキュリティで供給されないサービス
DNS was originally designed with the assumptions that the DNS will
return the same answer to any given query regardless of who may have
issued the query, and that all data in the DNS is thus visible.
Accordingly, DNSSEC is not designed to provide confidentiality,
access control lists, or other means of differentiating between
inquirers.
ＤＮＳは元々誰が問合せたかに関わらず同じ質問に同じ答を返す、それゆえ
ＤＮＳデータの全ては公開されているという仮定で元来設計されました。
したがって、ＤＮＳＳＥＣは機密性や、アクセス制御リストや、問合せ者を
区別する他の手段を供給する事は意図されません。
DNSSEC provides no protection against denial of service attacks.
Security-aware resolvers and security-aware name servers are
vulnerable to an additional class of denial of service attacks based
on cryptographic operations. Please see Section 12 for details.
ＤＮＳＳＥＣはサービス妨害攻撃に対して保護を供給しません。セキュリ
ティの認識のあるリゾルバとセキュリティの認識のあるネームサーバは暗号
演算に基づくサービス妨害攻撃の被害をうけやすいです。詳細は１２章を見
てください。
The DNS security extensions provide data and origin authentication
for DNS data. The mechanisms outlined above are not designed to
protect operations such as zone transfers and dynamic update
([RFC2136], [RFC3007]). Message authentication schemes described in
[RFC2845] and [RFC2931] address security operations that pertain to
these transactions.
ＤＮＳセキュリティ拡張はＤＮＳデータにデータ源認証を提供します。上で
概要を記述したメカニズムはゾーン転送や動的更新（[RFC2136]、[RFC3007]）
のようなオペレーションを守る設計はされていません。[RFC2845]や
[RFC2931]で記述されたメッセージ認証は、これらの処理に関係があるセキュ
リティオペレーションを扱います。
5. Scope of the DNSSEC Document Set and Last Hop Issues
5. ＤＮＳＳＥＣ文書群とと最終ホップ問題の範囲
The specification in this document set defines the behavior for zone
signers and security-aware name servers and resolvers in such a way
that the validating entities can unambiguously determine the state of
the data.
この文書群の仕様はゾーン署名者の行動と、データ検証をするエンティティー
が明瞭にデータの状態を決定することができるように、セキュリティの認識
のあるネームサーバとリゾルバを定義します。
A validating resolver can determine the following 4 states:
検証をするリゾルバが次の４状態を決定することができます：
Secure: The validating resolver has a trust anchor, has a chain of
trust, and is able to verify all the signatures in the response.
安全：検証をするリゾルバは信頼固定点を持ち、信頼連鎖を持ち、そして回答
のすべての署名を検証することが可能です。
Insecure: The validating resolver has a trust anchor, a chain of
trust, and, at some delegation point, signed proof of the
non-existence of a DS record. This indicates that subsequent
branches in the tree are provably insecure. A validating resolver
may have a local policy to mark parts of the domain space as
insecure.
不安定：検証をするリゾルバは信頼固定点と信頼の鎖を持ち、そしてある委
任点において、委任署名レコードの非実在の検証をしました。これは木で
の次の枝が検証上不安定であることを示します。検証をするリゾルバがド
メイン空間の一部が不安定であると印を付けるローカルポリシを持つかも
しれません。
Bogus: The validating resolver has a trust anchor and a secure
delegation indicating that subsidiary data is signed, but the
response fails to validate for some reason: missing signatures,
expired signatures, signatures with unsupported algorithms, data
missing that the relevant NSEC RR says should be present, and so
forth.
偽：検証をするリゾルバは信頼固定点と委任データが署名されてることを示
している安全な委任を持ちますが、回答は何以下の理由で無効です：署名
欠如、署名期限が切れ、サポートされていないアルゴリズム、適切なＮＳ
ＥＣ資源レコードなしのデータ欠如、など。
Indeterminate: There is no trust anchor that would indicate that a
specific portion of the tree is secure. This is the default
operation mode.
不確定：木の特定の部分で安全であることを示す信頼固定点がありません。
これはデフォルト運用モードです。
This specification only defines how security-aware name servers can
signal non-validating stub resolvers that data was found to be bogus
(using RCODE=2, "Server Failure"; see [RFC4035]).
この仕様書は、セキュリティの認識があるネームサーバが、非検証のスタブ
リゾルバに、データが偽であることがわかったと合図する方法を定義するだ
けです（RCODE=2、「サーバ失敗」を使って；[RFC4035]を見てください）。
There is a mechanism for security-aware name servers to signal
security-aware stub resolvers that data was found to be secure (using
the AD bit; see [RFC4035]).
セキュリティの認識があるネームサーバがセキュリティの認識があるスタブ
リゾルバにデータが安全であると合図するメカニズムがあります（ＡＤビッ
トを使って；[RFC4035]を見てください）。
This specification does not define a format for communicating why
responses were found to be bogus or marked as insecure. The current
signaling mechanism does not distinguish between indeterminate and
insecure states.
この仕様書は回答が偽である事や不安定であると印を付けられた理由を伝達
するフォーマットを定義しません。現在の信号メカニズムは不確定と不安定
な状態を区別しません。
A method for signaling advanced error codes and policy between a
security-aware stub resolver and security-aware recursive nameservers
is a topic for future work, as is the interface between a security-
aware resolver and the applications that use it. Note, however, that
the lack of the specification of such communication does not prohibit
deployment of signed zones or the deployment of security aware
recursive name servers that prohibit propagation of bogus data to the
applications.
セキュリティの認識があるスタブリゾルバとセキュリティの認識がある再帰
ネームサーバの間で、拡張エラーコードとポリシを示す方法は将来の仕事で、
セキュリティの認識があるリゾルバとアプリケーションの間のインタフェー
スも同様です。しかしながら、このような通信仕様の欠如が、署名されたゾー
ンの設置や、アプリケーションに偽データの利用を禁止するセキュリティの
認識がある再帰ネームサーバの設置を禁止しません。
6. Resolver Considerations
6. リゾルバの考察
A security-aware resolver has to be able to perform cryptographic
functions necessary to verify digital signatures using at least the
mandatory-to-implement algorithm(s). Security-aware resolvers must
also be capable of forming an authentication chain from a newly
learned zone back to an authentication key, as described above. This
process might require additional queries to intermediate DNS zones to
obtain necessary DNSKEY, DS, and RRSIG records. A security-aware
resolver should be configured with at least one trust anchor as the
starting point from which it will attempt to establish authentication
chains.
セキュリティの認識のあるリゾルバが少なくとも実装が必須のアルゴリズム
を使っているディジタル署名を検証するために必要な暗号の機能を実行する
ことが可能でなければなりません。セキュリティの認識のあるリゾルバは、
上記のように、新たに学んだゾーンから認証鍵への認証鎖を形成することが
できなくてはなりません。このプロセスは、必要なＤＮＳＫＥＹや委任署名
や資源レコード署名レコードを得るため、中間ＤＮＳゾーンへの追加の問合
せを要求するかもしれません。セキュリティの認識のあるリゾルバは、認証
鎖を生成する試みの出発点として少なくとも１つの信頼固定点を設定される
べきです。
If a security-aware resolver is separated from the relevant
authoritative name servers by a recursive name server or by any sort
of intermediary device that acts as a proxy for DNS, and if the
recursive name server or intermediary device is not security-aware,
the security-aware resolver may not be capable of operating in a
secure mode. For example, if a security-aware resolver's packets are
routed through a network address translation (NAT) device that
includes a DNS proxy that is not security-aware, the security-aware
resolver may find it difficult or impossible to obtain or validate
signed DNS data. The security-aware resolver may have a particularly
difficult time obtaining DS RRs in such a case, as DS RRs do not
follow the usual DNS rules for ownership of RRs at zone cuts. Note
that this problem is not specific to NATs: any security-oblivious DNS
software of any kind between the security-aware resolver and the
authoritative name servers will interfere with DNSSEC.
もしセキュリティの認識のあるリゾルバが、再帰ネームサーバやＤＮＳのプ
ロキシの役を務める中間装置により適切な正式なネームサーバと切り離され
ているなら、そしてもし再帰ネームサーバあるいは中間装置がセキュリティ
の認識がないなら、セキュリティの認識のあるリゾルバは安全モードで稼働
することができないかもしれません。例えば、もしセキュリティの認識のあ
るリゾルバのパケットがセキュリティの認識がないＤＮＳプロキシを含むネッ
トワークアドレス翻訳（ＮＡＴ）装置を通して送られるなら、セキュリティ
の認識があるリゾルバは署名されたＤＮＳデータを得るか、あるいは有効に
することが難しいか、あるいは不可能かもしれません。セキュリティの認識
があるリゾルバは、委任署名資源レコードがゾーン切断において資源レコー
ドの所有権の通常のＤＮＳ規則に従わないから、このような場合委任署名資
源レコードを得るは特に困難かもしれません。この問題はＮＡＴ固有ではあ
りません：セキュリティの認識のあるリゾルバと正式なネームサーバの間の、
セキュリティの認識がないＤＮＳソフトウェアは、どんな種類であってもＤ
ＮＳＳＥＣを妨害することに注意してください。
If a security-aware resolver must rely on an unsigned zone or a name
server that is not security aware, the resolver may not be able to
validate DNS responses and will need a local policy on whether to
accept unverified responses.
もしセキュリティの認識のあるリゾルバが署名されていないゾーンやセキュ
リティの認識のないネームサーバに頼らなくてはならないなら、リゾルバは
ＤＮＳ回答の妥当性検査が可能ではないかもしれず、そして、検証されてい
ない回答を受け入れるべきかどうかについて、ローカルポリシを必要とする
でしょう。
A security-aware resolver should take a signature's validation period
into consideration when determining the TTL of data in its cache, to
avoid caching signed data beyond the validity period of the
signature. However, it should also allow for the possibility that
the security-aware resolver's own clock is wrong. Thus, a
security-aware resolver that is part of a security-aware recursive
name server will have to pay careful attention to the DNSSEC
"checking disabled" (CD) bit ([RFC4034]). This is in order to avoid
blocking valid signatures from getting through to other
security-aware resolvers that are clients of this recursive name
server. See [RFC4035] for how a secure recursive server handles
queries with the CD bit set.
セキュリティの認識があるリゾルバは、キャッシュ上のデータのＴＴＬを決
めるときや、署名の有効時期を越えて署名されたデータをキャッシュするの
を避けると決定する時、署名の有効期間を考慮に入れるべきです。しかしな
がら、セキュリティの認識のあるリゾルバは自身の時計が間違っているとい
う可能性も考慮するべきです。それで、セキュリティの認識がある再帰ネー
ムサーバの一部であるセキュリティの認識があるリゾルバはＤＮＳＳＥＣ
「検査不要」（ＣＤ）ビット（[RFC4034]）に注意深い注意を払わなければな
らないでしょう。これはこの再帰ネームサーバのクライアントである他のセ
キュリティの認識のあるリゾルバに有効な署名が届かないことを避けるため
に必要です。安全な再帰サーバがＣＤビットが設定された問合せを処理する
方法は[RFC4035]を見てください。
7. Stub Resolver Considerations
7. スタブリゾルバの考察
Although not strictly required to do so by the protocol, most DNS
queries originate from stub resolvers. Stub resolvers, by
definition, are minimal DNS resolvers that use recursive query mode
to offload most of the work of DNS resolution to a recursive name
server. Given the widespread use of stub resolvers, the DNSSEC
architecture has to take stub resolvers into account, but the
security features needed in a stub resolver differ in some respects
from those needed in a security-aware iterative resolver.
厳密にプロトコルが要求するのではないけれども、たいていのＤＮＳの問合
せがスタブリゾルバから発生します。スタブリゾルバは、定義から、再帰ネー
ムサーバにＤＮＳ解決の仕事の大部分を任せるため再帰問合モードを使う最
小のＤＮＳリゾルバです。スタブリゾルバが広範囲に使われているので、Ｄ
ＮＳＳＥＣ体系はスタブリゾルバを考慮に入れなければなりません、しかし
スタブリゾルバで必要とされるセキュリティ昨日はセキュリティの認識があ
る再帰リゾルバで必要とされるものといくつかの点で異なります。
Even a security-oblivious stub resolver may benefit from DNSSEC if
the recursive name servers it uses are security-aware, but for the
stub resolver to place any real reliance on DNSSEC services, the stub
resolver must trust both the recursive name servers in question and
the communication channels between itself and those name servers.
The first of these issues is a local policy issue: in essence, a
security-oblivious stub resolver has no choice but to place itself at
the mercy of the recursive name servers that it uses, as it does not
perform DNSSEC validity checks on its own. The second issue requires
some kind of channel security mechanism; proper use of DNS
transaction authentication mechanisms such as SIG(0) ([RFC2931]) or
TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec.
Particular implementations may have other choices available, such as
operating system specific interprocess communication mechanisms.
Confidentiality is not needed for this channel, but data integrity
and message authentication are.
セキュリティの認識がないスタブリゾルバでさえ、もしそれが使う再帰ネー
ムサーバがセキュリティの認識があるなら、ＤＮＳＳＥＣから利益を得るか
もしれません、しかしスタブリゾルバがＤＮＳＳＥＣサービスに対する真の
信頼をするために、スタブリゾルバは再帰ネームサーバと、再帰ネームサー
バとの間の通信回線の両方を信頼しなくてはなりません。１番目のこ問題は
ローカルポリシ問題です：本質的に、セキュリティの認識がないスタブリゾ
ルバは、自分自身でＤＮＳＳＥＣ検証をしないので、再帰ネームサーバのな
すがままにする以外に選択肢を持っていません。２番目の問題は何らかの種
類の回線セキュリティメカニズムを必要とします；ＳＩＧ（０）（[RFC2931]）
や処理署名（[RFC2845]）のようなＤＮＳ取引認証メカニズムの適切な使用で
十分でしょう、ＩＰｓｅｃの適切な使用でもよいでしょう。特定の実装が、
オペレーティングシステム固有のプロセス間通信メカニズムのような、利用
可能な他の選択肢を持っているかもしれません。機密性がこの回線に必要と
されません、しかしデータ完全性とメッセージ認証は必要です。
A security-aware stub resolver that does trust both its recursive
name servers and its communication channel to them may choose to
examine the setting of the Authenticated Data (AD) bit in the message
header of the response messages it receives. The stub resolver can
use this flag bit as a hint to find out whether the recursive name
server was able to validate signatures for all of the data in the
Answer and Authority sections of the response.
再帰ネームサーバと通信回線の両方を信頼するセキュリティの認識があるス
タブリゾルバは、受け取る回答メッセージのメッセージヘッダの検証済デー
タ（ＡＤ）ビットの設定を調べることに決めてもよいです。スタブリゾルバ
は回答の解答部と権限部のデータのすべてで再帰ネームサーバが署名を検証
可能であったかどうか見つけだすためにこのビットフラグをヒントとして用
いることができます。
There is one more step that a security-aware stub resolver can take
if, for whatever reason, it is not able to establish a useful trust
relationship with the recursive name servers that it uses: it can
perform its own signature validation by setting the Checking Disabled
(CD) bit in its query messages. A validating stub resolver is thus
able to treat the DNSSEC signatures as trust relationships between
the zone administrators and the stub resolver itself.
もし、何かの理由で、再帰ネームサーバと有効な信頼関係を設立可能でない
なら、セキュリティの認識があるスタブリゾルバがとることができるもう１
つのステップがあります：問合で検査不要（ＣＤ）ビットを設定し、自分自
身で署名検証を行うことができます。検証をするスタブリゾルバは、ＤＮＳ
ＳＥＣ署名をゾーン管理者とスタブリゾルバ自身の信頼関係として取り扱う
ことが可能です。
8. Zone Considerations
8. ゾーンの考察
There are several differences between signed and unsigned zones. A
signed zone will contain additional security-related records (RRSIG,
DNSKEY, DS, and NSEC records). RRSIG and NSEC records may be
generated by a signing process prior to serving the zone. The RRSIG
records that accompany zone data have defined inception and
expiration times that establish a validity period for the signatures
and the zone data the signatures cover.
署名されたゾーンと、署名なしのゾーンの間にいくつかの相違があります。
署名されたゾーンは追加のセキュリティ関連のレコード（資源レコード署名
とＤＮＳＫＥＹと委任署名とＮＳＥＣレコード）を含んでいるでしょう。資
源レコード署名とＮＳＥＣレコードはゾーンの署名処理の過程で生成される
かもしれません。ゾーンデータに伴う資源レコード署名レコードは、署名と
署名がカバーするゾーンデータの有効期間を示す、定義された開始時間と終
了時間を含みます。
8.1. TTL Values vs. RRSIG Validity Period
8.1. ＴＴＬ値と資源レコード署名有効期間
It is important to note the distinction between a RRset's TTL value
and the signature validity period specified by the RRSIG RR covering
that RRset. DNSSEC does not change the definition or function of the
TTL value, which is intended to maintain database coherency in
caches. A caching resolver purges RRsets from its cache no later
than the end of the time period specified by the TTL fields of those
RRsets, regardless of whether the resolver is security-aware.
資源レコード集合のＴＴＬ値と、その資源レコード集合をカバーしている資
源レコード署名資源レコードでよって指定される署名有効期間、の区別に気
付くことは重要です。ＤＮＳＳＥＣはＴＴＬ値の定義や機能を変えず、そし
てこれはキャッシュのデータベース一貫性を持続するように意図されます。
キャッシュしているリゾルバは、リゾルバがセキュリティの認識があるかど
うかにかかわらず、その資源レコード集合のＴＴＬフィールドによって指定
された時期より前に資源レコード集合をキャッシュから追放します。
The inception and expiration fields in the RRSIG RR ([RFC4034]), on
the other hand, specify the time period during which the signature
can be used to validate the covered RRset. The signatures associated
with signed zone data are only valid for the time period specified by
these fields in the RRSIG RRs in question. TTL values cannot extend
the validity period of signed RRsets in a resolver's cache, but the
resolver may use the time remaining before expiration of the
signature validity period of a signed RRset as an upper bound for the
TTL of the signed RRset and its associated RRSIG RR in the resolver's
cache.
資源レコード署名資源レコードの開始と終了フィールド（[RFC4034]）は、他
方、署名がカバーする資源レコード集合の検証に使える時間を指定します。
署名されたゾーンデータと結び付けられた署名、その資源レコード署名資源
レコードのこれらのフィールドで指定された期間だけ有効です。ＴＴＬ値が
リゾルバのキャッシュの署名された資源レコード集合の有効期間を拡張する
ことはできませんが、しかしリゾルバは、署名された資源レコード集合と関
連する資源レコード署名資源レコードのＴＴＬに関して、資源レコード集合
の署名有効期間までの残りの時間をリゾルバのキャッシュの上限として使っ
てもよいです。
8.2. New Temporal Dependency Issues for Zones
8.2. ゾーンの新しい時間依存問題
Information in a signed zone has a temporal dependency that did not
exist in the original DNS protocol. A signed zone requires regular
maintenance to ensure that each RRset in the zone has a current valid
RRSIG RR. The signature validity period of an RRSIG RR is an
interval during which the signature for one particular signed RRset
can be considered valid, and the signatures of different RRsets in a
zone may expire at different times. Re-signing one or more RRsets in
a zone will change one or more RRSIG RRs, which will in turn require
incrementing the zone's SOA serial number to indicate that a zone
change has occurred and re-signing the SOA RRset itself. Thus,
re-signing any RRset in a zone may also trigger DNS NOTIFY messages
and zone transfer operations.
署名されたゾーンでの情報が元のＤＮＳプロトコルで存在しなかった時間依
存性を持っています。署名されたゾーンは、通常の維持管理で、ゾーンのそ
れぞれの資源レコード集合に対し現時点で有効な資源レコード署名資源レコー
ドがあるのを保証するように要求します。資源レコード署名資源レコードの
署名有効期間は、特定の署名された資源レコード集合の署名が有効と思われ
る期間です、そしてゾーンの異なる資源レコード集合の署名は異なる時刻に
期限が切れるかもしれません。ゾーンの資源レコード集合のいくつかを再署
名するといくつかの資源レコード署名資源レコードが変わり、そしてゾーン
変更が起こったことを示すためにゾーンのＳＯＡシリアル番号が増加され、
そしてＳＯＡ資源レコード集合自身を再署名する必要があるでしょう。それ
で、ゾーンでいくつかの資源レコード集合を再署名することは、ＤＮＳ通知
メッセージとゾーン転送オペレーションを引き起こすかもしれません。
9. Name Server Considerations
9. ネームサーバの考察
A security-aware name server should include the appropriate DNSSEC
records (RRSIG, DNSKEY, DS, and NSEC) in all responses to queries
from resolvers that have signaled their willingness to receive such
records via use of the DO bit in the EDNS header, subject to message
size limitations. Because inclusion of these DNSSEC RRs could easily
cause UDP message truncation and fallback to TCP, a security-aware
name server must also support the EDNS "sender's UDP payload"
mechanism.
セキュリティの認識のあるネームサーバは、全ての、ＥＤＮＳヘッダのＤＯ
ビットの使用により適切なＤＮＳＳＥＣレコードの受信を望む事を示し、メッ
セージサイズ制限の適用を受けた問合せに対する応答で、適切なＤＮＳＳＥ
Ｃレコード（資源レコード署名とＤＮＳＫＥＹと委任署名とＮＳＥＣ）を含
むべきです。これらのＤＮＳＳＥＣ資源レコードを含むことは容易にＵＤＰ
メッセージ切り詰めとＴＣＰ再問合せを起こすので、セキュリティの認識の
あるネームサーバがＥＤＮＳ「送信者ＵＤＰペイロード」メカニズムをサポー
トしなくてはなりません。
If possible, the private half of each DNSSEC key pair should be kept
offline, but this will not be possible for a zone for which DNS
dynamic update has been enabled. In the dynamic update case, the
primary master server for the zone will have to re-sign the zone when
it is updated, so the private key corresponding to the zone signing
key will have to be kept online. This is an example of a situation
in which the ability to separate the zone's DNSKEY RRset into zone
signing key(s) and key signing key(s) may be useful, as the key
signing key(s) in such a case can still be kept offline and may have
a longer useful lifetime than the zone signing key(s).
もし可能であるなら、それぞれのＤＮＳＳＥＣ鍵対の秘密鍵の部分はオフラ
インにしておかれるべきです、しかしこれはＤＮＳ動的更新が使用可能なゾー
ンでは可能ではないでしょう。動的更新の場合に、ゾーンの主マスターサー
バは、更新時に、ゾーンの再署名をしなければならないでしょう、それでゾー
ン署名鍵に対応している秘密鍵はオンラインにしておかれなければならない
でしょう。これはゾーンのＤＮＳＫＥＹ資源レコード集合をゾーン署名鍵と
鍵署名鍵に分けるのが有用でかもしれない例で、このような場合、鍵署名鍵
はオフラインにしててゾーン署名鍵より長い有効期間を持つかもしれません。
By itself, DNSSEC is not enough to protect the integrity of an entire
zone during zone transfer operations, as even a signed zone contains
some unsigned, nonauthoritative data if the zone has any children.
Therefore, zone maintenance operations will require some additional
mechanisms (most likely some form of channel security, such as TSIG,
SIG(0), or IPsec).
ゾーンに子がある場合、署名されたゾーンでに署名されていない正式でない
データがあるので、ＤＮＳＳＥＣだけではゾーン転送時のゾーン全体の完全
性を守るのに十分ではありません。それ故に、ゾーン管理オペレーションが
ある追加のメカニズムを必要とするでしょう（最も見込みが高いのは、処理
署名やＳＩＧ（０）やＩＰｓｅｃ等の何らかの形式の回線セキュリティです）。
10. DNS Security Document Family
10. ＤＮＳセキュリティ文書ファミリ
The DNSSEC document set can be partitioned into several main groups,
under the larger umbrella of the DNS base protocol documents.
ＤＮＳＳＥＣ文書群は、ＤＮＳベースプロトコル文書の下で、いくつかのグ
ループに分割できます。
The "DNSSEC protocol document set" refers to the three documents that
form the core of the DNS security extensions:
「ＤＮＳＳＥＣプロトコル文書群」はＤＮＳセキュリティ拡張の核心を形成
する３つの文書を参照します：
1. DNS Security Introduction and Requirements (this document)
1. ＤＮＳ安全の紹介と必要条件（この文書）
2. Resource Records for DNS Security Extensions [RFC4034]
2. ＤＮＳセキュリティ拡張のための資源レコード[RFC4034]
3. Protocol Modifications for the DNS Security Extensions [RFC4035]
3. ＤＮＳセキュリティ拡張のためのプロトコル修正[RFC4035]
Additionally, any document that would add to or change the core DNS
Security extensions would fall into this category. This includes any
future work on the communication between security-aware stub
resolvers and upstream security-aware recursive name servers.
さらに、ＤＮＳセキュリティ拡張の中心部を変更する文書はこのカテゴリー
に分類されるでしょう。これはセキュリティの認識があるスタブリゾルバと
上流のセキュリティの認識がある再帰ネームサーバの間の通信に関する未来
の仕事も含みます。
The "Digital Signature Algorithm Specification" document set refers
to the group of documents that describe how specific digital
signature algorithms should be implemented to fit the DNSSEC resource
record format. Each document in this set deals with a specific
digital signature algorithm. Please see the appendix on "DNSSEC
Algorithm and Digest Types" in [RFC4034] for a list of the algorithms
that were defined when this core specification was written.
「ディジタル署名アルゴリズム仕様」文書群は、どのように特定のディジタ
ル署名アルゴリズムを、ＤＮＳＳＥＣ資源レコードフォーマットに適合させ
て実装すべきであるか記述する文書のグループを示します。この文書群のそ
れぞれの文書は特定のディジタル署名アルゴリズムを扱います。この中心仕
様が書かれた時に定義されたアルゴリズムのリストは、[RFC4034]の「ＤＮＳ
ＳＥＣアルゴリズムとダイジェストタイプ」の付録を見てください。
The "Transaction Authentication Protocol" document set refers to the
group of documents that deal with DNS message authentication,
including secret key establishment and verification. Although not
strictly part of the DNSSEC specification as defined in this set of
documents, this group is noted because of its relationship to DNSSEC.
「処理認証プロトコル」文書群は、秘密鍵設立と証明を含む、ＤＮＳメッセー
ジ認証を扱う文書のグループを示します。この文書群で定義されるは厳密に
はＤＮＳＳＥＣ仕様書の一部ではないが、このグループはＤＮＳＳＥＣと関
係があります。
The final document set, "New Security Uses", refers to documents that
seek to use proposed DNS Security extensions for other security
related purposes. DNSSEC does not provide any direct security for
these new uses but may be used to support them. Documents that fall
in this category include those describing the use of DNS in the
storage and distribution of certificates ([RFC2538]).
最後の文書群、「新しいセキュリティの使用」、は他のセキュリティ関連の
目的のために提案されたＤＮＳセキュリティ拡張を使う文書を示します。Ｄ
ＮＳＳＥＣはこれらの新しい使用法に直接の安全を提供しませんが、それら
をサポートするために使われるかもしれません。この範疇に入る文書は、証
明書の保管と分配にＤＮＳを使用する記述をしている文書を含みます
（[RFC2538]）。
11. IANA Considerations
11. ＩＡＮＡの考慮
This overview document introduces no new IANA considerations. Please
see [RFC4034] for a complete review of the IANA considerations
introduced by DNSSEC.
この概観文書は新しいＩＡＮＡの考慮を導入しません。ＤＮＳＳＥＣによっ
て導入されたＩＡＮＡの考慮の完全な記述は[RFC4034]を見てください。
12. Security Considerations
12. セキュリティの考察
This document introduces DNS security extensions and describes the
document set that contains the new security records and DNS protocol
modifications. The extensions provide data origin authentication and
data integrity using digital signatures over resource record sets.
This section discusses the limitations of these extensions.
この文書はＤＮＳセキュリティ拡張を紹介して、そして新しいセキュリティ
レコードとＤＮＳプロトコル修正を含む文書群を記述します。拡張は資源レ
コード集合上にディジタル署名を使ったデータ源認証とデータ完全性を供給
します。この章はこれらの拡張の限界を論じます。
In order for a security-aware resolver to validate a DNS response,
all zones along the path from the trusted starting point to the zone
containing the response zones must be signed, and all name servers
and resolvers involved in the resolution process must be
security-aware, as defined in this document set. A security-aware
resolver cannot verify responses originating from an unsigned zone,
from a zone not served by a security-aware name server, or for any
DNS data that the resolver is only able to obtain through a recursive
name server that is not security-aware. If there is a break in the
authentication chain such that a security-aware resolver cannot
obtain and validate the authentication keys it needs, then the
security-aware resolver cannot validate the affected DNS data.
セキュリティの認識があるリゾルバがＤＮＳ回答の検証をするためには、信
頼された出発点から回答のゾーンまでのパスの全てのゾーンは署名されなく
てはなりません、そしてすべての解決処理に関係しているネームサーバとリ
ゾルバは、この文書群で定義されるように、セキュリティの認識がなければ
なりません。セキュリティの認識があるリゾルバは署名されていないゾーン
や、セキュリティの認識があるネームサーバによってサポートされたゾーン
でないゾーンや、リゾルバがセキュリティの認識がない再帰ネームサーバを
通してだけ得ることが可能なＤＮＳデータに起源している回答を検証するこ
とができません。もしセキュリティの認識があるリゾルバが、必要とする認
証鍵を得て検証することができない、認証鎖の隙間があるなら、セキュリティ
の認識があるリゾルバは与えられたＤＮＳデータの妥当性検査をすることが
できません。
This document briefly discusses other methods of adding security to a
DNS query, such as using a channel secured by IPsec or using a DNS
transaction authentication mechanism such as TSIG ([RFC2845]) or
SIG(0) ([RFC2931]), but transaction security is not part of DNSSEC
per se.
この文書は簡単に、ＩＰｓｅｃや、処理署名（[RFC2845]）やＳＩＧ（０）
（[RFC2931]）のようなＤＮＳ取引認証メカニズム、によって安全に保たれた
チャネルを使うかなどの、ＤＮＳの問合せにセキュリティを加える他の方法
を論じますが、処理セキュリティは本質的にＤＮＳＳＥＣの一部ではありま
せん。
A non-validating security-aware stub resolver, by definition, does
not perform DNSSEC signature validation on its own and thus is
vulnerable both to attacks on (and by) the security-aware recursive
name servers that perform these checks on its behalf and to attacks
on its communication with those security-aware recursive name
servers. Non-validating security-aware stub resolvers should use
some form of channel security to defend against the latter threat.
The only known defense against the former threat would be for the
security-aware stub resolver to perform its own signature validation,
at which point, again by definition, it would no longer be a
non-validating security-aware stub resolver.
非検証のセキュリティの認識があるスタブリゾルバは、定義から、自分自身
でＤＮＳＳＥＣ署名確証を行わず、従って代理として検査を実行するセキュ
リティの認識がある再帰ネームサーバへ（から）の攻撃や、セキュリティの
認識がある再帰ネームサーバとの通信回線への攻撃の被害をうけやすいです。
非検証のセキュリティの認識があるスタブリゾルバが後の脅威からの保護の
ためになんらかのチャンネルセキュリティを使うべきです。唯一の前の脅威
に対する既知の防衛策は、自分自身で署名確証を行うセキュリティの認識が
あるスタブリゾルバになる事で、そしてこの点で、再び定義によって、これ
はもう非検証のセキュリティの認識があるスタブリゾルバではありません。
DNSSEC does not protect against denial of service attacks. DNSSEC
makes DNS vulnerable to a new class of denial of service attacks
based on cryptographic operations against security-aware resolvers
and security-aware name servers, as an attacker can attempt to use
DNSSEC mechanisms to consume a victim's resources. This class of
attacks takes at least two forms. An attacker may be able to consume
resources in a security-aware resolver's signature validation code by
tampering with RRSIG RRs in response messages or by constructing
needlessly complex signature chains. An attacker may also be able to
consume resources in a security-aware name server that supports DNS
dynamic update, by sending a stream of update messages that force the
security-aware name server to re-sign some RRsets in the zone more
frequently than would otherwise be necessary.
ＤＮＳＳＥＣはサービス妨害攻撃からの保護をしません。ＤＮＳＳＥＣは、
セキュリティの認識のあるリゾルバとセキュリティの認識のあるネームサー
バに対して暗号のオペレーションに基づいたサービス妨害攻撃の新しい種類
の被害を作り、攻撃者が犠牲者の資源を消費するためにＤＮＳＳＥＣメカニ
ズムを使おうと試みることができます。この種類の攻撃は少なくとも２つの
形式をとります。攻撃者が回答メッセージの資源レコード署名資源レコード
を不法に変更することで、あるいは不必要に複雑な署名鎖を建設することに
よって、セキュリティの認識のあるリゾルバの署名検証プログラムで資源を
消費することが可能かもしれません。攻撃者が、セキュリティの認識のある
ネームサーバがゾーンのいくつかの資源レコード集合の再署名を必要以上に
しばしば強制するように、連続した更新メッセージを送ることで、ＤＮＳ動
的更新をサポートするセキュリティの認識のあるネームサーバの資源を消費
することが可能もしれません。
Due to a deliberate design choice, DNSSEC does not provide
confidentiality.
故意の設計上の選択としてＤＮＳＳＥＣは機密性を供給しません。
DNSSEC introduces the ability for a hostile party to enumerate all
the names in a zone by following the NSEC chain. NSEC RRs assert
which names do not exist in a zone by linking from existing name to
existing name along a canonical ordering of all the names within a
zone. Thus, an attacker can query these NSEC RRs in sequence to
obtain all the names in a zone. Although this is not an attack on
the DNS itself, it could allow an attacker to map network hosts or
other resources by enumerating the contents of a zone.
ＤＮＳＳＥＣは敵対的な関係者がＮＳＥＣ鎖をたどる事でゾーンのすべての
名前を得る事ができる能力を導入します。ＮＳＥＣ資源レコードは、ゾーン
の中のすべての名前を正規順で結合することで、名前が存在しないと断言し
ます。それで、攻撃者はゾーンですべての名前を得るために、これらのＮＳ
ＥＣ資源レコードを順番に問合せすることができます。これはＤＮＳ自身に
対する攻撃ではないが、攻撃者がゾーンの内容を列挙することでネットワー
クホストや他の資源の地図を得ることを許します。
DNSSEC introduces significant additional complexity to the DNS and
thus introduces many new opportunities for implementation bugs and
misconfigured zones. In particular, enabling DNSSEC signature
validation in a resolver may cause entire legitimate zones to become
effectively unreachable due to DNSSEC configuration errors or bugs.
ＤＮＳＳＥＣはＤＮＳに重要な追加の複雑さを導入し、それで新しい実装バ
グの可能性と、設定誤りのゾーンを作ります。特に、リゾルバでＤＮＳＳＥ
Ｃ署名検証をすることは、ＤＮＳＳＥＣ設定エラーやバグのため全部の正規
のゾーンを到達不可能にするかもしれません。
DNSSEC does not protect against tampering with unsigned zone data.
Non-authoritative data at zone cuts (glue and NS RRs in the parent
zone) are not signed. This does not pose a problem when validating
the authentication chain, but it does mean that the non-authoritative
data itself is vulnerable to tampering during zone transfer
operations. Thus, while DNSSEC can provide data origin
authentication and data integrity for RRsets, it cannot do so for
zones, and other mechanisms (such as TSIG, SIG(0), or IPsec) must be
used to protect zone transfer operations.
ＤＮＳＳＥＣは署名されていないゾーンデータを不法に変更することに対す
る保護をしません。ゾーン切断での正式でないデータ（親ゾーンの接着用資
源レコードとネームサーバ資源レコード）が署名されません。これは、認証
鎖の妥当検査で問題を起こしませんが、正式でないデータ自体がゾーン転送
オペレーションの間に不法に変更されやすいことを意味します。ＤＮＳＳＥ
Ｃが資源レコード集合にデータ源認証とデータ完全性を提供することができ
るのに対して、ゾーンに対してはできません、そしてゾーン転送オペレーショ
ンを守るために（処理署名やＳＩＧ（０）やＩＰｓｅｃのような）他のメカ
ニズムを使わなくてはなりません。
Please see [RFC4034] and [RFC4035] for additional security
considerations.
追加のセキュリティの考察として[RFC4034]と[RFC4035]を見てください。
13. Acknowledgements
13. 謝辞
This document was created from the input and ideas of the members of
the DNS Extensions Working Group. Although explicitly listing
everyone who has contributed during the decade in which DNSSEC has
been under development would be impossible, the editors would
particularly like to thank the following people for their
contributions to and comments on this document set: Jaap Akkerhuis,
Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein,
David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald
Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson,
Gilles Guette, Andreas Gustafsson, Jun-ichiro Itojun Hagino, Phillip
Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson,
Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon
Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters,
Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis,
Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ
Mundy, Thomas Narten, Mans Nilsson, Masataka Ohta, Mike Patton, Rob
Payne, Jim Reid, Michael Richardson, Erik Rozendaal, Marcos Sanz,
Pekka Savola, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler,
Brian Wellington, and Suzanne Woolf.
このドキュメントはＤＮＳ拡張作業班のメンバのインプットと考えから作ら
れました。明示的にＤＮＳＳＥＣ開発の１０年間に貢献した全員をリストアッ
プすることは不可能であるが、編集者は特にこの文書群への貢献とコメント
に対して次の人々に感謝します：Jaap Akkerhuis、Mark Andrews、
Derek Atkins、Roy Badami、Alan Barrett、Dan Bernstein、David Blacka、
Len Budney、Randy Bush、Francis Dupont、Donald Eastlake、Robert Elz、
Miek Gieben、Michael Graff、Olafur Gudmundsson、Gilles Guette、
Andreas Gustafsson、Jun-ichiro Itojun Hagino、Phillip Hallam-Baker、
Bob Halley、Ted Hardie、Walter Howard、Greg Hudson、Christian Huitema、
Johan Ihren、Stephen Jacob、Jelte Jansen、Simon Josefsson、
Andris Kalnozols、Peter Koch、Olaf Kolkman、Mark Kosters、
Suresh Krishnaswamy、Ben Laurie、David Lawrence、Ted Lemon、Ed Lewis、
Ted Lindgreen、Josh Littlefield、Rip Loomis、Bill Manning、
Russ Mundy、Thomas Narten、Mans Nilsson、Masataka Ohta、Mike Patton、
Rob Payne、Jim Reid、Michael Richardson、Erik Rozendaal、Marcos Sanz、
Pekka Savola、Jakob Schlyter、Mike StJohns、Paul Vixie、Sam Weiler、
Brian Wellington、Suzanne Woolf
No doubt the above list is incomplete. We apologize to anyone we
left out.
上記のリストが不完全であることに疑いがありません。我々は書き漏らした
誰にも謝ります。
14. References
14. 参考文献
14.1. Normative References
14.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.
[RFC2535] Eastlake 3rd, 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.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for DNS Security Extensions", RFC
4034, 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.
14.2. Informative References
14.2. 有益な参考文献
[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 3rd, D. and O. Gudmundsson, "Storing Certificates
in the Domain Name System (DNS)", RFC 2538, March 1999.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC2931] Eastlake 3rd, 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.
[RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
Authenticated Data (AD) bit", RFC 3655, November 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.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004.
[RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
RDATA Format", RFC 3845, August 2004.
Authors' Addresses
著者のアドレス
Roy Arends
Telematica Instituut
Brouwerijstraat 1
7523 XC Enschede
NL
EMail: roy.arends@telin.nl
Rob Austein
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
USA
EMail: sra@isc.org
Matt Larson
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA 20166-6503
USA
EMail: mlarson@verisign.com
Dan Massey
Colorado State University
Department of Computer Science
Fort Collins, CO 80523-1873
EMail: massey@cs.colostate.edu
Scott Rose
National Institute for Standards and Technology
100 Bureau Drive
Gaithersburg, MD 20899-8920
USA
EMail: scott.rose@nist.gov
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (2005).
著作権（Ｃ）インターネット学会（２００５）。
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そして
この中に明らかにされる以外は著者がすべての権利を維持します。
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
者が代表するか貢献者を後援する組織（もしあれば）とインターネット学会
とインターネット技術標準化タスクフォースは、明確にも暗黙にも、この情
報の使用が権利の侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、全ての保証を拒否します。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、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.
ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
めます。どうかietf-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。