Subject: [DNSOP] AD review of draft-ietf-dnsop-serve-stale-07

From: Barry Leiba <[email-masked]>
Date: Wed, 11 Sep 2019 12:06:23 -0400

I am handling this document as responsible AD, as Warren is a
co-author and so must recuse himself.  I’m not sure how I missed the
publication request, but miss it I did, and thanks to Warren for
pinging me.

Thanks for a very well-written and clear document.  I have only some
minor editorial comments and a couple of questions, all of which can
be addressed along with any last-call comments that come along.  I’ll
request last call right after I send this message.

— Abstract —

   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 chain of “and also”s feels awkward; I would remove the first one,
so “…TTL expiry, updates RFC 2181…”.  (I might remove the second
“also” as well, as “and suggests” is fine without it.)  This text is
also in the Introduction, so whatever change is made in the Abstract
should be made in the Introduction too.

— Introduction —

   This document proposes that the definition of the TTL be explicitly
   expanded to allow for expired data to be used in the exceptional

This isn’t wrong, but for a standards-track document we would usually
say, “This document expands the definition of the TTL to explicitly
allow for…”.  It will be published as a Proposed Standard, so I guess
the “proposed” part can just come from there, yes?

— Section 3 —

   This is again not [RFC2119]-normative
   language, but does convey the natural language connotation that data

In my ongoing effort to disabuse people of the idea that language has
to have BCP 14 key words in order to be normative, I would prefer that
this say, “This wording again does not contain BCP 14 key words,
but…,” because I do believe the quoted text is normative.

   Several recursive resolver operators currently use stale data for
   answers in some way, including Akamai.

Misplaced modifier:
NEW
   Several recursive resolver operators, including Akamai, currently
   use stale data for answers in some way.
END

   collective operational experience is that it provides significant
   benefit with minimal downside.

The antecedent to “it” is unclear (it could refer to Apple MacOS or
the Happy Eyeballs algorithm or mDNSResponder).  Better to say, “…is
that using stale data can provide….”

— Section 4 —

      If the data is unable to be
      authoritatively refreshed when the TTL expires, the record MAY be
      used as though it is unexpired.

I wonder if it makes sense to be more explicit here that one isn’t
meant to keep using expired data forever, but is expected to keep
trying to refresh it.  So, maybe?:

NEW
      If the data is unable to be
      authoritatively refreshed when the TTL expires, the record MAY be
      used as though it is unexpired until an authoritative refresh is
      successful.
END

— Section 5 —

“implementation dependent” needs a hyphen: “implementation-dependent”

— Section 6 —

   fact that no other RCODEs which a resolver normally encounters makes
   any assertions regarding the name in the question

Number agreement: “make any assertions”  (I would also change “which”
to “that”, but I’m picky about using “that” to introduce restrictive
clauses.)

   existing cache state.  Some authoritative servers operators have said

Either “authoritative server operators” or “authoritative servers’
operators”; I think the former.

   their servers are responding with errors like ServFail instead of
   giving true authoritative answers.  Implementers MAY decide to return
   stale answers in this situation.

It might be good for the last paragraph in Section 4, with the
“SHOULD”, to have a forward reference to this explanation.

— Section 10 —

Is another possible new security consideration that bad actors could
DDoS authoritative servers with the explicit intent of having stale
cached information used for longer, perhaps to extend the life of a
cache-poisoning attack or some such?

-- 
Barry

---

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

On Wed, Sep 11, 2019 at 12:06:23PM -0400,
 Barry Leiba <[email-masked]> wrote 

>       used as though it is unexpired until an authoritative refresh is

I think your proposed text is worse since it contradicts the current
draft, which limits the time during which you can serve stale answers
"The maximum stale timer should be configurable, and defines the
length of time after a record expires that it should be retained in
the cache.  The suggested value is between 1 and 3 days. [Even if you
cannot contact the authoritative servers, my note.]"

> cache-poisoning attack or some such?

Yes, seems right. Also reported by Viktor Dukhovni during the last
call. May be add at the end of section 10 "Attackers could be incited
to dDoS authoritative servers with the explicit intent of having stale
cached information used for longer. But if they have this capacity,
they probably could do much worse things than prolongating old data."

---

From: Barry Leiba <[email-masked]>
Date: Sat, 14 Sep 2019 08:46:12 -0400

> cannot contact the authoritative servers, my note.]"

Yes, true.  So maybe add "for a period of time or" before "until" in
my suggestion.  Or see if you can come up with better wording.  If you
really think it doesn't need to be qualified here because the rest of
the document takes care of it, I won't push it further.  I just think
it best to say *something* here that doesn't make it sound like an
entirely open-ended "MAY".

> they probably could do much worse things than prolongating old data."

Other than that "prolongating" isn't a word (use "prolonging the life
of"), that's probably OK.  Maybe add that the benefit outweighs the
risk, or some such, and then we'll see what the Sec ADs think.

Barry

Barry

---

From: Puneet Sood <[email-masked]>
Date: Wed, 18 Sep 2019 11:09:18 -0400

Barry,

Thanks for the detailed review. The editorial comments and security
considerations comment will be addressed in a new draft I will be
pushing.

> should be made in the Introduction too.
DONE

> the “proposed” part can just come from there, yes?
DONE

> but…,” because I do believe the quoted text is normative.
DONE

>    use stale data for answers in some way.
DONE

> that using stale data can provide….”
DONE

>       used as though it is unexpired until an authoritative refresh is

Addressing along with Stephane's response.

> “implementation dependent” needs a hyphen: “implementation-dependent”
DONE

> to “that”, but I’m picky about using “that” to introduce restrictive
DONE

> operators”; I think the former.
DONE

> “SHOULD”, to have a forward reference to this explanation.
DONE

> cache-poisoning attack or some such?

Added wording with suggested text from Stephane.

-Puneet

---

From: Puneet Sood <[email-masked]>
Date: Wed, 18 Sep 2019 11:14:07 -0400

> entirely open-ended "MAY".

I would prefer to not make the text in this paragraph too long since
other sections go into detail on the conditions when the stale data
can still be used. How about the following?

"If the data is unable to be authoritatively refreshed when the TTL expires,
the record MAY be used as though it is unexpired as long as certain
conditions are met. See the Example Method and Implementation
Considerations sections for details."

> risk, or some such, and then we'll see what the Sec ADs think.

Added wording in the second paragraph of the Security Considerations section.

-Puneet

---

From: Barry Leiba <[email-masked]>
Date: Wed, 18 Sep 2019 08:18:34 -0700

Puneet, that sounds perfect.  Thanks for reconsidering this.

Barry