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

From: [email-masked]
Date: Thu, 24 Oct 2019 12:10:15 -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 "Ace" Kumari
                          Puneet Sood
	Filename        : draft-ietf-dnsop-serve-stale-09.txt
	Pages           : 13
	Date            : 2019-10-24

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, updates RFC 2181
   by interpreting values with the high order bit set as being positive,
   rather than 0, and suggests a cap of 7 days.

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-09
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-serve-stale-09

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

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: Thu, 24 Oct 2019 15:35:46 -0400

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

This revision addressed the one remaining outstanding issue that Brian
Carpenter raised in the Gen-ART Last Call Review.  The following text
was added to explain why a TTL with the high-order bit set is now
handles as a large positive number (then capped down) rather than a
negative number (and treated as zero).

    As for the change to treat a TTL with the high-order bit set as
    positive and then clamping it, as opposed to [RFC2181] treating it as
    zero, the rationale here is basically one of engineering simplicity
    versus an inconsequential operational history.  Negative TTLs had no
    rational intentional meaning that wouldn't have been satisfied by just
    sending 0 instead, and similarly there was realistically no practical
    purpose for sending TTLs of 2^25 seconds (1 year) or more.  There's
    also no record of TTLs in the wild having the most significant bit set
    in DNS-OARC's "Day in the Life" samples.  With no apparent reason for
    operators to use them intentionally, that leaves either errors or
    non-standard experiments as explanations as to why such TTLs might be
    encountered, with neither providing an obviously compelling reason as
    to why having the leading bit set should be treated differently from
    having any of the next eleven bits set and then capped per Section 4.

I also removed the phrasing about 2181's handling of this issue as a
"curious suggestion".  I recognize it could have an unintended
negative connotation against the original authors, though when I wrote
the sentence originally I meant it only with its neutral denotation.
It was curious to me only because no rationale was provided as to why
that particular choice had been made, despite the current assertion
that it was obvious as to why.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Oct 2019 11:23:42 +1300

Hi Dave,

Thanks. I think that covers it. I still suspect that the original reason
was concern about int versus uint confusion, but the new text is fine.

Regards
   Brian Carpenter