Re: [DNSOP] opportunistic semi-authoritative caching (Re: DNSOP Call for Adoption - draft-tale-dnsop-serve-stale)

Paul Vixie <paul@redbarn.org> Sat, 09 September 2017 01:43 UTC

Return-Path: <paul@redbarn.org>
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 483431320CF for <dnsop@ietfa.amsl.com>; Fri, 8 Sep 2017 18:43:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 Fki2aGsCuIzl for <dnsop@ietfa.amsl.com>; Fri, 8 Sep 2017 18:43:56 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4849212EC30 for <dnsop@ietf.org>; Fri, 8 Sep 2017 18:43:56 -0700 (PDT)
Received: from [10.199.2.125] (unknown [50.235.236.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 986DD61FA2; Sat, 9 Sep 2017 01:43:54 +0000 (UTC)
Message-ID: <59B34758.8020105@redbarn.org>
Date: Fri, 08 Sep 2017 18:43:52 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.18 (Windows/20170825)
MIME-Version: 1.0
To: Evan Hunt <each@isc.org>
CC: dnsop@ietf.org, Joe Abley <jabley@hopcount.ca>
References: <59B1F467.9010308@redbarn.org> <FAC87A99-5558-4369-ADC0-57E2B7BF0429@hopcount.ca> <8183111.Lxug4lBFgO@localhost.localdomain> <20170909003248.GD44967@isc.org>
In-Reply-To: <20170909003248.GD44967@isc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zTupF9H334ig4epSSbBc2mzTuMo>
Subject: Re: [DNSOP] opportunistic semi-authoritative caching (Re: DNSOP Call for Adoption - draft-tale-dnsop-serve-stale)
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: Sat, 09 Sep 2017 01:43:57 -0000


Evan Hunt wrote:
> On Thu, Sep 07, 2017 at 10:28:30PM -0700, Paul Vixie wrote:
>> if they really need this, they should provide a method by which i can specify
>> both a TTL and an Expiry, and i will consider publishing both values, and
>> if i do, then they can use them the way i intend them. because as i said,
>> autonomy.  it's my data, and my TTL.
>
> I agree, and yet, a DDoS can make your data unavailable for refresh
> through no fault of yours, which makes a resolver operator appear to be
> broken through no fault of theirs, which makes them want very much to
> be able to do this bad thing.

understood. this is the same reasoning that led comcast to argue for the 
ability to turn off dnssec for important zones (like jpl.nasa.gov) who 
had fubar'd their keys and/or signatures and/or delegated signers.

> So, TTL stretching goes on the pile with NXDOMAIN redirection, tools that
> can be used for censorship, and all the other regrettable things that we
> implemented anyway dammit.

not so fast. nxdomain redirection is an attack. censorship is an attack. 
i don't think you mean to group ttl stretching in with those attacks. 
because if you do, then we agree, it is an attack, and ought not be 
done, and certainly ought not be standardized in any form.

> (I do like the idea of advertising a separate expiry value though.)

i think if we're going to put something into the 20-year deployment 
funnel we should treat the fixed costs as high and demand more benefits. 
that's where the proposal up-thread came from.

-- 
P Vixie