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.
