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

Paul Vixie <paul@redbarn.org> Thu, 07 September 2017 20:42 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 1EEE3132FDD for <dnsop@ietfa.amsl.com>; Thu, 7 Sep 2017 13:42:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8D6jy3UrNxo4 for <dnsop@ietfa.amsl.com>; Thu, 7 Sep 2017 13:42:50 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51BFA132FDB for <dnsop@ietf.org>; Thu, 7 Sep 2017 13:42:46 -0700 (PDT)
Received: from localhost.localdomain (104-7-65-172.lightspeed.sntcca.sbcglobal.net [104.7.65.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 3318061FA2 for <dnsop@ietf.org>; Thu, 7 Sep 2017 20:42:46 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: dnsop@ietf.org
Date: Thu, 07 Sep 2017 13:42:45 -0700
Message-ID: <8826934.gJBl6qSRLR@localhost.localdomain>
Organization: Vixie Freehold
User-Agent: KMail/4.13.0.25 (Linux/4.12.9-200.fc25.x86_64; KDE/4.14.30; x86_64; ; )
In-Reply-To: <CAJE_bqc9zD3Um2oWri7K3L10=MWrUrKpCHpmUGAADKUmFmPYCg@mail.gmail.com>
References: <CADyWQ+FHDHcmq-mr0BCHS5A8yvaOQmhTjve1_DmZN6vAc=BKyA@mail.gmail.com> <ybltw0emmvh.fsf@wu.hardakers.net> <CAJE_bqc9zD3Um2oWri7K3L10=MWrUrKpCHpmUGAADKUmFmPYCg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qUANGYhCyuPt_4ar5kuupnO6LYg>
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 20:42:52 -0000

On Thursday, September 07, 2017 11:33:22 AM 神明達哉 wrote:
> ...
> 
> If we don't work on a proposal like this, I'd love to see a specific
> counter proposal that doesn't violate the current protocol
> specification (i.e., using a cached answer beyond its TTL) and still
> avoids resolution failure when authoritative servers are forced to be
> non-responsive due to huge scale DoS attacks.

i think the actual problem statement is broader, and that by solving for this 
narrow version, we would lose the complexity/capability tradeoff -- we'd add 
more state and more signaling at a cost higher than what we would get for it.

it's a general reachability problem not specifically ddos problem. reasons for 
not being able to refresh data in a cache include ddos, but also backhoes, 
wire cutters, squirrels, circuit breakers, and bad design/provisioning.

i think the right answer will look like a miniature version of IXFR/AXFR and 
NOTIFY, such that a cache can register its intent to become a partial stealth 
secondary server, and by participating, an authority server can both indicate 
its willingness to have this done, and possibly remember what was transmitted 
so as to facilitate subsequent cache invalidation or zone change notification 
messaging. one could even imagine a dns cookie exchange at the outset, to help 
authenticate later messages. sort of a super-lightweight session protocol.

when the DNS was first popularized, we were using a lot of computers with less 
than four megabytes of memory and fewer than a million instructions per 
second, and our links were thought fast if 56K DDS, or super-fast if 1.544M T1 
or even 2.0M E1. this drove choices of how to encode, how to compress, where 
to synthesize, and whether to authenticate. all of those choices should be up 
for reconsideration now.

if our _vision_ as a technical community is to have little chunks of semi-
authoritative data cached in stealth-like secondary-like places, and then kept 
up to date, then we should pursue that, because moore's law and the 
privatization and commercialization of the internet have made it now 
practical.

if we lack a vision and we're going to pursue small discrete targets of 
opportunity based on the business problems faced by each industry participant, 
then we'd be making hairball soup, and i'd ask that we not.

see also:

http://queue.acm.org/detail.cfm?id=1647302

vixie