Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

Bob Harold <> Mon, 11 September 2017 18:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 339151331A3 for <>; Mon, 11 Sep 2017 11:11:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 BJLeiN12Nsad for <>; Mon, 11 Sep 2017 11:11:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 768B3133191 for <>; Mon, 11 Sep 2017 11:11:27 -0700 (PDT)
Received: by with SMTP id s62so23317625ywg.0 for <>; Mon, 11 Sep 2017 11:11:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7TtKV6jSohYb3y1DYSzzViAaKvUWAOBMjFMgltNf1+E=; b=SXrgZUu2ZdnynglRcJmY1/tCDA4cHU6i44RT39jC0roBUwtTBQXbLElrxl2TwZMTrh LhV/dAh1gp5Ef77jj9RnZMswhcNKnSflwMsiLycsrlB7jiNacWHictBPVQK/1VL/UaCY c8tgoFJCQzWOqhyv9puCRzQB1Ttfk+gvsjsCiNh6LObprlcIkBFBhzleB4qGxT+PPybl CaYQfM2ukJQeNCVlzFUNGl1WoQwNYU84dt6cx8Z2+k5emp9l5WVa2f1Klo9/mlG2b+96 Hy1+LgJWeogmw6U9Ilt/n3RgnBJxvE3y/5Aq/Y8xlNqdLfieblc9w28J6p/5yLw47AXS A54A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7TtKV6jSohYb3y1DYSzzViAaKvUWAOBMjFMgltNf1+E=; b=U1DM3N5lfS+tUepU49YlQ3f/QeLAlXRGqgeI6Ms9AuLYeeimC7YRjgTf/2EAF0WSwu FLGyn8iW2x7bVndTtpZynE5fDCkFyu+xyO7VHflbgmpRqCn6M713Ow/YOepJEUF+r4DC TfzDDCwQnrxuNGx5SqVc3IIP4aM9t+P/3GyBMqxsnnR6wREYa+cQXYCh2mFBoY3wczk/ IlnQpkH0t6etP7fUZT+p/wKKmCJ0gNB1SXuo6o3tDMmIeoxDfDI+FI1SYsLC4cTDYiPA yz0kTi6yEfLMSHHTudUrIe79de4xRghRoCfJT0LwoI742HcMSHhvdgOlvqV14Ypv7PTq 0Mwg==
X-Gm-Message-State: AHPjjUhL1dnB7lYTJxMOUd8qp2nTtbr4E0LRfiQRVsoB7TibOYQ/5GCr wqLkMDzYe6m3bVI7n4WmPzWl7ZUgIP2B1gg=
X-Google-Smtp-Source: ADKCNb7EPRvd8QebxYYV/Wje2cR/LtgnpaIKEL8p1ixjltU1LJZSdIooDuAkUEmsq7HT8OdRMELxf2VAewpdIqq9pe0=
X-Received: by with SMTP id o3mr10971076ywb.396.1505153486327; Mon, 11 Sep 2017 11:11:26 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 11 Sep 2017 11:11:25 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <8295055.TIQDDEhZcU@localhost.localdomain> <> <>
From: Bob Harold <>
Date: Mon, 11 Sep 2017 14:11:25 -0400
Message-ID: <>
To: Mark Andrews <>
Content-Type: multipart/alternative; boundary="001a11491bd4e2ab3b0558eddaac"
Archived-At: <>
Subject: Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Sep 2017 18:11:30 -0000

On Thu, Sep 7, 2017 at 10:07 PM, Mark Andrews <> wrote:

> Part of the problem is that we have one TTL value for both freshness
> and don't use beyond.
> This is fixable.  It is possible to specify two timer values.  It
> does require adding signaling between recursive servers and
> authoritative servers, on zone transfers and update requests.
> You basically add a additional timer field to every record immediately
> after the TTL field.  This is only returned if the client has
> signalled support for the extended field, I suggest using the last
> DNS header bit for this as you can determine how you will parse the
> response base on whether the bit is set in the response or not.
> This field is used to expire records from the cache and its value
> is set to the TTL field if the server has learnt the record from
> server that doesn't support the extension.
> The existing TTL field is used for freshness checking.  When a query
> comes in after that value has expired a freshness check is performed
> similar to the existing prefetches that happen today.  A TTL of 1
> is returned unless the original TTL was 0 in which case 0 is returned.
> New client - new recursive server - new authservers
> 300 86400 IN A
>                 +300 seconds
> 1 86100 IN A
>          (background query is in process)
> Old client - new recursive server - new authservers
> 300 IN A
>                 +300 seconds
> 1 IN A
>          (background query is in process)
> New client - new recusive server - old auth servers
> 300 300 IN A
>                 +300 seconds
>          (record has expired from cache,
>           new query is performed)
> 300 300 IN A
> For UPDATE a replacement opcode would be cleanest way to signal the
> new format is being used.  NOTIMP should be returned by servers
> that don't support the new opcode.
> There will be a few broken servers that just echo back the new
> header bit.
> This way the authoritative servers still control how long records
> are stored for.  Dead servers will get a little bit of traffic until
> the the refresh completes.  If the authorative servers are under
> attack the clients still see a answer.
> The alternative is to perform the refresh query and if it fails to
> complete within X milliseconds return the cached data rather than
> returning the cached data and doing the refresh in the background.
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET:

While I like the idea of a  "don't use beyond" timer, I think it will be a
very long time before it is widely deployed (and actually configured by
zone owners), and therefore won't solve our immediate need.  It would be
great if clients could opt-in, but again I don't see that happening anytime
soon.  So I would start with resolver-operators deciding what seems best
for their clients (which is hat is happening whether we like it or not).
Adding client opt-out/opt-in would be good.   Signalling to say that a
response is stale would be good.  Adding the second timer (both per-RR and
as a zone default value, like TTL is handled) would be good.

On a related note - the SOA "expire" timer tells a slave how long to keep
serving "stale" zone data when the master cannot be reached.  Would that be
a reasonable default value for how long a resolver should serve "stale"
data when the authoritative servers cannot be reached?   (Currently I think
most people set a very high value compared to the TTL.)

Bob Harold