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

George Michaelson <ggm@algebras.org> Thu, 07 September 2017 22:03 UTC

Return-Path: <ggm@algebras.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 68BF1132FE7 for <dnsop@ietfa.amsl.com>; Thu, 7 Sep 2017 15:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com
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 S8zDrsd9eY7y for <dnsop@ietfa.amsl.com>; Thu, 7 Sep 2017 15:03:28 -0700 (PDT)
Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A479D132FEC for <dnsop@ietf.org>; Thu, 7 Sep 2017 15:03:28 -0700 (PDT)
Received: by mail-vk0-x232.google.com with SMTP id m142so1462148vkf.2 for <dnsop@ietf.org>; Thu, 07 Sep 2017 15:03:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=StoeH0qHSimAeZxQOBcxIPMQTpNCRYpFIPUhatDwBAM=; b=JdSeHzoXZ/ehmJCBu5SFO96orwRpKb/mvJR+Gqy2NTuQt5ihz7dMIgTpIuab1iCB11 Ica1uTPRe7A3LN+2ilbuCrczMRdJa+d4tRAzVV0W9cLttqyNMy37t1yIhEqqwX93wZ30 OYBwM8+MbYVSqRJGQmdLZzM447JggEPVLSoVJAt2giL3GpTcpgmbbJM+MqlkGno9G0+U KBl0UcNt3+xgoO15bpgprHQH10rcbdIqxFbKZkGfyEvSU8ai9Mgh00IT0si/7T6EL7MS 9OxxZi5Ce7mfLFCD1KfBL5EGwKn2Hel9FG/19xiOF1R5Pz5XrmSk9JYZNICjST9ZvHrl ZRTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=StoeH0qHSimAeZxQOBcxIPMQTpNCRYpFIPUhatDwBAM=; b=JnIS/4RTFLjX9int4pf7lyJNVjy9cq09pPCA3dXydXnpSb5i/fQBZyxTSUuxy5ZmqJ HIHy+du1F8pQjJ06sUXHfeHrDVr8IgQLIkMHdJ/uhzuqaLkeeO+iUdVqJ2SHwg2/OTQw luKHB0T2xYKJX5/Edb5vDSXiflPCihwF3e2KIRGj9nOyjS6kZgt8wPi8U5liTPsFxZe5 EZHUs1WArloJB0BiNbLnkCNjCq2hIa+zUn4tAaxKnc9MDlVdpA5x7Q8ku2ue4VLAIQAt EGgKTFTQblYbXPxMeE7pxvsOLhs7I40bJ0Q/scImL/eNz1BmVtqIjbOyNJflf5oEpgit BU3g==
X-Gm-Message-State: AHPjjUhO6yNlH5B4aJC6o+dQWa8XGNBwh3aRRWcUUBbBU1vlP8KTx9OB MoYjitpAcYSLU/vwrRUA/sw63oiQtm3xe74=
X-Google-Smtp-Source: AOwi7QCYaLSKYuvxsSiKdZ1j4a+eseh9pen9lDyzwlEgOwUkNywg70/VLN6EhhB1Fw/khQ0ZKGOaBU5UYRXDZ7KYc18=
X-Received: by 10.31.63.204 with SMTP id m195mr500367vka.111.1504821807450; Thu, 07 Sep 2017 15:03:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.84.78 with HTTP; Thu, 7 Sep 2017 15:03:27 -0700 (PDT)
X-Originating-IP: [2001:dc0:2001:210:80cf:4544:2cf8:7f7d]
In-Reply-To: <8826934.gJBl6qSRLR@localhost.localdomain>
References: <CADyWQ+FHDHcmq-mr0BCHS5A8yvaOQmhTjve1_DmZN6vAc=BKyA@mail.gmail.com> <ybltw0emmvh.fsf@wu.hardakers.net> <CAJE_bqc9zD3Um2oWri7K3L10=MWrUrKpCHpmUGAADKUmFmPYCg@mail.gmail.com> <8826934.gJBl6qSRLR@localhost.localdomain>
From: George Michaelson <ggm@algebras.org>
Date: Fri, 8 Sep 2017 08:03:27 +1000
Message-ID: <CAKr6gn1rF1BphX3iQ3_HkrOLZBLR0uKo-uiaWD_pUgCEonCzkg@mail.gmail.com>
To: dnsop WG <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/JRPOz7imHEY_0vJ_8hXVDG2HhOI>
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 22:03:32 -0000

add client-intent signalling, and irrespective add server signalling
of action, and I could be there.

I'd support adoption.

On Fri, Sep 8, 2017 at 6:42 AM, Paul Vixie <paul@redbarn.org> wrote:
> 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
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop