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

Paul Vixie <paul@redbarn.org> Wed, 29 March 2017 19:10 UTC

Return-Path: <paul@redbarn.org>
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 E8742129541 for <dnsop@ietfa.amsl.com>; Wed, 29 Mar 2017 12:10:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 2yI5ZBsQnO5j for <dnsop@ietfa.amsl.com>; Wed, 29 Mar 2017 12:10:31 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66E44129510 for <dnsop@ietf.org>; Wed, 29 Mar 2017 12:10:31 -0700 (PDT)
Received: from [10.199.15.136] (unknown [12.219.129.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 4827E61F9C; Wed, 29 Mar 2017 19:10:29 +0000 (UTC)
Message-ID: <58DC06A4.7060502@redbarn.org>
Date: Wed, 29 Mar 2017 12:10:28 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.12 (Windows/20170323)
MIME-Version: 1.0
To: Shumon Huque <shuque@gmail.com>
CC: Warren Kumari <warren@kumari.net>, dnsop <dnsop@ietf.org>, Pieter Lexis <pieter.lexis@powerdns.com>
References: <22745.35498.811412.936974@gro.dd.org> <69EA837B-77BE-4202-8BFF-0243CF6AAC07@redbarn.org> <B18C12F9-D3EF-46D7-90D4-E58CEA575966@puck.nether.net> <20170328132050.018870d5@aardbei.mobile.plexis.eu> <CAHw9_iLOnKz_0c95FBzo0vt5n0TARwDYYYGvTafaQRcnZev64w@mail.gmail.com> <58DA9B68.2020007@redbarn.org> <CAHPuVdXMqkKwxQiQ4Npsy+ucrzFVh=3ZR1HqyVQgLG+g_siHvg@mail.gmail.com>
In-Reply-To: <CAHPuVdXMqkKwxQiQ4Npsy+ucrzFVh=3ZR1HqyVQgLG+g_siHvg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TFspzXGeVva_FUmEGZzgFd01RR8>
Subject: Re: [DNSOP] 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: Wed, 29 Mar 2017 19:10:33 -0000


Shumon Huque wrote:
> On Tue, Mar 28, 2017 at 12:20 PM, Paul Vixie <paul@redbarn.org
>     ...
> 
>     speaking of resimprove, i hope you'll include in this draft the idea of
>     using delegation-TTL as a delegation-recheck interval, and using an
>     authoritative NXDOMAIN from the delegator as proof that you need to run
>     an "rm -rf" in your cache.
> 
>     i bring this up because we need to be able to kill more cached data
>     faster-- the opposite of stretchiness-- for abuse control reasons. if
>     you're going to soften the signaling for cache expiration, you really
>     ought to balance that out with this simple method of also hardening it.
> 
> Perhaps you've forgotten (since you participated in the discussions), but
> the portion of resimprove that dealt with expunging cached data below the
> NXDOMAIN boundary was rescued, expanded on, and published as
> RFC 8020 ("NXDOMAIN: There Really is Nothing Underneath") late last
> year.

yes, i know that RFC 8020 includes both the idea of stopping downward
searches when a cached NXD is encountered, and the idea of pruning (like
"rm -rf" in UNIX) existing cache entries when an NXD is received. those
changes, in addition to QM, will do much to pacify the DNS data model.

however, it's equally vital for malicious DNS content takedown, that the
part about remembering the delegation NS TTL and using it to
periodically revalidate the existence of that delegation, also be
brought forward. this becomes even more vital if we're making TTL
stretchy, and i would be happy to see tale's document cover this topic.

in other words, the prune-and-stop on NXD must be given a new source of
NXD, which is delegation revalidation. i'd love it if delegations all
had a one hour or less TTL, at least for public suffixes.

-- 
P Vixie