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

From: The IESG <[email-masked]>
Date: Wed, 11 Sep 2019 09:13:37 -0700

The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Serving Stale Data to Improve
DNS Resiliency'
  <draft-ietf-dnsop-serve-stale-07.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2019-09-25. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

   This draft defines a method (serve-stale) for recursive resolvers to
   use stale DNS data to avoid outages when authoritative nameservers
   cannot be reached to refresh expired data.  One of the motivations
   for serve-stale is to make the DNS more resilient to DoS attacks, and
   thereby make them less attractive as an attack vector.  This document
   updates the definitions of TTL from RFC 1034 and RFC 1035 so that
   data can be kept in the cache beyond the TTL expiry, and also updates
   RFC 2181 by interpreting values with the high order bit set as being
   positive, rather than 0, and also suggests a cap of 7 days.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/ballot/

The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/3589/
   https://datatracker.ietf.org/ipr/3014/
   https://datatracker.ietf.org/ipr/3590/
   https://datatracker.ietf.org/ipr/3059/
   https://datatracker.ietf.org/ipr/3573/
   https://datatracker.ietf.org/ipr/2967/
   https://datatracker.ietf.org/ipr/2968/

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 Sep 2019 14:32:35 -0400

> On Sep 11, 2019, at 12:13 PM, The IESG <[email-masked]> 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.

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Sep 2019 20:22:37 +0100

> and treating that as "0" seems safer than as 137 years (likely

I guess this change is a result of trying to fill in the missing parts of
what a TTL means. I don't think this change is necessary: the draft could
be a bit less fussy without it.

The draft says:

   [RFC2181] aimed to provide "the precise definition of the Time to
   Live", but in Section 8 was mostly concerned with the numeric range
   of values and the possibility that very large values should be
   capped.  (It also has the curious suggestion that a value in the
   range 2147483648 to 4294967295 should be treated as zero.)

Which implies to me that the authors didn't spot the TTL bug in RFC 1035
that RFC 2181 was fixing with the curious suggestion.

RFC 1035 is inconsistent about the signedness of TTLs, so RFC 2181 fixed
it by specifying that TTLs are to be treated as unsigned (as usual for DNS
data) but must only use the range of positive signed 32 bit numbers.

Quoting from RFC 1035 to point out the curious copy and paste bug:

[ snip ]

3.2. RR definitions

3.2.1. Format

All RRs have the same top level format shown below:

[ snip ]

TTL             a 32 bit signed integer that specifies the time interval
                that the resource record may be cached before the source
                of the information should again be consulted.

[ snip ]

4.1.3. Resource record format

The answer, authority, and additional sections all share the same
format: a variable number of resource records, where the number of
records is specified in the corresponding count field in the header.
Each resource record has the following format:

[ snip a second copy of the same info ]

TTL             a 32 bit unsigned integer that specifies the time
                interval (in seconds) that the resource record may be
                cached before it should be discarded.

[ snip ]

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rattray Head to Berwick upon Tweed: Southwesterly veering northwesterly later,
4 or 5, increasing 6 at times, becoming variable 3 or 4 for a time in south.
Slight or moderate, occasionally smooth in south. Rain later, otherwise mainly
fair. Good, occasionally poor later.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 Sep 2019 15:41:21 -0400

On Wed, Sep 11, 2019 at 08:22:37PM +0100, Tony Finch wrote:

> [...]

These are the wire format for "TTLs in motion" (on the wire, in DNS
*messages*), where the residual TTL of a cached record could perhaps
become negative (and yet, sent in an answer).  Yes, it is unfortunate
the RFC1035 has two conflicting definitions.

If we allow unsigned TTLs in excess of 68 years for "TTLs at rest"
(in authoritative zone files), then I guess we're compelled to
tolerate them when copied into "TTLs in motion" in messages on the
wire, but my preference (had I the cycles to follow the WG phase
of this draft) would have been to make TTLs signed both at rest and
in motion, at the cost of ruling out use of TTLs >= 2^31s in zone
files.

That is, it may be safer to treat 68+ year TTLs (don't do that!)
as already expired, than to treat potentially "negative" TTLs as
large positive TTLs.

-- 
	Viktor.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 14 Sep 2019 14:31:14 +0200

On Wed, Sep 11, 2019 at 02:32:35PM -0400,
 Viktor Dukhovni <[email-masked]> wrote 

> 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?

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 15 Sep 2019 12:27:34 -0400

> 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".

-- 
	Viktor.

---

From: Puneet Sood <[email-masked]>
Date: Wed, 18 Sep 2019 12:06:45 -0400

> in Section 3 contains a typo.  Should "Know" be "Knot"?
Done

> and treating that as "0" seems safer than as 137 years (likely

Discussed separately.

> limited time window when TLSA records are initially published.

Added wording for negative caching to the first paragraph of "Security
Considerations".

-Puneet