There are three ways to treat this case: Any-TruestedKey-works ConfiguredKey-trumps-DS DS-trumps-configuredKey
I think the Last one is the "most" correct from an operational expectation, but the first one is least likely to run into errors, But I suspect the middle one is implemented Olafur On Tue, Oct 31, 2017 at 2:39 AM, Moritz Muller <moritz.mul...@sidn.nl> wrote: > Hi, > > Together with my colleagues I have been stumbling upon a, for me, unclear > case when validating trust anchors. > > Assuming that a resolver has enabled DNSSEC validation and has the root > keys configured. > Additionally, it has configured manually a trust anchor for a TLD (that > has also published its DS in the root zone). > Now, for example due to a key rollover at the TLD, the manually configured > trust anchor of the TLD does not match the DS in the root anymore. > > How should a resolver treat the signatures of this TLD? > The resolvers of BIND, Unbound, and PowerDNS seem to treat the signatures > of the TLD as bogus, but we didn't find any specifics in RFC 4034 and 4035 > that describe how resolvers should behave in this case. > Knot resolver treats them as NOERROR (according to the developers). > If we interpret section 4.3 of RFC 4035 then we would have assumed that > the signature must be treated as secure. > > Did we miss something, or is there indeed clarification needed? > > — Moritz > > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
