RFC4033 DNSSEC 翻译

本文转载自：http://blog.neu.edu.cn/jlu_wolfsky/archives/16

 

-------------------------------------------------------------------------------------------

————————————————————————————————–

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.

dnssec为dns系统添加了端点鉴别和数据完整性功能。这份文档介绍这些扩展，描述这些功能和限制。这份文档也讨论dnssec提供或者不提供的功能。最后，文档描述了有关dnssec各个文档之间的关系。

1. 简介. . . . . . . . . . . . . . . . . . . . . . . . 2
2. 重要名词的定义 . . . . . . . . . . . 3
3. dns安全特性提供的服务. . . . . . . . . . . . . 7
3.1. 数据源鉴别和数据完整性 . . . . 7
3.2. 授权域名和‘不存在’类型. . . . . . 9
4. dns安全特性不提供的服务 . . . . . . . . . . 9
5. DNSSEC文档的范围和最后一跳问题Scope of the DNSSEC Document Set and Last Hop Issues . . . . 9
6. 有关解析器的考虑. . . . . . . . . . . . . . . . . . 10
7. 有关存根解析器的考虑 . . . . . . . . . . . . . . . 11
8. 有关‘域’的考虑. . . . . . . . . . . . . . . . . . . . 12
8.1. TTL的值和RRSIG的有效期. . . . . . . . . 13
8.2. 新的暂时的域的依赖问题 . . . . . . . 13
9. 有关域名服务器的考虑 . . . . . . . . . . . . . . . . . 13
10. dnssec文档家族. . . . . . . . . . . . . . . . 14
11. IANA 的考虑 . . . . . . . . . . . . . . . . . . . . 15
12. 安全考虑 . . . . . . . . . . . . . . . . . . 15
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.1. Normative References . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . 18
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 21

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.

之前不解释。。。这些安全扩展引入了一系列的新的RR记录类型和对现有的dns协议的扩展，这些新的记录和协议的修改在这片文档中没有完全描述，详见第10部分中列出的文档家族中。文档的3和4部分更详细的描述了dnssec的能力和限制。第5部分描述了文档的范围。6，7，8，9描述了安全扩展对解析器，存根解析器，域和域名服务器的影响。

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.

不解释。。。。

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.

dnssec提供了端点鉴别和完整性鉴别，和公钥发布。这些扩展并不提供加密。

2.Definitions of Important DNSSEC Terms
重要的dnssec词汇的定义
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.”
授权链：一个由dns公钥和代理rrset交替组成的序列，dnskey rr用来验证包含ds rr的签名，使得ds rr能够被授权。ds rr包含着另一个dnskey rr 的散列值，这个新的dnskey rr如果和ds rr的散列值相同则被授权。这个新的dnskey rr反过来授权另一个dnskey rret ，反过来，一些dnskey rr可以用来授权另外的ds rr，这样延续下去直到授权链以一个携带着由其对应私钥签署的数据的公钥结束。例如，根节点dnskey rrset可以被用来授权example域的ds rrset。example域的ds rrset携带着一个与某个example域的dnskey rrset匹配的散列值，这个dnskey对应的私钥负责签署example域的rrset。example的私钥部分用来签署例如www.example的数据记录或者subzone.example 的ds rrset。

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.
授权密钥：一个被安全解析器验证过的可以用来授权数据的公钥。安全解析器可以通过三种方式获得授权密钥。一，解析器原来就被配置为知道其中至少一个公钥。配置信息可以是公钥本身，也可以是贮存在ds rr（信任锚）里面的公钥的散列值。二，解析器可能使用授权公钥来验证一个ds rr 和这个DS RR 指向的DNSKEY RR。三，解析器可能断定一个新的公钥已经被一个私钥（与这个私钥配对的公钥是解析器已经验证过的）签名。注意当解析器决定是否授权一个新的公钥时，必须总是受本地策略的指导，即使本地策略仅仅是授权任何解析器能够识别其签名的所有公钥。
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.
可授权RRset，在某个特定区的上下文中，当且仅当RRSET的所有者位于区顶端之下的名空间的子域中或者在与子域分界线之上时，这些RRSET才是可授权的。区顶端的所有rrsets都是可授权的，除了属于这个域的父域的rrset。这些rrset可能包括DS RRSET,与这个DS RRSET 相关的NSEC RRSET（属于父区），和与这些set相关的RRSIG RRS，这些都是在父区授权的。

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节点。

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.

安全孤岛：用来描述一个已签名并已被代理但并没有到达代理父区的信任链的区。也就是说，在它的代理父区一侧并没有包含这个区的dnskey的散列值的ds rr。一个安全孤岛由安全域名服务器伺服，可以提供到代理子区的信任链。安全岛的应答只有当它的权威密钥能够被验证（通过dns协议外的某些安全方法）时才能够被验证。

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.

密钥签名密钥（KSK），一个与私钥配对的授权密钥，用来为某一特定的区的其他授权密钥签名。一般来说，与ksk相关的私钥会签署一个zsk（区签名密钥），这个区签名密钥也有配对的私钥用来签署其他区的数据。本地策略可能要求zsk（区签名密钥）被较频繁的更换，而ksk会有更长时间的有效时间以提供更稳定的到该区的安全入口。将授权密钥作为ksk纯粹是操作上的考虑：dnssec的验证并不区分ksk和其他的dnssec授权密钥，将单一的密钥及作为ksk也作为zsk也是可行的。Ksk在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.

不做验证的安全存根解析器：一个具有安全意识的存根解析器，依赖一个或者更多的安全递归服务器来完成本文档中讨论的大部分任务。特别的，一个不做验证的安全存根解析器是一个发送dns报文，接受dns应答，并且能够建立适当的到安全递归域名服务器（能够代为安全存根解析器提供这些服务）的安全通道的实体。参见安全存根解析器，可做验证的安全存根解析器。

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 2.4部分中定义）的实体，理解本文档中定义的dns安全扩展。贴别的，一个安全域名服务器是一个接收dns查询报文，发送dns应答报文，支持EDNS0(RFC2671)报文大小扩展和DO位（RFC3225）并且支持本文档中定义的RR类型。

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 2.4部分定义）职责，能够理解本文档中定义的dns安全扩展的实体。贴别的，一个安全解析器是一个发送dns查询报文，接受dns应答报文，支持EDNS0(RFC2671)报文大小扩展和DO位（RFC3225）并且能够使用本文档中定义的用来提供dnssec服务的RR类型
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.
安全存根解析器：一个履行存根解析器职责的，能够充分理解本文档中定义的dns安全扩展的实体。安全存根解析器可以是”做验证的”和”不做验证的”，由存根解析器是否尝试自己去验证dnssec签名还是依赖一个友好的安全域名服务器来决定。参见验证存根解析器和非验证存根解析器。

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.
签名区：一个所有的rrsets都已经签名并且包括正常构建的DNSKEY,RRSIG,NSEC,(可能包括)DS记录的区。

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.
信任锚：一个配置过得DNSKEY RR或者DNSKEY RR的散列值（DS RR）。一个做验证的安全解析器使用这个公钥或者散列值作为建立到一个签名dns应答的信任链的起始点。总体上，一个做验证的解析器应该通过某种dns协议以外的安全或者可信任的方法获得信任锚的初始值。信任锚的存在也暗示解析器应该期待信任点指向的区应该是签名的。
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.
区签名密钥（zsk）：一个与签署区的私钥配对的验证密钥。典型的，一个区签名密钥（zsk）是作为与签署这DNSKEY RRset的私钥配对的ksk的DNSKEY RRSET的一部分。但是zsk在使用上与ksk有稍微不同的目的，可能在别的方面与ksk不同，比如有效时间。设计一个验证密钥作为zsk仅仅是一个操作上的问题。DNSSEC验证并不区分zsk和其他的DNSSEC验证密钥，将单一的密钥既作为ksk也作为zsk也是可能的。参见ksk。

3. Services Provided by DNS Security
dns 安全扩展提供的服务
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.
Dnss安全扩展提供端点鉴别和dns数据完整性服务，包括能够鉴别dns数据的不存在性。这些方法将在下面讨论。
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.

这些方法需要对原来的dns协议进行修改。Dnssec添加了四种新的资源记录类型：资源记录签名（RRSIG）,DNS 公钥（DNSKEY）,代理签名（DS）,下一个安全记录（NSEC）。同时添加两种新的报文首部位：关闭检查（CD），已验证的信息（AD）。为了支持由于添加了DNSSEC RR而变得更大的dns报文，DNSSEC同时需要EDNS0的支持。最终，DNSSEC需要DNSSEC OK(DO) EDNS 首部位（RFC3225）使得一个安全解析器可以在查询报文中指出期待在应答报文中接收到DNSSEC RRs。

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]中描述的对dns的大部分威胁。关于这些安全扩展的局限的讨论请参见第12章

3.1. Data Origin Authentication and Data Integrity
数据端点鉴别和数据完整性

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.)

dnssec通过将加密的数字签名和DNS RRsets结合起来提供验证。这些数字签名春尊在一种新的资源记录（RRSIG记录）中。通常，会有一个用来签署区数据的私钥，但是多个私钥也是可能的。例如，可能不同的数字签名算法会有不同的密钥。当一个安全解析器确信自己知道了一个区的公钥，他就可以验证这个区签名过的数据。一个重要的DNSSEC概念是签署区数据的密钥跟区本身有关而不是跟区的权威服务器有关。（用来dns事务验证的公钥（RFC2931）也可能在区数据中出现，但是DNSSEC本身只关心DNS数据的安全性而不是dns事务的安全性。与事务安全相关的密钥可能存贮在不同的RR类型中。详情参见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

Arends, et al. Standards Track [Page 7]

RFC 4033 DNS Security Introduction and Requirements March 2005
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.

一个安全解析器可以通过配置到解析器中的信任锚或者通过正常的DNS解析获得一个区的公钥。为了实现后一种功能，公钥被存贮在一种新的RR类型中，DNSKEY RR。注意用来签署区属据的私钥必须确保安全在实践中应该被离线保管。为了通过DNS解析得到一个公钥，目标公钥本身必须被一个配置过的授权密钥或别的之前已经被授权的密钥授权。安全解析器通过组织一条从新知道的公钥回溯到之前已经验证的公钥（已经被配置在解析器中或者之前已经被验证）的授权链来验证区信息。因此，解析器必须被配置至少一条信任锚。

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.

如果配置的信任锚是一个区签名密钥（zsk），那么它可以用来验证相关的区；如果配置的密钥是一个‘密钥签名密钥’（ksk），那么它可以用来验证一个区签名密钥（zsk）。当配置的信任锚是一个密钥的散列值而不是密钥本身，那么解析器可能不得不通过DNS查询来获得密钥。为了帮助安全解析器建立信任链，在报文空间允许的情况下，安全域名服务器尝试在发送区公钥的同时一并发送用来验证应答报文中的区公钥的签名记录。

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.

代理签名者（DS RR类型）简化了在签署组织边界代理中的管理上的任务。DS RRset位于一个父区的代理点处，暗示与用来签署子区的DNSKEY RRset的私钥配对的公钥的存在。反之，子区的管理员，使用与这个DNSKEY RR集合中的公钥配对的私钥来签署子区的数据。典型的信任链因此是： DNSKEY->[DS->DNSKEY]*->RRset,*代表0或者是子链的重复。DNSSEC允许更复杂的信任链，比如额外的签署其他DNSKEY的DNSKEY RR层。

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.

一个安全解析器通常会根据已配置的根的公钥从dns树状结构的根部自上而下的构建信任链。本地策略，也可以允许安全解析器使用一个或更多的公钥或者公钥的散列值（不提供根区公钥的配置信息）而不是根的公钥，或者因为任意原因阻止解析器使用某一特定公钥，即使这一公钥是合法验证过的。DNSSEC提供安全解析器判定某一RRSet是否是合法的算法。然而最终验证dnskey或者数据是本地策略（可能会延伸甚至重写本文档集合中的定义）。进一步的讨论参见第5部分。
Arends, et al. Standards Track [Page 8]

RFC 4033 DNS Security Introduction and Requirements March 2005
3.2. Authenticating Name and Type Non-Existence
验证名称和‘类型不存在’
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.
3.1部分中的安全方法只提供了签署一个区中存在的RRset。为否定应答提供同等级的验证和完整性需要一种新的资源记录类型：NSEC记录。NSEC记录允许安全解析器同过和验证其他DNS应答一样的方法来验证一个域名或者不存在类型的否定应答。使用NSEC记录需要区内的域名按照范式表达和排序。NSEc记录链明确的描述区中存在的域名和RRset的类型表之间的缝隙。每个NSEC记录都要用3.1部分中描述的方法签名。
4. Services Not Provided by DNS Security
DNS 安全扩展不提供的服务
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.
DNS起初被设计成为无论谁提交某一特定查询，dns都会返回相同的记录，dns中所有的信息都是可见的。同时，DNSSEC当初并未设计提供加密服务，访问控制列表，或者其他的区别对待查询者的方法。
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.
DNSSEC不能为拒绝服务攻击提供保护。安全解析器和安全域名服务器对于基于密码的拒绝服务攻击是脆弱的。请详见第12部分。
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.
DNS安全扩展提供数据和端点鉴别。上面列出的方法并不是用来保护区传送或是动态更新（RFC2136,RFC3007）。RFC2845和RFC2931中提供的报文验证提到了适用于这些事务的安全操作。
5. Scope of the DNSSEC Document Set and Last Hop Issues
DNSSEC文档集的范围和‘最后一跳’问题
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:
一个验证解析器可以区分一下4种状态：
Secure: The validating resolver has a trust anchor, has a chain of
trust, and is able to verify all the signatures in the response.
安全：验证解析器，有一个信任锚，一跳信任链，而且能够验证应答报文中的所有签名。
Arends, et al. Standards Track [Page 9]

RFC 4033 DNS Security Introduction and Requirements March 2005
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.
不安全：验证解析器有一条信任锚，一跳信任链，而且在某个代理点，有签名的证据表示某个DS记录的不存在。这表示树的某个分支可能是不安全的。一个验证解析器可以有自己的本地策略来将某个域空间标识为不安全的。
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.
伪造的：验证解析器有一个信任锚，和一个表示附属信息已经签名的安全代理，然而应答因为以下原因失败了：丢失签名，过期的签名，不支持算法的签名，NSEC记录表示应该存在的数据却丢失，等等。
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]).
安全域名服务器通知安全存根服务器数据是安全的（使用AD位，见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
解析器方面的考虑
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
安全解析器必须要部署能够验证至少一种算法产生的签名的加密功能.安全解析器必须能够建立从新获得的区回溯到一个验证密钥的验证链。这个过程必须依赖额外的到中间dns区的查询来获得必须的dns密钥，ds记录和rrsig签名。
Arends, et al. Standards Track [Page 10]

RFC 4033 DNS Security Introduction and Requirements March 2005
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.
如果一个安全解析器被一个递归域名服务器或者其他扮演dns代理的设备隔开，并且这个递归服务器或者这个直接设备不是具备安全功能的，这个安全解析器可能无法在安全模式下运行。例如，如果一个安全解析器的包路由过一个包含不具备安全功能的dns协议的nat设备，安全解析器可能很难或者不可能获得或验证已签名的dns信息。安全解析器在这种情况下可能很难获得ds记录，因为ds记录并不遵循通常的在区分界处的rr归属规则。注意这个我呢提并不是nat设备特有的：任何在安全解析器和安全域名服务器之间的无安全意识的dns软件都会干扰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.
如果一个安全解析器必须依赖一个未签名区或者一个不是安全的域名服务器，这个解析器可能无法验证dns应答，需要本地策略来决定是否接受未验证的应答。
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.
当决定缓存中的的数据的TTL值的时候，安全解析器必须考虑到签名的有效期。然而，可能存在的情况是安全解析器自己的时钟是错误的。因此，一个安全递归服务器内一侧的安全解析器必须仔细检查DNSSEC中的”检查关闭”（CD）位（RFC4034）.这是为了避免阻塞通过该递归服务器到客户端一侧的安全解析器。关于安全递归服务器如何处理带CD位的查询参见RFC4035。
7. Stub Resolver Considerations
有关存根解析器的考虑
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
大多数的dns查询都是从存根解析器上发出的，虽然dns协议并不严格要求这样做。存根解析器，根据定义，是一个使用递归查询模式来将大部分的dns解析任务转交给递归服务器的最小的dns解析器。由于存根解析器的广泛使用，
Arends, et al. Standards Track [Page 11]

RFC 4033 DNS Security Introduction and Requirements March 2005
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.
DNSSEC架构不得不考虑存根解析器，但是存根解析器中的安全特性在某些方面和安全迭代解析器不太相同。
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.
如果递归服务器是安全的，那么使用它的无安全意识的存根解析器也可以因此而受益。但是存根解析器若是要依赖DNSSEC服务，它必须在相信递归服务器的查询结果和它和域名服务器之间的通信通道。首要的问题是本地策略问题：一个无安全意识的存根解析器必须依赖于它使用的递归域名服务器，因为它本身并不能进行DNSSEC合法性验证。第二个问题需要某种信道安全方法；使用像SIG(0)（RFC2931）或者TSIG（RFC2845）这样的DNS事务验证方法，或者合理的使用IPsec。特别的部署可能有其他的方法，比如操作系统内部的通信方法。对于这个信道来说，可信不是必须的，但是数据完整性和报文鉴别却是。
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.
既信任递归服务器又信任通信信道的安全存根解析器可能会检测报文头部中的”已验证信息”AD位。存根解析器可以使用这个标志位作为线索来判断递归服务器是否能够对应答报文中的应答和授权字段的签名进行验证。
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.
如果由于某种原因，一个安全存根解析器无法建立与递归服务器可信任的关系，那么需要更进一步的方法：它可以在查询报文中设置”关闭检查”来自己进行签名验证。一个验证存根解析器因此将DNSSEC签名作为区管理者和解析器自己之间的信任关系（注：无视中间的递归服务器）。
8. Zone Considerations
有关区的考虑：
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.
是否签名的区之间存在一些差别。签名能够的区包含额外的与安全相关的记录（RRSIG,DNSKEY,DS,NSEC记录）。RRSIG和NSEC记录可能由签名进程生成。与区数据相关的RRSIG记录定义了开始和过期时间，为签名和签名覆盖的数据规定了有效期。
Arends, et al. Standards Track [Page 12]

RFC 4033 DNS Security Introduction and Requirements March 2005
8.1. TTL Values vs. RRSIG Validity Period
TTL值和RRSIG有效期
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.
理解一个RR集合的TTL值和覆盖这个RR的RRSIG所确定的签名有效期之间的区别是很重要的。DNSSEC并不改变TTL原来的定义，TTL仍然用来维护缓存中的数据库一致性。一个缓存解析器需要在TTL之前将RRset从缓存中擦除，而不必考虑解析器是不是安全的。
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.
另一方面，RRSIG RR中的插入时间和过期时间明确了签名可用来验证覆盖的RRSET的有效期。与签名的区信息关联的签名旨在这些字段规定的有效期内才是合法的。TTL的值并不能延长签名的RRsets在解析器缓存中的有效期，但是解析器可以使用签名过期前剩余的时间来作为签名RRset和与其相关连的RRSIG RR的TTL的上限。
8.2. New Temporal Dependency Issues for Zones

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
有关域名服务器的考虑
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.
在报文长度限制允许的情况下，一个安全域名服务器应该在应答中包含相应的DNSSEC记录（RRSIG,DNSKEY,DS,NSEC），如果解析器在查询报文中的EDNS头部设置了DO位来声明愿意接受这些记录。因为包含这些DNSSEC资源记录可能应以的导致UDP报文超长而使用TCP，一个安全域名服务器必须支持EDNS的”发送方UDPpayload”机制。
Arends, et al. Standards Track [Page 13]

RFC 4033 DNS Security Introduction and Requirements March 2005
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).
如果可能的话，每个DNSSEC密钥对的私钥部分必须被离线保存，但是这对于需要动态更新的区来说是不可能的。在动态更新的情况下，当更新后，区主服务器必须要重签区，这是与区重签相关的私钥必须要在线。这是一种最好将DNSKEY分成zsk和ksk情况，因为ksk可以离线保管而且获得更长的生命期。
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).
DNSSEC本身并不能保证区传送中整个区数据的完整性，如果一个签名区包含一些未签名未验证的信息。因此，区维护操作需要一些额外的机制（最可能是一些信道安全机制，比如TSIG,SIG(0)或者IPsec）。
10. DNS Security Document Family
DNS 安全文档家族
The DNSSEC document set can be partitioned into several main groups,
under the larger umbrella of the DNS base protocol documents.
DNSSEC文档系列可以被分成几个主要的组。
The “DNSSEC protocol document set” refers to the three documents that
form the core of the DNS security extensions:
DNSSEC协议文件族指的是三分组成DNS安全扩展核心的文档。
1. DNS Security Introduction and Requirements (this document)
DNS安全简介和需求（本文档）
2. Resource Records for DNS Security Extensions [RFC4034]
DNS安全扩展使用的资源记录类型（RFC4034）
3. Protocol Modifications for the DNS Security Extensions [RFC4035]
DNS安全扩展协议修正（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.
另外，任何增加或更改核心DNS安全扩展的文档都会列入这份目录。这包括未来安全存根解析器和上游安全递归服务器之间的通信方面的工作。
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.
“数字签名算法”文档指的是描述特定的数字签名算法如何按照DNSSEC资源记录的类型部署。这个集合中的每个文档处理一种特定的数字签名算法。请参见RFC4034关于DNSSEC算法和摘要类型的附录列出了一系列的算法。
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

Arends, et al. Standards Track [Page 14]
RFC 4033 DNS Security Introduction and Requirements March 2005
strictly part of the DNSSEC specification as defined in this set of
documents, this group is noted because of its relationship to DNSSEC.
事务鉴别协议文档集合着的是处理报文鉴别的文档，包括密钥建立和验证。虽然按照本文档的定义严格来说并不是DNSSEC协议的一部分，然而由于和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]).
最终的文档集合，”新安全应用”，指的是采用DNS安全扩展来解决其他安全相关的问题的文档。DNSSEC并不直接为这些新的应用提供安全，而是协助他们。在这个范围内的文档包括描述DNS存贮和证书分发的文档（RFC2538）。
11. IANA Considerations
IANA 的观点
This overview document introduces no new IANA considerations. Please
see [RFC4034] for a complete review of the IANA considerations
introduced by DNSSEC.
没有引入新的观点
12. Security Considerations
有关安全的考虑
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.
这本文档介绍了DNS安全扩展，描述了包含新的安全记录和dns协议修订的文档集合。这些扩展通过对信息资源记录进行数字签名提供数据端点鉴别和数据完整性保护。
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.
为了是安全解析器能够验证一个DNS应答，从信任起始点到应答区路径上的所有区都必须是安全的（按照本文档的定义）。一个安全解析器不能验证从一个未签名区发出的应答报文，或一个没有安全域名服务器伺服的区，或者只能通过一个不安全的递归服务器。如果信任链有中断时的安全解析器不能获得和验证它需要的家别密钥，那么安全解析器不能验证相关联的dns数据。
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.
本文档粗略的讨论了其他能增加DNS查询安全性的方法，比如使用IPsec加固的信道或者使用想TSIG(RFC2845)这样的DNS事务传输机制，但是事务安全并不是DNSSEC的一部分。
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
一个不做安全验证的安全存根解析器，根据定义，不自己进行DNSSEC签名验证，因此对针对为其做验证的递归服务器的攻击或者对两者之间通信的攻击很脆弱。
Arends, et al. Standards Track [Page 15]

RFC 4033 DNS Security Introduction and Requirements March 2005
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.
DNSSEC并不能防御拒绝服务攻击。DNSSEC使得DNS对于一种针对安全解析器和安全域名服务器的新的基于加密手段的拒绝服务攻击很脆弱，因为一个攻击者可以试图通过DNSSEC机制去消耗受害者的资源.这类攻击至少有两种形式。一个攻击者通过修改应答报文中的RRSIG RRs或者构建无用的复杂的信任链来消耗安全解析器的签名验证码资源。攻击者也可以通过频繁发送大量要求安全服务器区重签一些RRsecs的更新报文来消耗支持DNS动态更新的安全域名服务器的资源。
Due to a deliberate design choice, DNSSEC does not provide
confidentiality.
经过谨慎的设计考虑，DNSSEC不支持加密。
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时的恶意方能够沿着NSEC链得到区中的所有域名。NSEC RR通过按照范式顺序将区中所有的域名连接起来来暗示哪些域名是不存在的。因此，攻击者可以按顺序查询NSEC RR来获得一个区中的所有域名。尽管这不是针对DNS本身的攻击，但是却使攻击者能够通过枚举区中的信息得到网络主机的映射或者其他资源.
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为DNS带来了显著的额外复杂度因此引入了产生许多新的部署缺陷和配置错误的区的可能性。特别的，在一个解析器中开启DNSSEC签名验证可能使得整个逻辑区因为错误的配置或者bug变得不可见。
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.
DNSSEC并不能保护对于未签名区数据的干扰。在区分界处的非授权数据（父区中的glue和NS RR）是不签名的。在验证信任链时并不会引发问题，然而未授权在区传送操作时是脆弱的。因此，DNSSEC可以为RRsets提供端点鉴别和数据完整性保护，而不能为区做类似保护，必须使用其他的机制来保护区传送操作。
Arends, et al. Standards Track [Page 16]

RFC 4033 DNS Security Introduction and Requirements March 2005
Please see [RFC4034] and [RFC4035] for additional security
considerations.

13. Acknowledgements

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.
人名。。。
No doubt the above list is incomplete. We apologize to anyone we
left out.