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

George Michaelson <> Thu, 07 September 2017 22:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68BF1132FE7 for <>; Thu, 7 Sep 2017 15:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S8zDrsd9eY7y for <>; Thu, 7 Sep 2017 15:03:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A479D132FEC for <>; Thu, 7 Sep 2017 15:03:28 -0700 (PDT)
Received: by with SMTP id m142so1462148vkf.2 for <>; Thu, 07 Sep 2017 15:03:28 -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 :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;; 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 with SMTP id m195mr500367vka.111.1504821807450; Thu, 07 Sep 2017 15:03:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 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: <> <> <> <8826934.gJBl6qSRLR@localhost.localdomain>
From: George Michaelson <>
Date: Fri, 08 Sep 2017 08:03:27 +1000
Message-ID: <>
To: dnsop WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] DNSOP Call for Adoption - 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: 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 <> 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:
> vixie
> _______________________________________________
> DNSOP mailing list