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

[George Michaelson <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop