On 12 August 2017 at 04:29, Lanlan Pan <abby...@gmail.com> wrote: > 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 confess it was a rhetorical question. All of the major implementations already support DNSSEC. 8198 doesn't have an implementation status section, but there's every reason to think the major implementations will have support within a version of two. A quick survey of a few issues databases shows that at least Knot is already working on it. That is a significant head start; SWILD support without DNSSEC support can't happen in any significant way, and SWILD support without support for 8198 doesn't seem likely. As for operator adoption, the incentives are all wrong for this to actually get used. Recursive operators already have a very low operational bar to turn on DNSSEC and get the same benefit to their cache. In both cases (SWILD and DNSSEC) they rely on the authoritative operator opting in before that benefit can be realized. Authoritative operators may choose to use DNSSEC because it will secure their zone, and if recursive operators also have 8198-capable name servers then the workload for both authoritative and recursive is reduced for all terminal names. With SWILD, there is no direct benefit to the authoritative operator, as far as I can see. Given that the only benefit to using SWILD is to the recursive operator, what is the motivation for the authoritative operator to add complexity to their deployment by adopting it? Traditional wildcards work fine for them. To make the adoption problem worse, it appears as if SWILD is more limited in its use than traditional wildcards. For example, I don't see how you could occlude an SWILD record with a more-specific domain name, as you can with traditional wildcards. Here's a common scenario based on the example from the draft: @ 86400 IN SWILD _ _ 3600 IN CNAME map.bar.net. * 600 IN CNAME _ dev 600 IN CNAME map.dev.bar.net. How does SWILD behave when a client queries for dev? According to the draft, the authoritative server would return the SWILD record at the apex. An SWILD-aware recursive server seems like it would ignore the CNAME returned for dev and instead use the CNAME for _, which is not what the operator intended. > > *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) > We already know that a year ago 26% of all end users were behind some sort of validating resolver, a number which continues to climb as more ISPs turn on validation, and more users switch to things like Google Public DNS <https://labs.apnic.net/presentations/store/2016-06-27-dnssec.pdf>. This isn't an ideal deployment status so long after DNSSEC was standardized, but it's a long way ahead of SWILD. You'll need to have a very compelling argument for me to believe that SWILD is both more useful than DNSSEC and more likely to be deployed at any kind of scale that would make a difference. I just don't see it. Add to that Paul's point that we would very much like to encourage DNSSEC adoption, I don't see why we'd add support for an alternative technology that accomplishes a subset of its features.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
