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.