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