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

Reply via email to