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

[Vernon Schryver <[e-mail]>]

> From: Lanlan Pan <[e-mail]>

> 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.


> 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.
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

   .......................

] From: Mark Andrews <[e-mail]>

] 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    [e-mail]