5. Scope of the DNSSEC Document Set and Last Hop Issues

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

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

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.