> On Oct 3, 2019, at 7:11 AM, Tony Finch <[email protected]> wrote: > >>> [ I'm still not convinced "indeterminate" is a coherent validation state... >>> ] >> >> It happens when glue NS records are available, but DS RRsets are not. > > That is "insecure".
No, by "available" I meant lookup succeeded (returning valid records, NODATA or NXDOMAIN, with DoE as appropriate). By "unavailable", I meant a timeout, ServFail, bogus reply, ... > I think the definitions of the terms in RFC 4033 are a lot more clear than > RFC 4035. By the 4033 definitions the distinction between insecure and > indeterminate is whether you have a covering trust anchor or not, so > nothing is indeterminate any more for normal validator configurations. A clear but vacuous/redundant definition is not useful. In RFC7672 I chose the 4035 variant, because it is actually useful: https://tools.ietf.org/html/rfc7672#section-2.1.1 The RFC4033 definition of "indeterminate" is not usefully different from "insecure", and as you note, with the root signed, is mostly no longer applicable. This state is different from "bogus", "insecure" or "secure". The resolver has an answer whose security status is unknown (indeterminate), because the records needed to determine that status could not be obtained (which is different from "missing"). -- Viktor. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
