a long lived mechanism is in-band, not using labels in the DNS or query payload.
bits in the EDNS space, indicating yes-no and where more than bits are needed, explicit field:value definitions will get us further. because they demand code change they can only inform us of the future. warrens mechanism admits of being able to use a cronjob from a host, through a resolver, to indicate you know, as the admin, what you say it can do. -g On Mon, Jul 20, 2015 at 6:02 PM, Michael StJohns <m...@nthpermutation.com> wrote: > I've taken a brief look at Warren's as yet unpublished draft (attached to > the meeting agenda) and had a few comments. > > My major objection to this type of approach is that it doesn't pass the > "cui bono" test. Basically, the major benefit from this is not to the > clients who have to implement the "query occasionally so the root knows > what I know", but to the root operators (or not even them maybe). The > cost to implement this on the client side is pretty close to the cost to > implement 5011 (and in fact it uses similar timings). And generally, I > would guess that the folk that are going to implement this are the ones > already doing 5011 and not all of them, so we're not really going to get a > complete data set at the root. (Logically, if you had to implement this, > would you concentrate on something that will actually allow automatic > rollovers or on something that's just reporting you can't do it?) [Note: > My belief is that it's not as simple as just upgrading to the new > software. I believe that this will need to be manually turned on by the > resolver owner to deal with the possible data leaking threat rather than > just being on once you update. And I almost say "no" to "do you want to > help improve our software" types of prompts] > > Then there's the root operator problem and the data reduction problem. > The root ops all have to set up support for this new option - hopefully > that will be minor, but adding new things to the root servers is always > fraught. Once they do, they have to have sufficient logging space to > collect the data and be willing to do it over a period of time. Finally, > someone has to be willing to do the data reduction. All of these operation > concerns need at least tentative buy in from the Root zone ops and probably > an assignment of resources at ICANN for the data reduction. (And someone > noted privacy issues at the microphone). > > Then there's what do you do with the data when you get it? Considering > there's no hope at all that everyone will implement this, we will ALWAYS > get an answer that says "someone hasn't done everything they need to do to > roll the root" of some vague size. > > And then there's the sunset problem. This is only useful (if at all) for > a short period of time, and then it becomes extraneous. e.g. For a while > before the first rollover and then for a while after. At that point > we've either had a disaster or we haven't had one. Its unclear that long > term collection of the data adds value vs causing enough pain on the client > side to get them to "do the right thing" with respect to automated updates. > > The above are comments on the utility of the data collection part. I'm > going to think a little more on whether or not this could provide similar > security guarantees as does 5011 if it were used for trust anchor > rollover. I'm not sure that it can deal with even a single key compromise > and that was one of the basic design criteria driving 5011. > > Later, Mike > > > > > > _______________________________________________ > 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
