in the last 20 years, there have been a few testbeds that have explored this space.
irl.cs.ucla.edu/papers/imc71-osterweil.pdf https://eprint.iacr.org/2013/254.pdf that suggest Matt is spot on here. accepting any success is likely to present the fewest problems from a user perspective. /Wm On Thu, Nov 2, 2017 at 7:41 AM, Matt Larson <m...@kahlerlarson.org> wrote: > The root KSK rollover project has given me a real appreciation for the > brittleness of trust anchor configuration, even with RFC 5011. (Automated > update support should get better over time, especially after the first KSK > roll exposes problems, but right now it's pretty shaky, which is my > informed opinion based on observation from the operational trenches.) In > the real world, where trust anchors are going to go stale, an "Accept Any > Success" (in the language of Appendix C) trust anchor policy is the safest > operationally. > > I agree with Ed's observation that operators are, by and large, going to > use the defaults in whatever implementation they're running, so defaults > are important. > > Trust is always going to be a matter of local policy, so with DNSSEC > there's never going to be a consistent output given a consistent input. The > best we can do is give good guidance to implementors, ideally based on > operational experience, to inform their choices for the default settings > that operators will end up using. > > I think RFC 6840 gets it right: it acknowledges that trust anchor > preference is a matter of local policy, but recommends an operationally > safe default of "Accept Any Success". > > Why would one want a "Closest Encloser" trust anchor preference policy? > I've heard two reasons in this thread: > > 1. The untrusted parent scenario: I submit there's no practical > implication of distinguishing between the parent's control of the > delegation and its control of the DS: the child zone is completely at the > will of the parent zone, so if your parent has it in for you, you lose. > This scenario is not sufficient motivation, in my opinion, to suggest > "Closest Encloser" as a default policy. > > 2. In a split DNS context, reject answers that leak into the wrong view: I > think using DNSSEC as a backstop to enforce split DNS policy is a dubious > operational practice and likewise not sufficient motivation to suggest > "Closest Encloser" as a default policy. > > In my perfect world, implementations would offer a knob to set "Closest > Encloser" for consenting adults but default to "Accept Any Success". > > Matt > > _______________________________________________ > 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
