IETF Logo Mail Archive

Re: [DNSOP] draft-tale-dnsop-serve-stale

P Vix <paul@redbarn.org> Mon, 27 March 2017 22:00 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 C0FBD128959 for <dnsop@ietfa.amsl.com>; Mon, 27 Mar 2017 15:00:15 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 aDv7PUeBjAPQ for <dnsop@ietfa.amsl.com>; Mon, 27 Mar 2017 15:00:13 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA2D12969F for <dnsop@ietf.org>; Mon, 27 Mar 2017 15:00:00 -0700 (PDT)
Received: from [IPv6:2600:1008:b106:5160:f051:ef71:8d6:e50e] (unknown [IPv6:2600:1008:b106:5160:f051:ef71:8d6:e50e]) (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 3EB6761F9C; Mon, 27 Mar 2017 22:00:00 +0000 (UTC)
Date: Mon, 27 Mar 2017 21:59:58 +0000
User-Agent: K-9 Mail for Android
In-Reply-To: <22745.35498.811412.936974@gro.dd.org>
References: <22745.35498.811412.936974@gro.dd.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----MF14TR04OSLP6TDC5U16DCXZTJRQYQ"
Content-Transfer-Encoding: 7bit
To: dnsop@ietf.org, Dave Lawrence <tale@dd.org>
From: P Vix <paul@redbarn.org>
Message-ID: <69EA837B-77BE-4202-8BFF-0243CF6AAC07@redbarn.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HpeU9g3gQ_j5jLDJR7PaW0UfNcA>
Subject: Re: [DNSOP] 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: Mon, 27 Mar 2017 22:00:16 -0000

I agree to review and comment. Note that I am provisionally negative to the idea itself, and my review may reflect that. Vixie

On March 27, 2017 4:56:58 PM CDT, Dave Lawrence <tale@dd.org> wrote:
>One of the two drafts I wanted to talk about at dnsop today for WG
>adoption was "Serving Stale Data to Improve DNS Resiliency":
>https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/
>
>In short, this describes a method for increasing DNS resiliency by
>treating the inability to refresh data after TTL expiration as a soft
>error, eventually becoming a hard error if the authoritative server
>failures are not remedied.
>
>This basic algorithm has been in use at Akamai for six years now and
>helped us avoid numerous incidents.  I'd implemented it in BIND and
>the patches were recently contributed to ISC.
>
>There are relevant patents in the area held by Google and
>Akamai/Xerocole.  I'm still waiting for the official statement from
>Akamai lawyers about it, but given that we contributed to the code to
>ISC for release under the Mozilla Public License I don't expect any
>really issue here.
>
>Warren and I are hoping for WG adoption.
>
>_______________________________________________
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

v2.23.0 | Report a Bug | By Email