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 <p...@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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
