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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
