Re: [DNSOP] Last Call: <draft-ietf-dnsop-serve-stale-07.txt> (Serving Stale Data to Improve DNS Resiliency) to Proposed Standard

Viktor Dukhovni <> Sun, 15 September 2019 16:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4746912018D; Sun, 15 Sep 2019 09:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WMTp3f2HWJuD; Sun, 15 Sep 2019 09:27:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9F723120125; Sun, 15 Sep 2019 09:27:35 -0700 (PDT)
Received: by (Postfix, from userid 1001) id DDE8D2AB29B; Sun, 15 Sep 2019 12:27:34 -0400 (EDT)
Date: Sun, 15 Sep 2019 12:27:34 -0400
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <>
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-serve-stale-07.txt> (Serving Stale Data to Improve DNS Resiliency) to Proposed Standard
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 15 Sep 2019 16:27:38 -0000

On Sat, Sep 14, 2019 at 02:31:14PM +0200, Stephane Bortzmeyer wrote:

> On Wed, Sep 11, 2019 at 02:32:35PM -0400,
>  Viktor Dukhovni <> wrote 
>  a message of 37 lines which said:
> > Finally, in security considerations, there's no mention of
> > the potential security impact of stale negative responses.
> It's not true, the last two paragraphs of section 10 do it. May be, as
> reported by an AD, add that an attacker may dDoS authoritative name
> servers just to exploit this possibility? 

I read those, but there's no mention (perhaps unnecessary?) of the
security impact of stale *negative* (i.e. NXDOMAIN or NODATA) for
TLSA records used in Opportunistic DANE TLS (e.g. RFC7672).

When DANE TLSA records are *initially* published for a domain, and
the RRSIGs of previously published NSEC/NSEC3 records are not yet
expired (typically 14 to 30 days), stale NXDOMAIN RRs + signatures
for the TLSA records downgrade SMTP Opporunistic DANE TLS to just
opportunistic TLS.  The exposure goes away once the TLSA records
have been in place long enough for all stale NSEC records to expire.

Granted, perhaps the limited exposure timeframe makes this corner
case not worthy of discussion, but it is differs materially from
the stale *positive* cache cases (address RRs, ...), and could be
worth mentioning, if not too "esoteric".