Hi Matthew, Thanks for your detailed reply, :-)
Matthew Pounsett <m...@conundrum.com>于2017年8月13日周日 上午12:31写道： > 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. > We know that we will have a Swiss Army knife (DNSSEC) in the future, can we also put a Fruit knife (SWILD) in the kitchen now? > > 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. > Authoritative will be directly benefit, save cost, reduce wildcard subdomain response laterncy. As methioned in the draft : "Intermediate Nameservers' cache hit rate will rise, avoid to query Authoritative Nameserver for the same wildcard domain configuration." Imagine that Recursive Resolver knows that SWILD RR of wildcard domain "*. foo.com". In TTL time, if Recursive Resolver receives " yyy.foo.com/zzz.foo.com/..." A RR query, it can directly return this subdomain wildcard response without send dns queries to Authoritative. Traditional wildcards work no so fine for them, it make recursive send many subdomain dns queries to Authoritative. Authoritative operators can choose DNSSEC because of security, they can also choose SWILD because of wildcard domain response optimization. Not contradictory. > 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. > As I replied to Petr, "many wildcards occupy the Resolver cache, with no nodes below them." Most of the subdomain wildcards for CDN, P2P, advertise, anti-virus, DNSBLs service have not specific subdomain like "dev", SWILD is not for this condition. > >> >> *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. > Every protocol feature has a deployment progress, nobody thinks that will be a short time, the same with other features such as ANAME, DANE, ... > 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. > I don't think SWILD will be more useful than DNSSEC, everyone knows that they are different features, and it is impossible. I think SWILD has no influence on DNSSEC deployment, details in last mail replied to Paul. One question: is wildcard subdomain cache issue solution must bind with security feature ? -- 致礼 Best Regards 潘蓝兰 Pan Lanlan
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
