Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[Joe Abley <[e-mail]>]

Hi Steve,

I fully agree that the kinds of things I was waving my hands about are science projects at best, and so far from ready for informed standardisation in dnsop that it seems silly even typing that phrase.

However, you were speculating about the future in your reaction to some of the commentary here, and inferring that the draft under discussion (or some of the discussion surrounding it) was pointing in a silly direction.

I was just trying to illustrate that there are more possible directions. Many of them may well be silly, but it's a little early to pass judgement, I think.


Joe

> On Jul 29, 2018, at 15:59, Steve Crocker <[e-mail]> wrote:
> 
> Joe,
> 
> Thanks.  You've mentioned several things tagged with "it would be nice to have."  Each of these has both (a) one or more assumptions about a problem that seeking to be addressed and (b) the implication of a fairly massive architectural change.  These need a deeper and better organized discussion than can be done on this list.  This is really IAB territory or something similar, in my opinion, and the starting point is a careful delineation of the problems before we engage in specific solutions.  Your experience, perceptions and judgments are top notch, but it will take time and work to get everyone else on the same page.  (Or not.)
> 
> Meanwhile, there is already an evolution toward local service of the root zone.  It seems to be there are two relevant threads to pursue.  One is how best to support it, and the other, picking up on your point, is to understand what problems, defects, etc. there might be as more and more recursive resolvers start to serve the root zone.
> 
> Speaking for myself, I'm not opposed, in principle, to thinking about fresh designs and radical changes where it's appropriate.  For example, I have made comments in the past and will be making more comments in the future about the whois system.  But with respect to the evolution of the root service, I'm not in agreement that we should be entangling it with the much larger architectural issues you're raising.
> 
> Steve
> 
> 
>> On Sun, Jul 29, 2018 at 12:44 PM, Joe Abley <[e-mail]> wrote:
>> Hi Steve,
>> 
>> On Jul 29, 2018, at 15:09, Steve Crocker <[e-mail]> wrote:
>> 
>> > As an individuals, you, I, or anyone else, can do whatever we like, of course.  On the other hand, as system designers we presumably look at the overall system and try to put in place an operational structure that anticipates and meets the likely needs of the users.
>> 
>> Agreed!
>> 
>> > The present and long-standing system provides the recursive resolvers with well-oiled and highly effective solutions to (a) finding the root servers and (b) getting highly reliable and highly responsive answers from them.
>> 
>> This is true. However, there are some disadvantages of the current system that are worth thinking about when we consider alternatives, such as the privacy implications of having all resolvers call home to a set of well-known servers and the aggregate cost of engineering and operations that has gone into making the root system as resilient as it is.
>> 
>> I have spoken in the past in opposition to the idea that slaving the root zone on resolvers was a desirable end-state; I think it leaves operational gaps that we should want to fill. Being able to validate the contents of the zone and have software react appropriately (without human operator intervention) when zone data is found to be stale or inaccurate obviates many of my concerns.
>> 
>> Perhaps there is a future where the root server system was preserved only to serve legacy clients, whilst more modern software had a diversity of options in addition to that fall-back.
>> 
>> I think the root zone is a convenient starting point for these kinds of discussions, but I think the scope could be wider. Maybe one day the DNS protocol (for all zones, not just the root zone) is only comonly used for communications between stub and resolver, where we have the deployed base with the longest tail, and where capacity planning and attack resistance is a different kind of problem because all your traffic generators are on-net. Perhaps the database problem of replicating authoritative data into resolver caches is solved in different ways.
>> 
>> It would be nice if end-users didn't have to rely upon authoritative servers being up in order to resolve names; it would be nice if there wasn't a small set of targets against which the next memcached-scale attack could be used to take us back to 21 October 2016; it would be nice if the integrity of the naming scheme didn't ultimately rely upon the deployment of BCP38.
>> 
>> If such a mechanism relied upon DNSSEC to ensure integrity of data in the absence of plausible channel authentication, availability of zones might be aligned with DNSSEC deployment, which would give the Alexa 500 a(nother) reason to sign their zones.
>> 
>> There are lots of things to think about here. I don't think clinging to the status quo in terms of infrastructure or institutions is necessarily a good idea, although I do agree with the idea of preserving legacy compatability and incremental change.
>> 
>> 
>> Joe
>