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

Hi Vernon,

Thanks for your advice, :-)

Vernon Schryver <vjs@rhyolite.com>于2017年8月15日周二 下午2:52写道：

> > From: Lanlan Pan <abbypan@gmail.com>
>
> > Don't judy other's motivation with meaningless skeptics. The endless
> > skeptics can also push on your RPZ to DNSSEC.
>
> A significant difference between RPZ and the SWILD is that RPZ does
> not depend on non-participants doing anything.  For example, RPZ works
> fine on a single, isolated resolver.
> (Of course, the owners of the IETF printing presses would have to
> agree to publish anything, but publishing a description is neither
> implementing nor deploying.)
>
> The history of RPZ might suggest a temporary solution.  Why not implement
> SWILD using a private rtype or perhaps even TXT?  An implementation
> and a few 1000 installations might convince some skeptics and render
> many objections moot.
>

Yeah,  TXT is my history plan: Recursive Resolvers that support wildcard
detect method with TXT record
<https://github.com/abbypan/dns_wildcard_on_intermediate_nameservers/blob/a4188548c87b6a10af45aa23575b86d9f33f39ec/draft.txt>

>
>
> > DNSSEC deployment will sharply rise if global nameservers desire *dns
> > security*, but almost impossible because of an addtional wildcards
> feature.
>
> I don't understand that.  My zones have plenty of wildcards, but as
> far as I can tell, no new wildcard features will break my DNSSEC
> signatures.
>
> I don't understand "global nameservers [desiring] dns security".
> Are "global nameservers" resolvers or authorities?

If they are resolvers, then there is absolutely no immediate prospect
> of many (any?) resolvers that might be called "global" dropping
> unsigned DNS data.
>

Both recursives and authoritatives.
I mean more and more recursives and authoritatives enable DNSSEC for dns
query by default configuration, sorry for my poor English.

If they are authorities, then I thought that the reasons why almost
> all com zones are unsigned are well understood, recently listed here,
> and have nothing to do with wildcards.  What am I missing?
> http://scoreboard.verisignlabs.com/
> http://scoreboard.verisignlabs.com/percent-trace.png

The deployment problem is on the Authoritative Nameservers of billions of
second level domains,  not on TLD.
And Recursive must enable DNSSEC validation for dns query by default
configuration.

>
>    .......................
>
> ] From: Mark Andrews <marka@isc.org>
>
> ] I can't see how you can say push your RPZ to DNSSEC as RPZ breaks
> ] DNSSEC.
>
> I describe the same facts as the opposite, as "either DNSSEC breaks RPZ
> or DNSSEC and RPZ work together perfectly well"  (in either case,
> assuming a trusted path such as (trusted) localhost name or 127.0.0.1
> address to a trusted resolver, where "trusted resolver" includes
> "trusted to rewrite."  Of course, without a trusted path to a trusted
> resolver or a verifying stub, DNSSEC doesn't mean much.)
>
> As Mark Andrews understands but many people don't, the common RPZ
> implementation parameter "BREAK-DNSSEC yes" does NOT mean "RPZ breaks
> DNSSEC", but "RPZ should ignore DNSSEC request bits despite the fast
> that RPZ invalidates and removes signatures and so verifying stubbs
> and verifying downstream resolvers will not accept rewritten answers."
>
> Also, in the two RPZ implementations I've written, the default
> BREAK-DNSSEC value is "no" so that requesting DNSSEC turns off RPZ.
>
>
> Vernon Schryver    vjs@rhyolite.com
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan