Re: [DNSOP] draft-tale-dnsop-serve-stale

Warren Kumari <> Tue, 28 March 2017 15:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9942612943A for <>; Tue, 28 Mar 2017 08:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 83dXOcM3mP0S for <>; Tue, 28 Mar 2017 08:31:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 785121293F9 for <>; Tue, 28 Mar 2017 08:31:53 -0700 (PDT)
Received: by with SMTP id i34so67324663qtc.0 for <>; Tue, 28 Mar 2017 08:31:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F2547ah+DzUNUxQ7YxCcbJGJvJrA5ODZ+0/A0SYbGpA=; b=AZyPvW93HRwLgk9d+AHSTTXGkcIU7e9bPGv3h9epnf3IDShtsNSzhwZklCbfDS34MF XtnLbeZOJVS5R3AwjL0TYhujadRQQk1zyYRYKQmiR1FZdNoLPhI++4YzPuLeaF9ArIi+ D/bJzdR62fn2xwH7saS/CKSBDLDQrFdt/HP03yKANMdbzeQGlpaWLvCE9yJJt1qg5eKr 8lx5cu1mlmEIWYiAH6x3zVEfDLdVXvkZomdxYH0oHA5qVVMDKLhMyxEa1zZHlkmbzJp4 LJNqOwvhnZ3fIgwrmByrTUwblktlbzxos5plGR0ssEAB6JNzw41AQxZTq15TMwpJGEN7 6Zjw==
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=F2547ah+DzUNUxQ7YxCcbJGJvJrA5ODZ+0/A0SYbGpA=; b=mmPuJ7YgcCD52F9a5ngjgC0OaBXSyDYy3CtzXSaKWW2bDSz2WhEtR0ioXi0KryYgfH MoZ4fEmN9j4mCYLGfMobxVzwEcxP4NS2LV9s8yayEef9Li6cSQVK8csHaRUscuGrdsjS V8TNdlD/esjCnkC/qBnDBA58DSmmFDmYVzxejtuYTTb7FhBQHJATp4aGmd2/lhWm0wdd vYVYEJF8QJfuLyiznzQ513pYS0lS/7ozhsH5CNw7+d9OdUKLsIKt+/HKQUO/sZWpQKJ3 QnVkNoF/cs/8frjFP3W2AaGJQtWeydQYy4bzYnNnF5u8kV9qd0yEnyHIv0rUqWPhmTui XwDQ==
X-Gm-Message-State: AFeK/H37M9WHTnawDjt6ixXsgAbE2ZXA1psEJa1XoiRQHJD7RK70P1Lr4T2CxsoNE7KJNhXIpwHXFZKzNrQi0MJ+
X-Received: by with SMTP id v43mr27102162qta.263.1490715112370; Tue, 28 Mar 2017 08:31:52 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 28 Mar 2017 08:31:11 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Warren Kumari <>
Date: Tue, 28 Mar 2017 10:31:11 -0500
Message-ID: <>
To: Pieter Lexis <>
Cc: dnsop <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] 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: Tue, 28 Mar 2017 15:31:58 -0000

On Tue, Mar 28, 2017 at 6:20 AM, Pieter Lexis <> wrote:
> On Mon, 27 Mar 2017 18:19:09 -0400
> Jared Mauch <> wrote:
>> I will note there are other implementations out there as well, such as in unbound.  serve-expired configuration directive is available there as well.
> I feel that the authors should attempt to describe the goal of the algorithm and suggest possible limits and describe pitfalls rather than describing the exact algorithm to use.

As one of the authors of both this, and an earlier document with a
different algorithm ( draft-wkumari-dnsop-ttl-stretching ), I think
that the actual algorithm specified is a secondary consideration --
first we need to agree on if the concept / idea is good for general

Assuming that it is a good idea to standardize (perhaps only for
certain use-cases / environments)...

This document has an algorithm which has been deployed, and tuned and
fettled, and works nicely -- however, the environment in which is
being used in may different attributes to the general case, so...

It is entirely possible that:
A: the described algorithm and parameters are perfect for general use, or
B: the described algorithm with different parameters is perfect for general use
C: we need a different algorithm for general use
D: we could describe multiple algorithms, and implementors can select
E: we can just describe what the expected behavior is, and
implementors can determine how to do this.
F: something else

I personally think that B is reasonable -- the algorithm seems to
work, but different (or adjustable) timers might be better for general
recursive servers. But, I'm happy to be wrong -- if the WG adopts the
document it owns it and can choose any of the above...

> This will allow implementers to come up with new and innovative algorithms based on continued measurements.
> I do support an adoption of such a draft in the WG.

Thank you.

> Best regards,
> Pieter
> --
> Pieter Lexis
> PowerDNS.COM BV --
> _______________________________________________
> DNSOP mailing list

I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.