Hi Paul, Maybe it makes a mountain out of a molehill. "Give to the emperor the things that are the emperor's, and to God the things that are God's.“, we can seperate security issue and subdomain wildcard cache issue.
I think, SWILD has no influence on DNSSEC deployment : 1) If recursive wants to deploy DNSSEC, it is almost impossible because of NSEC/NSEC3 aggressiveuse Wildcards. *Security need is the greatest motivation behind DNSSEC depolyment.* 2) If recursive doesn't want to deploy DNSSEC, it is almost impossible because of SWILD. Imagine that, there is no SWILD to give precise subdomain wildcard information from authoritative, recursive can use random subdomain detect method to make cache optimization, which was described in DNS Noise: Measuring the Pervasiveness ofDisposable Domains in Modern DNS Traffic <http://astrolavos.gatech.edu/articles/dnsnoise-dsn2014.pdf>. But the rate of "DNSSEC + NSEC + default dns query with DNSSEC” has influnence on subdomain wildcard cache issue if we only accept unique solution depend on it. Paul Vixie <p...@redbarn.org>于2017年8月12日周六 下午11:42写道： > On Saturday, August 12, 2017 8:29:45 AM GMT Lanlan Pan wrote: > > ... > > > > SWILD is a feature just for recusive cache optimization, only dealing > with > > the wildcard subdomain issue (with no nodes below). > > DNSSEC + NSEC aggressive is security feature, with cryptographic contents > > such as KSK/ZSK/NSEC/NSEC3/NSEC5/... > > > > My assumption is: *we can give recursive server an alternative solution > for > > wildcard subdomain cache issue, not need to depend on DNSSEC.* > > Authoritative server just simply add one SWILD RR, not much deploy cost. > > Recursive server can add SWILD support if it has an interest in wildcard > > subdomain cache optimization, it is OPT-IN. > > > > *I don't expect implementers would adopt SWILD 100% before adopting > > DNSSEC+NSEC aggressive. Just give an alternative choice, implementers can > > decide adopting or not, before or after, we won't pre-select for them.* > > we do, though, and we must. DNSSEC development began in 1996, and > deployment > is stalled due to lack of motivation. it is the IETF's position that > DNSSEC is > a public good in that it will enable a general world-wide security level > that > has always eluded the Internet. > > any DNSSEC feature that we decide to offer separately ("a la carte") is > both a > missed opportunity to increase the deployment of DNSSEC, and a > self-inflicted > wound that deliberately further stalls that deployment. > > noting that DNSSEC as a protocol is of atrociously low quality ("it's > crap"), > i am in no way defending the design itself. however, it does work, and we > would be acting contrary to our own best interests ("folly") if we took up > anything like SWILD, or allowed anything like SWILD on the individual > track. > > failing that level of commitment, the IETF ought to kill DNSSEC altogether. > > this is very similar to the "shall we had IPv6's features to IPv4, since > V6 is > taking so long to deploy, and these features are badly needed?" debate. > > vixie > -- 致礼 Best Regards 潘蓝兰 Pan Lanlan
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
