Re: [DNSOP] Last Call: <draft-ietf-dnsop-serve-stale-07.txt> (Serving Stale Data to Improve DNS Resiliency) to Proposed Standard
Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 11 September 2019 18:32 UTC
Return-Path: <ietf-dane@dukhovni.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 8265A120BFD; Wed, 11 Sep 2019 11:32:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 10ChC7Backv6; Wed, 11 Sep 2019 11:32:37 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924D5120C40; Wed, 11 Sep 2019 11:32:37 -0700 (PDT)
Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 7CFE52A4D71; Wed, 11 Sep 2019 14:32:36 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <156821841762.13409.15153693738152466982.idtracker@ietfa.amsl.com>
Date: Wed, 11 Sep 2019 14:32:35 -0400
Cc: draft-ietf-dnsop-serve-stale@ietf.org, dnsop@ietf.org
Reply-To: ietf@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-serve-stale@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <91411A04-4DD6-47D6-A4CC-AD8747B21361@dukhovni.org>
References: <156821841762.13409.15153693738152466982.idtracker@ietfa.amsl.com>
To: ietf@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/k7cPFbu4OCyxtBdVSPhNxpaH9AE>
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-serve-stale-07.txt> (Serving Stale Data to Improve DNS Resiliency) to Proposed Standard
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 11 Sep 2019 18:32:40 -0000
> On Sep 11, 2019, at 12:13 PM, The IESG <iesg-secretary@ietf.org> wrote: > > 'Serving Stale Data to Improve DNS Resiliency' <draft-ietf-dnsop-serve-stale-07.txt> It looks to me like the list of resolvers that implement "Serve Stale" in Section 3 contains a typo. Should "Know" be "Knot"? A number of recursive resolver packages (including BIND, Know, OpenDNS, Unbound) provide options to use stale data. I am a bit puzzled by the lack of text that motivates treating TTLs with the high bit set as positive? Why is this desirable, and why in this draft? What is the connection between TTLs with the high bit set and Serve Stale? If some resolver inadvertently returns stale data whose TTL has expired, it might return a negative TTL, and treating that as "0" seems safer than as 137 years (likely then capped to 7 days). Finally, in security considerations, there's no mention of the potential security impact of stale negative responses. Specifically, stale denial of existence of newly published TLSA records can delay their visibility to clients, and degrade transport security until the fresh records are finally available. With RFC7672 MTA-to-MTA SMTP, a ServFail answer would avoid the downgrade and either use a different MX host or defer the delivery until such time as fresh records become available. That said, this exposure exists only in a limited time window when TLSA records are initially published. -- Viktor.
- [DNSOP] Last Call: <draft-ietf-dnsop-serve-stale-… The IESG
- Re: [DNSOP] Last Call: <draft-ietf-dnsop-serve-st… Viktor Dukhovni
- Re: [DNSOP] Last Call: <draft-ietf-dnsop-serve-st… Tony Finch
- Re: [DNSOP] Last Call: <draft-ietf-dnsop-serve-st… Viktor Dukhovni
- Re: [DNSOP] Last Call: <draft-ietf-dnsop-serve-st… Stephane Bortzmeyer
- Re: [DNSOP] Last Call: <draft-ietf-dnsop-serve-st… Viktor Dukhovni
- Re: [DNSOP] Last Call: <draft-ietf-dnsop-serve-st… Puneet Sood