Re: [DNSOP] opportunistic semi-authoritative caching (Re: DNSOP Call for Adoption - draft-tale-dnsop-serve-stale)
Paul Vixie <paul@redbarn.org> Fri, 08 September 2017 05:28 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 19AD31330CC for <dnsop@ietfa.amsl.com>; Thu, 7 Sep 2017 22:28:32 -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 zDDlYKCxz6l9 for <dnsop@ietfa.amsl.com>; Thu, 7 Sep 2017 22:28:31 -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 379871330C8 for <dnsop@ietf.org>; Thu, 7 Sep 2017 22:28:31 -0700 (PDT)
Received: from localhost.localdomain (dhcp-182.access.lah1.vix.su [24.104.150.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id AC2A061FA2; Fri, 8 Sep 2017 05:28:30 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: Joe Abley <jabley@hopcount.ca>
Cc: dnsop@ietf.org
Date: Thu, 07 Sep 2017 22:28:30 -0700
Message-ID: <8183111.Lxug4lBFgO@localhost.localdomain>
Organization: Vixie Freehold
User-Agent: KMail/4.13.0.25 (Linux/4.12.9-200.fc25.x86_64; KDE/4.14.30; x86_64; ; )
In-Reply-To: <FAC87A99-5558-4369-ADC0-57E2B7BF0429@hopcount.ca>
References: <59B1F467.9010308@redbarn.org> <FAC87A99-5558-4369-ADC0-57E2B7BF0429@hopcount.ca>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/u_qVgGjLXZNv2zZ0BpUxia-Scsg>
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: Fri, 08 Sep 2017 05:28:32 -0000
On Thursday, September 07, 2017 11:08:43 PM Joe Abley wrote: > >> Would you see the querying application informing you of intent via > >> > >> option code saying "If I'm unable to talk to you once TTL expires, I may > >> serve your last known good answer"? > > > > i don't think so. if it was "may i serve your last good answer?" then yes. > > but with it as "i may" and the ? outside the quotes as shown above, then > > no. > There's a recursive operator with whom Jared and tale may be familiar that > some time ago had a feature called "pinning" whereby particular names that > were known to be availability-sensitive (their non-availability caused > great disturbance in the helpdesk) could be "pinned" -- that is, in the > recursive server, they were configured never to expire from the cache. They > could be refreshed, but they would not expire. the domain name system is the world's first and only distributed, coherent, autonomous, reliable database. if someone decides, for the sake of their help desk, to use my data for longer than the TTL i signaled, that's an affront to both coherence and autonomy, and they should stop. 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. vixie
- [DNSOP] opportunistic semi-authoritative caching … Paul Vixie
- Re: [DNSOP] opportunistic semi-authoritative cach… Joe Abley
- Re: [DNSOP] opportunistic semi-authoritative cach… Paul Vixie
- Re: [DNSOP] opportunistic semi-authoritative cach… Joe Abley
- Re: [DNSOP] opportunistic semi-authoritative cach… Tony Finch
- Re: [DNSOP] opportunistic semi-authoritative cach… Paul Vixie
- Re: [DNSOP] opportunistic semi-authoritative cach… Evan Hunt
- Re: [DNSOP] opportunistic semi-authoritative cach… Paul Vixie
- Re: [DNSOP] opportunistic semi-authoritative cach… Matthew Kerwin
- Re: [DNSOP] opportunistic semi-authoritative cach… Evan Hunt
- Re: [DNSOP] opportunistic semi-authoritative cach… Paul Vixie
- Re: [DNSOP] opportunistic semi-authoritative cach… Evan Hunt
- Re: [DNSOP] opportunistic semi-authoritative cach… Paul Vixie
- Re: [DNSOP] opportunistic semi-authoritative cach… Vladimír Čunát
- Re: [DNSOP] opportunistic semi-authoritative cach… Brian Dickson