Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Lanlan Pan <[e-mail]>]

Mark Andrews <[e-mail]>于2017年8月15日周二 下午1:14写道：

>
> In message <
> [e-mail]>
> , 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: [phone] <+61%202%209871%204742>                 INTERNET:
> [e-mail]
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan