In message <201708150651.v7f6ptn7005...@calcite.rhyolite.com>, Vernon Schryver writes: > ] From: Mark Andrews <ma...@isc.org> > > ] I can't see how you can say push your RPZ to DNSSEC as RPZ breaks > ] DNSSEC.
I should have been more precise RPZ breaks DNSSEC for down stream validators if it modifies responses from signed zones. RPZ implementations can be configured to do this. > 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 v...@rhyolite.com > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- 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
