In message <59f8d666.9000...@redbarn.org>, Paul Vixie writes: > > > Paul Wouters wrote: > > On Tue, 31 Oct 2017, Edward Lewis wrote: > > > ... > >>>> ConfiguredKey-trumps-DS > ... > >> > >>> It better, it is the only working solution :) > >> > >> Can you elaborate...why would it be the "only" "working" solution? > > > > The idea of the hierarchical model has always been that if you don't > > trust the parent, you can configure keys at the level you want. If > > I don't trust the root, I can put in a trust anchor for .ca. If I > > don't trust .ca, I can put in a trust anchor for nohats.ca. > > +1. and this is how DLV worked, for that reason.
DLV is deepest match. It also was was only consulted if the answer validated as insecure with configured trust anchors. No trust-anchor above a name means it validated as insecure. The same data could be used to configure trust anchors which are used instead of DS records. Named currently doesn't support this. > > Allowing "any" key to override that would make me vulnerable to all > > my parents, even if I don't want to trust them. I don't want .ca to > > be able to put in a DS for internal.nohats.ca in their TLD and steal > > my traffic. Now, when I run that zone internally and sign it internally, > > and put in the trust anchor, this zone can never be stolen from me by > > a parent. > > > > This has always given the parent keys an enigma problem. Get abused once > > and we will bypass you. Trusting "any" key will no longer allow me to > > untrust a particular zone cut. > > +1. all policy is local. > > -- > P Vixie > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
