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

[Ólafur Guðmundsson <[e-mail]>]

On Thu, Nov 9, 2017 at 12:01 AM, Paul Wouters <[e-mail]> wrote:

> 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.
>
>
Paul,

I have been thinking about what you said and why it is perfectly valid, but
that I think it is wrong.
The issue here is three fold IMHO
Operator is using split-DNS i.e. internal and external
Operator is using the SAME name space for both views  i.e. foo.example.com
can exist in both name spaces with different values.
Operator is using DIFFERENT keys to sign the two namespaces.

We have no way at the moment to express  which namespace a "name" comes
from thus you want to give preference to the "internal" namespace for users
of that namespace

The purist in me says this is bad setup, the practical part of me says "you
get what you ask for" i.e. IETF failed to write guidelines for Spit-DNS
thus we should expect things like this.
Either way I think the use of Different Key is what we should strongly
discourage as that makes the other problems go away.

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
>
> Olafur