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

Bob Harold <> Wed, 17 October 2018 18:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3AFE9130DD7 for <>; Wed, 17 Oct 2018 11:43:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 vWYlUhm6TDlt for <>; Wed, 17 Oct 2018 11:43:15 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 06327128C65 for <>; Wed, 17 Oct 2018 11:43:14 -0700 (PDT)
Received: by with SMTP id s10-v6so20600694lfc.9 for <>; Wed, 17 Oct 2018 11:43:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=92WnqGWDTz+I99TdeTcUYBnWNnhORozY8tRmdlMgmHY=; b=dqfYPoOkDYeVK2KoPQXwiFb3rlh92qOSCKab8Dc1SossxjIl05jwOe5Txq+g/WLxpK JKKCxlzSxZbzhbbnxMuLBrV2d0QBHWAlzrHAiH8vZmZjMOexxrRms3jobM+KgNu65Ziz LbSf+yIepQSBVTYnwoZt8UHfNI3+kLYMhqvo5uz3+Fc17SpJucsnv44eb/WtGOuNsDc4 /K7zsOKfEiVYYma1/EXW3rAxS2f2gdgNhNNAjmwMgqeyJLS7yw6SyRvS5yFfKUV8oYDr UQJZ0QaplXk8ytLZqj7ip5s9yUpthcZzYzHI9OIKkk5TeN7lGbDj/1N52PGFUFYHNwHL A+Bg==
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; bh=92WnqGWDTz+I99TdeTcUYBnWNnhORozY8tRmdlMgmHY=; b=iv7gWF0KvTfleXFVokqXDpzfI0bfTbpIW+Gl4YZXnlnhyAbfxlZ3FaPUJT9Xa2aDxz CAH4JFaHzCgHGrGeRkGbYRfYWSl3MU8x1loJ3yqAiyatM2LsroI9cDJpj+MMFT5WlHQ7 32uWF2w1H9viX7IiACTI8LalU/nylcfsK6syDvj3j1l8waheWCam3V9OWuCphc8aRk4Z KnvhOLgQSPo7F8wAFdGf9w3+Sqm9Twi8ytbk2Gw/Cj2sM8RhtMrfw2KKM2BapqjmB1l2 32E5eOzoDW6EUUBYGY5M5+muHJQa/yralrUvQmtHfiJViWHDsNDz7pcTWmrvWRxs9+q5 N2kA==
X-Gm-Message-State: ABuFfojdwh81JGqA5NZVA2n2l9AWbbMAl/U4neDyF44gRkbl0w+KBEIu BdCDkYCXNWGzRXTNjRpzrocOrE68OGbRQf+XlQ6ypXsC5Mc=
X-Google-Smtp-Source: ACcGV60MAwpkYr7oShxEPpnOVb2hrFVycdHQqXGP4puzkAED+/k/xVJkyAq7WG9PKrYmo361ux9KaMKb/PJBY8DHIi8=
X-Received: by 2002:a19:df54:: with SMTP id q20-v6mr11945985lfj.130.1539801793008; Wed, 17 Oct 2018 11:43:13 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Bob Harold <>
Date: Wed, 17 Oct 2018 14:43:01 -0400
Message-ID: <>
To: Dave Lawrence <>
Content-Type: multipart/alternative; boundary="000000000000e5ac8b0578710a86"
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-02.txt
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, 17 Oct 2018 18:43:18 -0000

On Wed, Oct 17, 2018 at 1:45 PM Dave Lawrence <> wrote:

> writes:
> > A diff from the previous version is available at:
> >
> 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.

I would suggest a combination:



| D | U | S | V |             RESERVED




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.

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

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

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

30 seconds is good. (May be configurable)

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

Agreed. (MAY be configurable)

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

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