📄 draft-ietf-dnsext-dnssec-protocol-07.txt
字号:
the same field of a parental RRSIG RR at the zone cut will indicate a DNSKEY RR in the parent zone's apex. As with any other authoritative RRs, RRSIG RRs MUST be included in zone transfers of the zone in which they are authoritative data.3.1.6 The AD and CD Bits in an Authoritative Response The CD and AD bits are designed for use in communication between security-aware resolvers and security-aware recursive name servers. These bits are for the most part not relevant to query processing by security-aware authoritative name servers. A security-aware name server does not perform signature validation for authoritative data during query processing even when the CD bit is clear. A security-aware name server SHOULD clear the CD bit when composing an authoritative response. A security-aware name server MUST NOT set the AD bit in a response unless the name server considers all RRsets in the Answer and Authority sections of the response to be authentic. A security-aware name server's local policy MAY consider data from an authoritative zone to be authentic without further validation, but the name server MUST NOT do so unless the name server obtained the authoritative zone via secure means (such as a secure zone transfer mechanism), and MUSTArends, et al. Expires January 13, 2005 [Page 16] Internet-Draft DNSSEC Protocol Modifications July 2004 NOT do so unless this behavior has been configured explicitly. A security-aware name server which supports recursion MUST follow the rules for the CD and AD bits given in Section 3.2 when generating a response that involves data obtained via recursion.3.2 Recursive Name Servers As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware recursive name server is an entity which acts in both the security-aware name server and security-aware resolver roles. This section uses the terms "name server side" and "resolver side" to refer to the code within a security-aware recursive name server which implements the security-aware name server role and the code which implements the security-aware resolver role, respectively. The resolver side follows the usual rules for caching and negative caching which would apply to any security-aware resolver.3.2.1 The DO bit The resolver side of a security-aware recursive name server MUST set the DO bit when sending requests, regardless of the state of the DO bit in the initiating request received by the name server side. If the DO bit in an initiating query is not set, the name server side MUST strip any authenticating DNSSEC RRs from the response, but MUST NOT strip any DNSSEC RR types that the initiating query explicitly requested.3.2.2 The CD bit The CD bit exists in order to allow a security-aware resolver to disable signature validation in a security-aware name server's processing of a particular query. The name server side MUST copy the setting of the CD bit from a query to the corresponding response. The name server side of a security-aware recursive name server MUST pass the sense of the CD bit to the resolver side along with the rest of an initiating query, so that the resolver side will know whether or not it is required to verify the response data it returns to the name server side. If the CD bit is set, it indicates that the originating resolver is willing to perform whatever authentication its local policy requires, thus the resolver side of the recursive name server need not perform authentication on the RRsets in the response. When the CD bit is set the recursive name server SHOULD, if possible, return the requested data to the originating resolverArends, et al. Expires January 13, 2005 [Page 17] Internet-Draft DNSSEC Protocol Modifications July 2004 even if the recursive name server's local authentication policy would reject the records in question. That is, by setting the CD bit, the originating resolver has indicated that it takes responsibility for performing its own authentication, and the recursive name server should not interfere. If the resolver side implements a BAD cache (see Section 4.7) and the name server side receives a query which matches an entry in the resolver side's BAD cache, the name server side's response depends on the sense of the CD bit in the original query. If the CD bit is set, the name server side SHOULD return the data from the BAD cache; if the CD bit is not set, the name server side MUST return RCODE 2 (server failure). The intent of the above rule is to provide the raw data to clients which are capable of performing their own signature verification checks while protecting clients which depend on the resolver side of a security-aware recursive name server to perform such checks. Several of the possible reasons why signature validation might fail involve conditions which may not apply equally to the recursive name server and the client which invoked it: for example, the recursive name server's clock may be set incorrectly, or the client may have knowledge of a relevant island of security which the recursive name server does not share. In such cases, "protecting" a client which is capable of performing its own signature validation from ever seeing the "bad" data does not help the client.3.2.3 The AD bit The name server side of a security-aware recursive name server MUST NOT set the AD bit in a response unless the name server considers all RRsets in the Answer and Authority sections of the response to be authentic. The name server side SHOULD set the AD bit if and only if the resolver side considers all RRsets in the Answer section and any relevant negative response RRs in the Authority section to be authentic. The resolver side MUST follow the procedure described in Section 5 to determine whether the RRs in question are authentic. However, for backwards compatibility, a recursive name server MAY set the AD bit when a response includes unsigned CNAME RRs if those CNAME RRs demonstrably could have been synthesized from an authentic DNAME RR which is also included in the response according to the synthesis rules described in [RFC2672].3.3 Example DNSSEC Responses See Appendix B for example response packets.Arends, et al. Expires January 13, 2005 [Page 18] Internet-Draft DNSSEC Protocol Modifications July 20044. Resolving This section describes the behavior of entities that include security-aware resolver functions. In many cases such functions will be part of a security-aware recursive name server, but a stand-alone security-aware resolver has many of the same requirements. Functions specific to security-aware recursive name servers are described in Section 3.2.4.1 EDNS Support A security-aware resolver MUST include an EDNS [RFC2671] OPT pseudo-RR with the DO [RFC3225] bit set when sending queries. A security-aware resolver MUST support a message size of at least 1220 octets, SHOULD support a message size of 4000 octets, and MUST advertise the supported message size using the "sender's UDP payload size" field in the EDNS OPT pseudo-RR. A security-aware resolver MUST handle fragmented UDP packets correctly regardless of whether any such fragmented packets were received via IPv4 or IPv6. Please see [RFC3226] for discussion of these requirements.4.2 Signature Verification Support A security-aware resolver MUST support the signature verification mechanisms described in Section 5, and SHOULD apply them to every received response except when: o The security-aware resolver is part of a security-aware recursive name server, and the response is the result of recursion on behalf of a query received with the CD bit set; o The response is the result of a query generated directly via some form of application interface which instructed the security-aware resolver not to perform validation for this query; or o Validation for this query has been disabled by local policy. A security-aware resolver's support for signature verification MUST include support for verification of wildcard owner names. Security aware resolvers MAY query for missing security RRs in an attempt to perform validation; implementations that choose to do so must be aware that the answers received may not be sufficient to validate the original response. When attempting to retrieve missing NSEC RRs which reside on the parental side at a zone cut, a security-aware iterative-mode resolver MUST query the name servers for the parent zone, not the child zone. When attempting to retrieve a missing DS, a security-awareArends, et al. Expires January 13, 2005 [Page 19] Internet-Draft DNSSEC Protocol Modifications July 2004 iterative-mode resolver MUST query the name servers for the parent zone, not the child zone. As explained in Section 3.1.4.1, security-aware name servers need to apply special processing rules to handle the DS RR, and in some situations the resolver may also need to apply special rules to locate the name servers for the parent zone if the resolver does not already have the parent's NS RRset. To locate the parent NS RRset, the resolver can start with the delegation name, strip off the leftmost label, and query for an NS RRset by that name; if no NS RRset is present at that name, the resolver then strips of the leftmost remaining label and retries the query for that name, repeating this process of walking up the tree until it either finds the NS RRset or runs out of labels.4.3 Determining Security Status of Data A security-aware resolver MUST be able to determine whether or not it should expect a particular RRset to be signed. More precisely, a security-aware resolver must be able to distinguish between four cases: Secure: An RRset for which the resolver is able to build a chain of signed DNSKEY and DS RRs from a trusted security anchor to the RRset. In this case, the RRset should be signed, and is subject to signature validation as described above. Insecure: An RRset for which the resolver knows that it has no chain of signed DNSKEY and DS RRs from any trusted starting point to the RRset. This can occur when the target RRset lies in an unsigned zone or in a descendent of an unsigned zone. In this case, the RRset may or may not be signed, but the resolver will not be able to verify the signature. Bogus: An RRset for which the resolver believes that it ought to be able to establish a chain of trust but is unable to do so, either due to signatures that for some reason fail to validate or due to missing data which the relevant DNSSEC RRs indicate should be present. This case may indicate an attack, but may also indicate a configuration error or some form of data corruption. Indeterminate: An RRset for which the resolver is not able to determine whether or not the RRset should be signed, because the resolver is not able to obtain the necessary DNSSEC RRs. This can occur when the security-aware resolver is not able to contact security-aware name servers for the relevant zones.4.4 Configured Trust Anchors A security-aware resolver MUST be capable of being configured with atArends, et al. Expires January 13, 2005 [Page 20] Internet-Draft DNSSEC Protocol Modifications July 2004 least one trusted public key or DS RR, and SHOULD be capable of being configured with multiple trusted public keys or DS RRs. Since a security-aware resolver will not be able to validate signatures without such a configured trust anchor, the resolver SHOULD have some reasonably robust mechanism for obtaining such keys when it boots; examples of such a mechanism would be some form of non-volatile storage (such as a disk drive) or some form of trusted local network configuration mechanism. Note that trust anchors also covers key material that is updated in a secure manner. This secure manner could be through physical media, a key exchange protocol, or some other out of band means.4.5 Response Caching A security-aware resolver SHOULD cache each response as a single atomic entry containing the entire answer, including the named RRset and any associated DNSSEC RRs. The resolver SHOULD discard the entire atomic entry when any of the RRs contained in it expire. In most cases the appropriate cache index for the atomic entry will be the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response form described in Section 3.1.3.2 the appropriate cache index will be the double <QNAME,QCLASS>. The reason for these recommendations is that, between the initial query and the expiration of the data from the cache, the authoritative data might have been changed (for example, via dynamic update). There are two situations for which this is relevant: 1. By using the RRSIG record, it is possible to deduce that an answer was synthesized from a wildcard. A security aware recursive name server could store this wildcard data and use it⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -