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

Reply via email to