Mark Andrews <ma...@isc.org>于2017年8月15日周二 下午1:14写道：
> > In message < > canljsvwyo0nbisjgsqhrh33evbcuflnzcjceahj-l89fa+e...@mail.gmail.com> > , Lanlan Pan writes: > > > > Hi Paul, > > > > Don't judy other's motivation with meaningless skeptics. The endless > > skeptics can also push on your RPZ to DNSSEC. > > I can't see how you can say push your RPZ to DNSSEC as RPZ breaks > DNSSEC. > Just for compare example, I mean that I also can't see how Paul can say SWILD is to reduce DNSSEC deployment. Not depend on, is not equal to , reducing deployment. > > As an network engineer, I think good faith is face to the realistic > > internet world, try my best to offer a better solution to technology > > problem. > > > > If we anticipated the subdomain wildcard scenario when designing wildcard > > years ago, *make Authoritative give more precise wildcard information to > > Recursive* (SWILD) is natually. > > SWILD is not starting from "desire", not to mention "reducing DNSSEC > > deployment". > > > > *1) I believe, reduce solution interdependence between different problem > > areas is comfortable.* > > > > Subdomain wildcard cache issue solution is not need to bind with security > > issue, in natural. > > Only if you believe spoofed responses can't be delivered. > Everyone knows spoofed response can be delivered, that is why DNSSEC exists. SWILD can work with DNSSEC validation, and save validation cost. DNSSEC-enabled Recursive only need validate SWILD RR one time, not need calculate/match NSEC3/NSEC5/... for yyy/zzz/.foo.com range. > > > *2) I believe, design an alternative solution to an existed problem is > > ordinary.* > > > > IPv4/IPv6 Migration can use Tunnel, NAT, ... > > And that is a problem for router vendors and OS developers because > they end up having to implement them all. Part of the reason there > aren't lots of CPE Routers today that support IPv6 is that the > vendors have to spend lots of $$$$$$ implemententing and testing > all the different transition mechanisms. If they don't want to > spend lot of $$$$$$ then there is no real guidance on what mechanisms > to discard. > > > Subdomain wildcard cache optimization can use NSEC aggressive wildcards, > > SWILD, ... > > > > You can oppose to SWILD, but wish you not oppose to the alternative > > solution designing. > > > > *3) I believe, network protocol / feature deployment progress is decided > > by the key function, not because of additional function.* > > > > IPv6 deployment will sharply rise mostly because of *IPv4 addresses > > exhaustion*, but almost impossible because of any improved IPv6 featue > > that IPv4 not have, such as MTU detect, auto addressing, built in IPsec, > ... > > DNSSEC deployment will sharply rise if global nameservers desire *dns > > security*, but almost impossible because of an addtional wildcards > feature. > > > > That is why I say "SWILD has no influnence on reducing DNSSEC > deployment", > > going further, "NSEC aggressive wildcard has no influnence on rising > > DNSSEC deployment". > > > > Repeat the Google example, as far as I can see: > > - Google has expert on NSEC aggressive wildcard. > > - Google likes to support some optimized protocols/features, such as > QUIC, > > SPDY, ... > > > > Nowadays: dig @ns1.google.com xxxxxxxx.google.com +dnssec, only return > > NXDOMAIN. > > Sum it up, I believe Google will deploy DNSSEC because of DNS SECURITY > NEED > > in future, more probability than because of NSEC aggressive wildcards. > > Google validates answers on its recursive servers so Google has already > partially deployed DNSSEC. > My example is Google's Authoritative Server, ns1.google.com. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 <+61%202%209871%204742> INTERNET: > ma...@isc.org > -- 致礼 Best Regards 潘蓝兰 Pan Lanlan
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
