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

Puneet Sood <> Wed, 18 September 2019 15:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D2109120972 for <>; Wed, 18 Sep 2019 08:10:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gNhZrcrpiXQQ for <>; Wed, 18 Sep 2019 08:10:00 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3BC6012098C for <>; Wed, 18 Sep 2019 08:10:00 -0700 (PDT)
Received: by with SMTP id i18so7281210wru.11 for <>; Wed, 18 Sep 2019 08:10:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LzElnKlGwzrDc4oasIok8FBM8BX/2BItxLHVXSW6PbU=; b=OvIGaBaQJVSNJ44904ytt56Q9qwGKzoFBTngFcpGMpRT9QTwk+Tt+yeZfDtvQJKhd6 iiWZW9DP2FqQPm9XvCufWGMqnyv5Rm4eRaPvGgXQsYQOeDR/gxBGiB8+kgrsm4uxb6un uxBeoTuyllmxYfWyfPk8XkKwVr0WFkNfJpP8chI/QqMptTkTIlbuP1C4B8gBwtuRfrqU Z9xs+1i2E7Jg5qHEQ9+SjDK0uMJQnaJuci04a2XzzSFcDEu+hsxypLeGltMHkW5/f9mM SWaNorWSedRxMefe4fYc6Ypuf05jUwfEpqrudvGrw7Qqf6QMUtf94IgM3vT02P0GAdea S0xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LzElnKlGwzrDc4oasIok8FBM8BX/2BItxLHVXSW6PbU=; b=Md5luKEruppyI5kK/4kqU1y3Lkfgru5gEk+3YnSH7VbpTKthPYG+ZEyAOVH9g4Ri+L c9RSAAGjX178xXrosi1Ij4wGARHHQlelRdtYK8JrGP2L2zsMvlrsW7DikhG3bFkO6Npw EzI7uhDbpaQuQxpoj/vBn/M7dkvogupyFo/PJZW2A+dI9hwBggMxO10ZOh9DQtti0D1t 9szwTrvMpkHQ0c/3bdgTBcsM8UbBDj7Bjt3zecOuOwjUrm1FDMyyGtf/JI0M4tKPP1zr Dzegc+wEE1toldq081B2Efom8SX06XeehutNqvwRhn8Q7oKIEI/qLLx5DKhXLfJkYrTA aJxw==
X-Gm-Message-State: APjAAAXRJ7S0mzD36P/aMwILMZnH7Lvb5b72Afe0fC0Zg3ODJ9xm0xn1 Iw1y6SHZ7isTYMM0OVUeBcFttBB1Sx0EZmaMNWtFwg==
X-Google-Smtp-Source: APXvYqyjwxoqwG/H6S84LobjKeJiPEC+QXx3ZeoolAfQAVQWApWf1grHovugjgtYvvIpZOkbHBe8q7sAYLyiWBYNQyI=
X-Received: by 2002:a5d:4241:: with SMTP id s1mr3439706wrr.101.1568819398282; Wed, 18 Sep 2019 08:09:58 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Puneet Sood <>
Date: Wed, 18 Sep 2019 11:09:18 -0400
Message-ID: <>
To: Barry Leiba <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] AD review of draft-ietf-dnsop-serve-stale-07
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: Wed, 18 Sep 2019 15:10:07 -0000


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

On Wed, Sep 11, 2019 at 12:06 PM Barry Leiba <> wrote:
> 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:
>    Several recursive resolver operators, including Akamai, currently
>    use stale data for answers in some way.

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

Addressing along with Stephane's response.

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

Added wording with suggested text from Stephane.


> --
> Barry