Re: [DNSOP] Resolver behaviour with multiple trust anchors

If I remember the discussions correctly, there was a sense that the
resolver decides the local policy. And that yes, those are the three
options. Perhaps the options should be made more clear in a text somewhere.

On Tue, 31 Oct 2017, Ólafur Guðmundsson wrote:

>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.muller@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