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. > 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. > *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. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
