Subject: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-02.txt

From: [email-masked]
Date: Sun, 14 Oct 2018 05:35:06 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : Serving Stale Data to Improve DNS Resiliency
        Authors         : David C Lawrence
                          Warren Kumari
                          Puneet Sood
	Filename        : draft-ietf-dnsop-serve-stale-02.txt
	Pages           : 12
	Date            : 2018-10-14

Abstract:
   This draft defines a method for recursive resolvers to use stale DNS
   data to avoid outages when authoritative nameservers cannot be
   reached to refresh expired data.  It updates the definition of TTL
   from [RFC1034] and [RFC1035] to make it clear that data can be kept
   in the cache beyond the TTL expiry and used for responses when a
   refreshed answer is not readily available.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-serve-stale-02
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-serve-stale-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-serve-stale-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 17 Oct 2018 13:45:44 -0400

> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-serve-stale-02

Here's a summary of the functional updates:

Puneet Sood @ Google added as co-author in the short-lived -01.

A second, simpler EDNS option for signaling is proposed for
discussion.  That makes:

  * Option 1: Capable of identifying exactly which RRSets are stale so
    that a stub can use that information to handle each exactly as
    desired.

  * Option 2: Simplified to only indicate that stale data appears in
    the answer, but not where.

A discussion note for the updated TTL definition, that "capping values
with the high order bit as being max positive, rather than 0, is a
change from [RFC2181]. Also, we could use this opportunity to
recommend a much more sane maximum value like 604800 seconds, which is
one week, instead of the literal maximum of 68 years."

Raised the suggested response TTL on stale records to 30 seconds, from
1 second.  That's in the message from the recursive to its client.

Recommended that refresh attempts from the recursive to the
authorities happen no more frequently than every 30 seconds.

One thing I've realized isn't mentioned in the draft but maybe should
be is that even in the absence of an EDNS option stale data can also
be disabled by the client request if it asks without the recurse flag
on (dig +norec).  Since serve-stale as proposed relies on recursion
failing, if there was no attempted recursion that could have failed
there will be no revisiting the cache to find stale answers.

---

From: Bob Harold <[email-masked]>
Date: Wed, 17 Oct 2018 14:43:01 -0400

>     the answer, but not where.

I would suggest a combination:

OPTION-CODE

OPTION-LENGTH

| D | U | S | V |             RESERVED

STALE-RRSET-INDEX 1

TTL-EXPIRY 1

...

V - verbose flag.  Set to 1 by client if they want the individual
stale-rrset-index's returned.

    Set to 0 if they only want the flags returned.

> one week, instead of the literal maximum of 68 years."

One week sounds good as a default maximum (MAY be configurable).

> 1 second.  That's in the message from the recursive to its client.

30 seconds is good. (May be configurable)

> authorities happen no more frequently than every 30 seconds.

Agreed. (MAY be configurable)

> there will be no revisiting the cache to find stale answers.

Yes, that is worth mentioning, since some users won't immediately think of
that, and implementers should plan for that, so that compatible
implementations work the same.

-- 
Bob Harold