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

4.1. EDNS Support

The implementations of security-aware resolvers MUST support the EDNS0 message size extension, MUST support a message size of at least 1220 octets, and SHOULD support a message size of 4000 octets.

4.2. Signature Verification Support

A security-aware resolver MUST support the signature verification mechanisms described in Section 5, and MUST apply them to every received response, except when:

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

4.3. Determining Security Status of Data

A security-aware resolver MUST be able to determine whether it should expect a particular RRset to be signed. 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.

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

4.4. Configured Trust Anchors

A security-aware resolver MUST be capable of being configured with at 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.

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 RRSIG RRs and NSEC RRs associated with it, regardless of the response's security status.

A security-aware resolver MUST NOT cache RRSIG RRs independently of the RRsets that they sign, as this could permit an attacker to replay old RRSIGs with new data.

4.6. Handling of the CD and AD Bits

The CD bit controls whether a security-aware resolver performs validation for a particular query. A security-aware resolver MUST set the AD bit in a response if and only if the resolver considers all RRsets in the Answer and Authority sections of the response to be authentic.

A resolver that is not security-aware MUST NOT set the AD bit in a response. A security-aware resolver MUST NOT set the AD bit unless it has validated the data according to the rules described in this specification.

4.7. Caching BAD Data

A resolver MAY cache data with a "bad" security status differently from data with a "good" security status. However, a resolver MUST NOT use cached data with a bad security status unless:

• The resolver is

responding to a query with the CD bit set

• The bad data was the result of a query with the CD bit set
• Local policy explicitly authorizes use of bad data

4.8. Synthesized CNAMEs

A security-aware resolver MUST apply special processing rules when handling synthesized CNAME RRs as described in [RFC2672]. The resolver MUST NOT expect a synthesized CNAME to be signed, but MUST validate the DNAME RR from which the CNAME was synthesized.

4.9. Stub Resolvers

A security-aware stub resolver is an entity that acts as a DNS resolver and that has the ability to perform signature validation but does not act as a full security-aware recursive name server. Stub resolvers typically rely on a recursive name server to perform most DNS operations on their behalf.

4.9.1. Handling of the DO Bit

A security-aware stub resolver SHOULD set the DO bit in queries to indicate that it wishes to receive DNSSEC RRs in the response.

4.9.2. Handling of the CD Bit

A security-aware stub resolver MAY set the CD bit in queries to indicate that it is willing to perform validation itself rather than relying on the name server to which it is sending the query to perform validation on its behalf.

4.9.3. Handling of the AD Bit

A security-aware stub resolver MAY use the setting of the AD bit in a response to indicate whether the name server that sent the response validated the data on the stub resolver's behalf.

A security-aware stub resolver that sets the CD bit in a query MUST ignore the AD bit in the response, since the name server was explicitly instructed not to perform validation on the stub resolver's behalf.

---