I’d argue that there are a magnitude more resolvers than browsers in the world. There are lots of devices that have a resolver but don’t have a browser. Think of all the smart light bulbs. They all need to be able to update their trust anchors. DNSSEC deployment is still in its infancy.
> On 1 Jul 2021, at 05:26, Michael StJohns <m...@nthpermutation.com> wrote: > > Peter et al - > > It might be useful to review RFC 4986 - > https://www.rfc-editor.org/rfc/rfc4986.html - Requirements Related to DNS > Security Trust Anchor Rollover - to understand what the problem requirements > were/are before resurrecting this discussion again. If the requirements > have changed, then perhaps we need a new solution, but we should probably > update 4986 before tossing 5011. > > Peter - > > WRT to your analogy to the CA system, I will note that browser clients (where > the trust anchors are embedded for the CA) are not even close to being > updated in the same manner as recursive resolvers (not simply "DNS clients") > and many resolvers are used to provide services within various small and > large organizations rather than being owned and updated by a single person. > For one thing, there are orders of magnitude more browers than there are > resolvers. For another, resolvers are rarely updated automatically. What > would be interesting is to get some idea of the set of resolvers with no > active management being performed on them - including software updates. > > Mike > > > > On 6/30/2021 2:59 PM, Peter van Dijk wrote: >> Hello DNSOP, >> >>> I propose replacing rfc5011-security-considerations with a short document >>> deprecating 5011 in its entirety. I am happy to write text for that, if >>> there is an appetite - when the WG queue is small enough! >> I see this ruffled some feathers. Here's a more nuanced version. >> >> I feel that 5011, for the purpose of root key rollovers, is the wrong tool, >> -especially- combined with the trust anchor signaling that various resolver >> stacks sent to the root. Lack of clarity about where various signals came >> from, combined with some interesting bugs in implementations, has led to a >> lot of wild goose chases, and it would not surprise me (but I cannot prove) >> that bad data is what delayed the first roll for so long. Not actual >> problems predicted by the data; just bad data. (I have mentioned before that >> I think the trust anchor signalling was a mistake too, and any calls for >> 'more of this' are 'calls for more bad data' and we do not need more bad >> data.) >> >> I feel that the right mechanism for root key distribution is software >> distributors. This is working fine for the CA system, and with keys >> announced far enough in advance, should work fine for DNSSEC. Software >> distributors have solved this problem; they are very good at distributing >> things; I suggest we let them solve this for us. >> >> rfc5011-security-considerations is a good document, and I apologise for >> targeting it unfairly - my problem with 5011 is as above. Given my next two >> point, it probably makes sense to publish rfc5011-security-considerations. >> >> With heaps of 5011 'client' implementations out there, I am in no way >> proposing that root rolls happen in a way that that software could not >> follow along. I am only proposing that we write down that 5011 is not the >> best fit for the problem, and recommend against more client implementations >> of it *for the purpose of root key rolls*. >> >> I think (can't find it right now) that somebody mentioned that 5011 has its >> place outside of the root key system, inside enterprises. I'm inclined to >> disagree, but do not feel entirely capable of judging that. If (again, when >> there's WG bandwidth) we draft a document about why 5011 is a bad fit for >> the root, perhaps somebody can contribute text about the level-of-fit for >> other use cases. >> >> Kind regards, > > > _______________________________________________ > 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
