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

Vladimír Čunát <vladimir.cunat+ietf@nic.cz> Thu, 07 September 2017 12:14 UTC

Return-Path: <vladimir.cunat@nic.cz>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD2B132D62 for <dnsop@ietfa.amsl.com>; Thu, 7 Sep 2017 05:14:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upC8LPJV-gxu for <dnsop@ietfa.amsl.com>; Thu, 7 Sep 2017 05:14:44 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA05E1326FE for <dnsop@ietf.org>; Thu, 7 Sep 2017 05:14:43 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:d8cd:12ff:fe4f:872c] (unknown [IPv6:2001:1488:fffe:6:d8cd:12ff:fe4f:872c]) by mail.nic.cz (Postfix) with ESMTPSA id 4533960B80 for <dnsop@ietf.org>; Thu, 7 Sep 2017 14:14:42 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1504786482; bh=/sTxNv8ARvZv36kf2IFeCRsSBM/6CAik+c7fkNYbUuI=; h=To:From:Date; b=WrbSoV1qZy9Z0sXipwnFrAxn5mLa0pANVrxaRKd0Yj8zMiJQCvVT5PYiuQGFRpaIn 5IkeBc0nYKbNiX89vBiGpZuyBLhWGgCrX+OIp7J6V5sZ5ljvd7yhTVV8NtFJFKfThv S1HpDucl5iC3u0BK3P1IWk7dFlXJioBi/1G/3Dy0=
To: dnsop@ietf.org
References: <CADyWQ+FHDHcmq-mr0BCHS5A8yvaOQmhTjve1_DmZN6vAc=BKyA@mail.gmail.com>
From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <vladimir.cunat+ietf@nic.cz>
Message-ID: <2acc3d1b-7f7f-c74e-e77a-007d48b3cfb0@nic.cz>
Date: Thu, 7 Sep 2017 14:14:42 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CADyWQ+FHDHcmq-mr0BCHS5A8yvaOQmhTjve1_DmZN6vAc=BKyA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cqF6lIfe_11dCqlsQW9P3gTulW8>
Subject: Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Sep 2017 12:14:45 -0000

On 09/05/2017 09:25 PM, tjw ietf wrote:
> This starts a formal Call for Adoption for draft-tale-dnsop-serve-stale
I do support the adoption.  We plan to support some kind of
stale-serving in knot-resolver soon, so
I'm certainly willing to review and perhaps contribute some suggestions.

Still, I wonder about the intended level of vagueness of the text.  Is
it meant that the final RFC will leave (larger) unspecified corners?

One issue I see is the case when servers for some zone don't respond but
they (are expected to) only provide a *lead* to the final answer, e.g. a
delegation or a CNAME elsewhere.  In that case it seems useless to wait
without
action until the client timer fires, because we (typically) need at
least one more round-trip to get the final answer.  It might be also
good to touch the issue of negative caching of non-responsivity for some
short time (rfc2308.7.2) and consequently serving stale records
*immediately*.  There's a tradeoff between stale-ness and many resolvers
legitimately hammering servers that are/were under attack (or simply
broken).

I personally think that the length of stale-serving should derive from
the original TTL in some way, as very short TTL suggests the value is
more likely to change and operator doesn't mind increased traffic.
(Raised at IETF99, I think.)  The security section should perhaps stress
that the technique may effectively extend the range of validity in
RRSIGs, as served by validating resolvers (unless I misunderstand the
draft).  I suppose the AD flag might get zeroed in that case, but that
seems not to make much difference in practice (and we *do* want the
stale records, right?)

--Vladimir