Hi Matthew ＆ Paul, Good question, :-)
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.* Even if both Authoritative server and Recursive server support DNSSEC+NSEC aggressive, when will they configure default dns query with dnssec ? (for NSEC agreesive cached deduced wildcard) As old features, why DNSSEC + NSEC is not forthcoming global deployed ? (maybe an old question, tired of discussing) Both Authoritative server and Recursive server consider about the DNSSEC validation cost / DDoS. Authoritative's Zone Enumeration risk, NSEC -> NSEC3 -> NSEC5 -> ??? other reasons... For example, Google likes to support some optimized protocols/features, such as QUIC, SPDY, ... dig @ns1.google.com xxxxxxxx.google.com +dnssec , only return NXDOMAIN. Matthew Pounsett <m...@conundrum.com>于2017年8月11日周五 下午10:39写道： > On 11 August 2017 at 01:02, Lanlan Pan <abby...@gmail.com> wrote: > > >>> We can get even better behavior from aggressive NSEC use. Here are >>> advantages of aggressive NSEC use: >>> - does not require changes to existing authoritatives or signed zones >>> - less fragile (if we consider manual SWILD specification as an option) >>> - supports wildcards with nodes below it >>> >> >> Yes, aggressive NSEC use has advantages if: >> 1) AUTH give NSEC RR. >> 2) Every Intermediate Resolver supports DNSSEC validating and the NSEC >> aggressive use. >> > > It sounds like you're assuming that SWILD would be supported by caching > servers that do not support DNSSEC or NSEC aggressive use. Why do you > expect implementers would adopt SWILD before adopting these much older > features? > > > >> >> Yes, the aggressive NSEC is limited to DNSSEC-signed zones. I think that >>> is okay: New features are provided only by the latest version of >>> the protocol. >>> >> But: >> 1) many wildcards occupy the Resolver cache, with no nodes below them. >> 2) many wildcards AUTH not give NSEC RR. >> 3) many resolvers not support DNSSEC validating, not to mention NSEC >> aggressive use. >> >> On the view of new feature, SWILD can be an alternative simpler choice to >> deploy. >> > -- 致礼 Best Regards 潘蓝兰 Pan Lanlan
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
