Section 3.2. 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 use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR to advertise the message size that it is willing to accept. A security-aware resolver's IP layer MUST handle fragmented UDP packets correctly regardless of whether any such fragmented packets were received via IPv4 or IPv6. Please see [RFC1122], [RFC2460], and [RFC3226] for discussion of these requirements. 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 that 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. For example, a zone update may have changed (or deleted) the desired information between the original and follow-up queries. When attempting to retrieve missing NSEC RRs that 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-aware iterative-mode resolver MUST query the name servers for the parent zone, not the child zone. As explained in Section 220.127.116.11, 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 off 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.
Bogus: An RRset for which the resolver believes that it ought to be able to establish a chain of trust but for which it is unable to do so, either due to signatures that for some reason fail to validate or due to missing data that 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 the RRset should be signed, as 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. Section 18.104.22.168 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 to generate positive responses to queries other than the name for which the original answer was first received. 2. NSEC RRs received to prove the non-existence of a name could be reused by a security-aware resolver to prove the non-existence of any name in the name range it spans. In theory, a resolver could use wildcards or NSEC RRs to generate positive and negative responses (respectively) until the TTL or signatures on the records in question expire. However, it seems prudent for resolvers to avoid blocking new authoritative data or synthesizing new data on their own. Resolvers that follow this recommendation will have a more consistent view of the namespace. Section 3.2 for the effect this bit has on the behavior of security-aware recursive name servers. A security-aware resolver MUST clear the AD bit when composing query messages to protect against buggy name servers that blindly copy header bits that they do not understand from the query message to the response message. A resolver MUST disregard the meaning of the CD and AD bits in a response unless the response was obtained by using a secure channel or the resolver was specifically configured to regard the message header bits without using a secure channel.
Conceptually, caching such data is similar to negative caching ([RFC2308]), except that instead of caching a valid negative response, the resolver is caching the fact that a particular answer failed to validate. This document refers to a cache of data with invalid signatures as a "BAD cache". Resolvers that implement a BAD cache MUST take steps to prevent the cache from being useful as a denial-of-service attack amplifier, particularly the following: o Since RRsets that fail to validate do not have trustworthy TTLs, the implementation MUST assign a TTL. This TTL SHOULD be small, in order to mitigate the effect of caching the results of an attack. o In order to prevent caching of a transient validation failure (which might be the result of an attack), resolvers SHOULD track queries that result in validation failures and SHOULD only answer from the BAD cache after the number of times that responses to queries for that particular <QNAME, QTYPE, QCLASS> have failed to validate exceeds a threshold value. Resolvers MUST NOT return RRsets from the BAD cache unless the resolver is not required to validate the signatures of the RRsets in question under the rules given in Section 4.2 of this document. See Section 3.2.2 for discussion of how the responses returned by a security-aware recursive name server interact with a BAD cache. RFC2672], at least to the extent of not rejecting a response message solely because it contains such CNAME RRs. The resolver MAY retain such CNAME RRs in its cache or in the answers it hands back, but is not required to do so.
Section 5.3. Once the resolver has authenticated the apex DNSKEY RRset by using an initial DNSKEY RR, delegations from that zone can be authenticated by using DS RRs. This allows a resolver to start from an initial key and use DS RRsets to proceed recursively down the DNS tree, obtaining other apex DNSKEY RRsets. If the resolver were configured with a root DNSKEY RR, and if every delegation had a DS RR associated with it, then the resolver could obtain and validate any apex DNSKEY RRset. The process of using DS RRs to authenticate referrals is described in Section 5.2. Section 5.3 shows how the resolver can use DNSKEY RRs in the apex DNSKEY RRset and RRSIG RRs from the zone to authenticate any other RRsets in the zone once the resolver has authenticated a zone's apex DNSKEY RRset. Section 5.4 shows how the resolver can use authenticated NSEC RRsets from the zone to prove that an RRset is not present in the zone. When a resolver indicates support for DNSSEC (by setting the DO bit), a security-aware name server should attempt to provide the necessary DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). However, a security-aware resolver may still receive a response that lacks the appropriate DNSSEC RRs, whether due to configuration issues such as an upstream security-oblivious recursive name server that
accidentally interferes with DNSSEC RRs or due to a deliberate attack in which an adversary forges a response, strips DNSSEC RRs from a response, or modifies a query so that DNSSEC RRs appear not to be requested. The absence of DNSSEC data in a response MUST NOT by itself be taken as an indication that no authentication information exists. A resolver SHOULD expect authentication information from signed zones. A resolver SHOULD believe that a zone is signed if the resolver has been configured with public key information for the zone, or if the zone's parent is signed and the delegation from the parent contains a DS RRset. RFC4033]) are signed zones for which it is not possible to construct an authentication chain to the zone from its parent. Validating signatures within an island of security requires that the validator have some other means of obtaining an initial authenticated zone key for the island. If a validator cannot obtain such a key, it SHOULD switch to operating as if the zones in the island of security are unsigned. All the normal processes for validating responses apply to islands of security. The only difference between normal validation and validation within an island of security is in how the validator obtains a trust anchor for the authentication chain. Section 5.3).
o The Algorithm and Key Tag in the DS RR match the Algorithm field and the key tag of a DNSKEY RR in the child zone's apex DNSKEY RRset, and, when the DNSKEY RR's owner name and RDATA are hashed using the digest algorithm specified in the DS RR's Digest Type field, the resulting digest value matches the Digest field of the DS RR. o The matching DNSKEY RR in the child zone has the Zone Flag bit set, the corresponding private key has signed the child zone's apex DNSKEY RRset, and the resulting RRSIG RR authenticates the child zone's apex DNSKEY RRset. If the referral from the parent zone did not contain a DS RRset, the response should have included a signed NSEC RRset proving that no DS RRset exists for the delegated name (see Section 3.1.4). A security-aware resolver MUST query the name servers for the parent zone for the DS RRset if the referral includes neither a DS RRset nor a NSEC RRset proving that the DS RRset does not exist (see Section 4). If the validator authenticates an NSEC RRset that proves that no DS RRset is present for this zone, then there is no authentication path leading from the parent to the child. If the resolver has an initial DNSKEY or DS RR that belongs to the child zone or to any delegation below the child zone, this initial DNSKEY or DS RR MAY be used to re-establish an authentication path. If no such initial DNSKEY or DS RR exists, the validator cannot authenticate RRsets in or below the child zone. If the validator does not support any of the algorithms listed in an authenticated DS RRset, then the resolver has no supported authentication path leading from the parent to the child. The resolver should treat this case as it would the case of an authenticated NSEC RRset proving that no DS RRset exists, as described above. Note that, for a signed delegation, there are two NSEC RRs associated with the delegated name. One NSEC RR resides in the parent zone and can be used to prove whether a DS RRset exists for the delegated name. The second NSEC RR resides in the child zone and identifies which RRsets are present at the apex of the child zone. The parent NSEC RR and child NSEC RR can always be distinguished because the SOA bit will be set in the child NSEC RR and clear in the parent NSEC RR. A security-aware resolver MUST use the parent NSEC RR when attempting to prove that a DS RRset does not exist.
If the resolver does not support any of the algorithms listed in an authenticated DS RRset, then the resolver will not be able to verify the authentication path to the child zone. In this case, the resolver SHOULD treat the child zone as if it were unsigned. Sections 5.3.1, 5.3.2, and 5.3.3 describe each step in detail.
It is possible for more than one DNSKEY RR to match the conditions above. In this case, the validator cannot predetermine which DNSKEY RR to use to authenticate the signature, and it MUST try each matching DNSKEY RR until either the signature is validated or the validator has run out of matching public keys to try. Note that this authentication process is only meaningful if the validator authenticates the DNSKEY RR before using it to validate signatures. The matching DNSKEY RR is considered to be authentic if: o the apex DNSKEY RRset containing the DNSKEY RR is considered authentic; or o the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, and the DNSKEY RR either matches an authenticated DS RR from the parent zone or matches a trust anchor. Section 5.3.1, the validator has to reconstruct the original signed data. The original signed data includes RRSIG RDATA (excluding the Signature field) and the canonical form of the RRset. Aside from being ordered, the canonical form of the RRset might also differ from the received RRset due to DNS name compression, decremented TTLs, or wildcard expansion. The validator should use the following to reconstruct the original signed data: signed_data = RRSIG_RDATA | RR(1) | RR(2)... where "|" denotes concatenation RRSIG_RDATA is the wire format of the RRSIG RDATA fields with the Signature field excluded and the Signer's Name in canonical form. RR(i) = name | type | class | OrigTTL | RDATA length | RDATA name is calculated according to the function below class is the RRset's class type is the RRset type and all RRs in the class OrigTTL is the value from the RRSIG Original TTL field All names in the RDATA field are in canonical form
The set of all RR(i) is sorted into canonical order. To calculate the name: let rrsig_labels = the value of the RRSIG Labels field let fqdn = RRset's fully qualified domain name in canonical form let fqdn_labels = Label count of the fqdn above. if rrsig_labels = fqdn_labels, name = fqdn if rrsig_labels < fqdn_labels, name = "*." | the rightmost rrsig_label labels of the fqdn if rrsig_labels > fqdn_labels the RRSIG RR did not pass the necessary validation checks and MUST NOT be used to authenticate this RRset. The canonical forms for names and RRsets are defined in [RFC4034]. NSEC RRsets at a delegation boundary require special processing. There are two distinct NSEC RRsets associated with a signed delegated name. One NSEC RRset resides in the parent zone, and specifies which RRsets are present at the parent zone. The second NSEC RRset resides at the child zone and identifies which RRsets are present at the apex in the child zone. The parent NSEC RRset and child NSEC RRset can always be distinguished as only a child NSEC RR will indicate that an SOA RRset exists at the name. When reconstructing the original NSEC RRset for the delegation from the parent zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the child zone. When reconstructing the original NSEC RRset for the apex of the child zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent zone. Note that each of the two NSEC RRsets at a delegation point has a corresponding RRSIG RR with an owner name matching the delegated name, and each of these RRSIG RRs is authoritative data associated with the same zone that contains the corresponding NSEC RRset. If necessary, a resolver can tell these RRSIG RRs apart by checking the Signer's Name field.
Section 5.3.1 and reconstructed the original signed data as described in Section 5.3.2, the validator can attempt to use the cryptographic signature to authenticate the signed data, and thus (finally!) authenticate the RRset. The Algorithm field in the RRSIG RR identifies the cryptographic algorithm used to generate the signature. The signature itself is contained in the Signature field of the RRSIG RDATA, and the public key used to verify the signature is contained in the Public Key field of the matching DNSKEY RR(s) (found in Section 5.3.1). [RFC4034] provides a list of algorithm types and provides pointers to the documents that define each algorithm's use. Note that it is possible for more than one DNSKEY RR to match the conditions in Section 5.3.1. In this case, the validator can only determine which DNSKEY RR is correct by trying each matching public key until the validator either succeeds in validating the signature or runs out of keys to try. If the Labels field of the RRSIG RR is not equal to the number of labels in the RRset's fully qualified owner name, then the RRset is either invalid or the result of wildcard expansion. The resolver MUST verify that wildcard expansion was applied properly before considering the RRset to be authentic. Section 5.3.4 describes how to determine whether a wildcard was applied properly. If other RRSIG RRs also cover this RRset, the local resolver security policy determines whether the resolver also has to test these RRSIG RRs and how to resolve conflicts if these RRSIG RRs lead to differing results. If the resolver accepts the RRset as authentic, the validator MUST set the TTL of the RRSIG RR and each RR in the authenticated RRset to a value no greater than the minimum of: o the RRset's TTL as received in the response; o the RRSIG RR's TTL as received in the response; o the value in the RRSIG RR's Original TTL field; and o the difference of the RRSIG RR's Signature Expiration time and the current time.
Section 5.3, it must take additional steps to verify the non- existence of an exact match or closer wildcard match for the query. Section 5.4 discusses these steps. Note that the response received by the resolver should include all NSEC RRs needed to authenticate the response (see Section 3.1.3). RFC4034], then no RRsets with the requested name exist in the zone. However, it is possible that a wildcard could be used to match the requested RR owner name and type, so proving that the requested RRset does not exist also requires proving that no possible wildcard RRset exists that could have been used to generate a positive response. In addition, security-aware resolvers MUST authenticate the NSEC RRsets that comprise the non-existence proof as described in Section 5.3. To prove the non-existence of an RRset, the resolver must be able to verify both that the queried RRset does not exist and that no relevant wildcard RRset exists. Proving this may require more than
one NSEC RRset from the zone. If the complete set of necessary NSEC RRsets is not present in a response (perhaps due to message truncation), then a security-aware resolver MUST resend the query in order to attempt to obtain the full collection of NSEC RRs necessary to verify the non-existence of the requested RRset. As with all DNS operations, however, the resolver MUST bound the work it puts into answering any particular query. Since a validated NSEC RR proves the existence of both itself and its corresponding RRSIG RR, a validator MUST ignore the settings of the NSEC and RRSIG bits in an NSEC RR. Section 4.7 on caching responses that do not validate. Appendix C shows an example of the authentication process. RFC4034] contains a review of the IANA considerations introduced by DNSSEC. The following are additional IANA considerations discussed in this document: [RFC2535] reserved the CD and AD bits in the message header. The meaning of the AD bit was redefined in [RFC3655], and the meaning of both the CD and AD bit are restated in this document. No new bits in the DNS message header are defined in this document. [RFC2671] introduced EDNS, and [RFC3225] reserved the DNSSEC OK bit and defined its use. The use is restated but not altered in this document. RFC4033] for terminology and general security considerations related to DNSSEC; see [RFC4034] for considerations specific to the DNSSEC resource record types.
An active attacker who can set the CD bit in a DNS query message or the AD bit in a DNS response message can use these bits to defeat the protection that DNSSEC attempts to provide to security-oblivious recursive-mode resolvers. For this reason, use of these control bits by a security-aware recursive-mode resolver requires a secure channel. See Sections 3.2.2 and 4.9 for further discussion. The protocol described in this document attempts to extend the benefits of DNSSEC to security-oblivious stub resolvers. However, as recovery from validation failures is likely to be specific to particular applications, the facilities that DNSSEC provides for stub resolvers may prove inadequate. Operators of security-aware recursive name servers will have to pay close attention to the behavior of the applications that use their services when choosing a local validation policy; failure to do so could easily result in the recursive name server accidentally denying service to the clients it is intended to support. RFC4033] includes a list of some of the participants who were kind enough to comment on these documents.