Re: [DNSOP] What can be done with the DNS and what should be done elsewhere [draft-klensin-dns-function-considerations]

John C Klensin <john-ietf@jck.com> Wed, 07 June 2017 14:16 UTC

Return-Path: <john-ietf@jck.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 90AE71270A3 for <dnsop@ietfa.amsl.com>; Wed, 7 Jun 2017 07:16:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 BEDradm7fB2G for <dnsop@ietfa.amsl.com>; Wed, 7 Jun 2017 07:16:39 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A204E12EC68 for <dnsop@ietf.org>; Wed, 7 Jun 2017 07:16:39 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1dIblE-000Lhc-8e; Wed, 07 Jun 2017 10:16:36 -0400
Date: Wed, 07 Jun 2017 10:16:30 -0400
From: John C Klensin <john-ietf@jck.com>
To: Tony Finch <dot@dotat.at>, Stephane Bortzmeyer <bortzmeyer@nic.fr>
cc: dnsop@ietf.org
Message-ID: <399EC4C37472864C97500D1E@PSB>
In-Reply-To: <alpine.DEB.2.11.1706071236150.21595@grey.csi.cam.ac.uk>
References: <20170606200437.GA23271@sources.org> <alpine.DEB.2.11.1706071236150.21595@grey.csi.cam.ac.uk>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/N4CuG8GI6CZhYzRpxkJL1_RfjqE>
Subject: Re: [DNSOP] What can be done with the DNS and what should be done elsewhere [draft-klensin-dns-function-considerations]
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 07 Jun 2017 14:16:41 -0000


--On Wednesday, June 7, 2017 12:48 +0100 Tony Finch
<dot@dotat.at> wrote:

> Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
>> 
>> > The DNS model of master and slave servers, with the latter
>> > initiating updates based on TTL values,
>> 
>> The slaves don't use the TTL values, don't they?
> 
> That section is a bit weird.
> 
>                                                      Efforts
> to use very    short (or zero) TTLs to simulate
> nearly-simultaneous updating may    work up to a point but
> appear to impose very heavy loads on servers    and
> distribution mechanisms that were not designed to accommodate
>    that style of working.  Similar observations can be made
> about    attempts to use dynamic, "server-push", updating
> rather than the    traditional DNS mechanisms.  While those
> might work better than    ordinary short TTLs and update
> mechanisms as specified in RFC 1034    and 1035, they imply
> that a "master" server must know the identities    of (and
> have real time access to all of) its slaves, defeating many
> of the advantages of caching, particularly those associated
> with    reduction of query traffic across the Internet.
> 
> It doesn't mention the venerable and widely-deployed NOTIFY,
> and seems to muddle up replication to authoritative servers
> and cacheing in resolvers. If it is supposed to be talking
> about somthing of current relevance, it should refer
> explicitly to draft-ietf-dnssd-push or whatever other
> developments the author has in mind.

It is indeed muddled.  Thanks to both of you for pointing that
out.  I will try to fix.  The references are another issue -
while I've tried to pick up references as I went along, there
are _many_ things that have been discussed, proposed, or even
adopted that I haven't picked up, partially because I just don't
follow some of the work closely enough.  Pointers to them would
be appreciated, as would text to go with them.

At least in retrospect, someone closer to DNS issues than I am
should have written the document I hope this will become and
written it several years ago.   No one did.  The IAB Identifier
Program could have taken it on, but they didn't (mostly, AFAICT,
for good reasons) and the IAB has now closed it.    I don't
believe that posting a note to the IETF (or DNSOP) list saying
"someone should do this" has ever been particularly productive,
especially not in the last few years.  WGs like DNSOP appear to
be focused on responses to demands for services and behavior
from the DNS that can be defined, implemented, and deployed in
the relatively short term (as I think they should be -- see
earlier response to Stephane).  Because I am concerned about
weakening the DNS for its original function and the amount of
time and energy that appears to be going into "solutions" that
just cannot work (the quest for fully-equivalent names, not even
limited to pointers to subtrees, comes to mind), my view is that
we need to start asking fundamental questions about how far it
is sensible to push the boundaries of the DNS, saying in essence
about many things that "we need a naming system and database for
something, the DNS is out there, so let's put it in the DNS".
So, driven by some other issues, including concerns that some of
the proposals to "fix" the DNS (or just "fix" IDNs) could weaken
it for other purposes, some apparent real disconnects in the
broader Internet community about the purpose of the DNS and
criteria for DNS success, and the degree to which I believe that
some of the requirement are real but that trying to make
proposed solutions fit in the DNS prevents work on more
comprehensive and effective solutions, I finally started
writing.    Again, if anyone with the right background wants to
be more actively involved, I would really welcome that.

best,
   john