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
