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

Steve Crocker <steve@shinkuro.com> Sun, 29 July 2018 19:59 UTC

Return-Path: <steve@shinkuro.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9FD130EE3 for <dnsop@ietfa.amsl.com>; Sun, 29 Jul 2018 12:59:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=shinkuro-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aCqzlhsc4eP for <dnsop@ietfa.amsl.com>; Sun, 29 Jul 2018 12:59:25 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96048130E72 for <dnsop@ietf.org>; Sun, 29 Jul 2018 12:59:24 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id j5-v6so10489856wrr.8 for <dnsop@ietf.org>; Sun, 29 Jul 2018 12:59:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shinkuro-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=P+U57XOisrGySBFy5Pax+J/zXmcpnq/KxOU3fXATVDE=; b=vOyIMEjJzrRhW2eidn+FM9U85tfte7eu6t4fCVOeU7o9aPdfN/cj8nAB00LSifdmRy a3GDcilTyfM854PACsuuOBNwFp2cuthjS3vgwG+PL0Hcod8FPupG2CNc0j27bAQ0sGjq 6jF1XLcLf9Tgfw9PA5r3sLOWgqPsIOgkSTmfKPyF77862cmEHpRljldOxFBFUNsOrN75 jC3ulBlK0Y+e0JXwnIvHioh7EmmoEb7VnJwEytGIbqxIPoePXLeSFV1QyjJ+8AfCnDYB xWS+oeSpTYP9vCVDNrnhBozezYRC55PH6aTMGnzSt2VBdq74KjW0WEvyq+C5/eTVpvG5 ARUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=P+U57XOisrGySBFy5Pax+J/zXmcpnq/KxOU3fXATVDE=; b=FiojVBaI8RwAFunqJa8lXNKys+UW3c5nkf/BKHA5emN/I0VtwA3lWdUc8jSr4RbmNW hWDnCC44TTnhpReH0+1igwngJ0qhBJaFSEFmBZ+BjtN92foAFtIflczmkj3Re7VxJvuN Mi+Fj9WEb+UYxQRaIJG2BsQMaCAC1wDnCCjlsMsXel8I+z7C6Gk/nJ3bMMQ4xasm/Mqh erWvSCWVZwPaELLe8+FiNGt79yuW//1oBolaIVqm7Gn3LBlbNKfzT7vwronvziy2P9KQ dTEpjjE0atjedd8pyWPBKQHLMzgSUwCV+96V+/nA1NyxoqJ0QIvPjYAClBM7MekUfmca zQnQ==
X-Gm-Message-State: AOUpUlH0CT2uzPtPu829yFs7NUl/VrNausX9MD0Cxal7p8P9zCAmXX+o vy6O41cTuCT7wIGxIwFArUL3N4vnsliBWkiAMIEThcTA6vY=
X-Google-Smtp-Source: AAOMgpf/iata4KpKdHXzGCfiphux9bsDP/fGbodCLz0noAOtVL1/wG8s4YvWPHuc5gPL1xgE7RYOyjPhULBWNnJm6Rc=
X-Received: by 2002:adf:c383:: with SMTP id p3-v6mr14779654wrf.68.1532894362976; Sun, 29 Jul 2018 12:59:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a1c:c48:0:0:0:0:0 with HTTP; Sun, 29 Jul 2018 12:59:21 -0700 (PDT)
In-Reply-To: <03FAA51D-C9EE-4619-91A7-636C29D2D6F1@hopcount.ca>
References: <20180729155014.C8F2C20030CD40@ary.qy> <5F1A8568-02D6-4145-8ECE-59385C31DA7C@shinkuro.com> <CAJhMdTP-J8qaGQE1rTQQ6KUC0fdtHpJeztr9GaY2n-WGpYm8Pg@mail.gmail.com> <CABf5zvLq4PUiVYk3-sBZ-HF-Ecp7eSzBKhm-Fw=2+80OOYQ0ug@mail.gmail.com> <03FAA51D-C9EE-4619-91A7-636C29D2D6F1@hopcount.ca>
From: Steve Crocker <steve@shinkuro.com>
Date: Sun, 29 Jul 2018 12:59:21 -0700
Message-ID: <CABf5zvJJgrK7ATfwV2hhg8rH4TUM16TH69LmOq6V=qGDeU+TRA@mail.gmail.com>
To: Joe Abley <jabley@hopcount.ca>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fbdc42057228c736"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/7PDJEk-ZYot9ufitbwtQMqF-nhw>
Subject: Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Jul 2018 19:59:28 -0000

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 <jabley@hopcount.ca> wrote:

> Hi Steve,
>
> On Jul 29, 2018, at 15:09, Steve Crocker <steve@shinkuro.com> 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