Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors

[Paul Wouters <[e-mail]>]

On Wed, 8 Nov 2017, Edward Lewis wrote:

> This is why the guidance in "Protocol Modifications for the DNS Security Extensions" leads to "any" chain. "Clarifications and Implementation Notes for DNS Security (DNSSEC)" opens the possibility that knobs can be included, which is the prerogative of the implementer to build and the operator to use (local policy).  I see these two documents as compatible.

"prerogative of the implementer" canont apply to how one defines trust
in a protocol. You can't have two implementations make different
trust decisions, especially as most endusers don't control their
resolver.

> The bottom line is that one can choose to abide by a rule of "if a trust anchor is there, ignore other chains" but recall that the choice is made by the validator operator, not the zone administrator, as the validator operator is also responsible for keeping the trust anchors current and accurate, it is their own failure if that is not the case, and they exclusively have the ability to fix a conflict.
>
> The bottom line is that the zone administrator doesn't get a say - it's all up to the validator operators.

It's up to neither. You cannot retroactively argue that hardcoding trust
anchors is an option can that be ignored by an implementation.

knot had a bug some people thought would be a nice fallback recovery
feature to a failed rollover procedure. knot should just be fixed. This
really does not require an RFC update.

Paul