On Tue, 20 Dec 2016, Suzanne Woolf wrote:
The draft is being present as "Informational", and the point here is to
document current working
behavior in the DNS (for the past several years). It is obvious that some
feel this draft is a
large mistake, but like edns-client-subnet, more operators are deploying this
than one is aware
of.
This starts a Call for Adoption for draft-vixie-dns-rpz
First,
I think using the DNS to (re)distribute this kind of database is silly.
I think using CNAME's to point to keywords is a silly hack that shows
this solution is done with the wrong tools. I can see merit in people
using the same standard mechanisms to sync up their firewalls with
rulesets - even if a silly implementation is used. So while I think
it is an unwise choice, I don't think it will cause harm other then
the solution shooting itself in the foot, to which I do not object.
Second,
My biggest concern is not with the implementation of data synchronization,
but with the concept of introducing DNS lies. Any server implemting the
use of this draft document will be going to return DNS answers to me
that I am forced to drop as BOGUS. With DNSSEC validation moving to the
end node, this becomes indistinguishable from an attack. These end nodes
are likely not the best places to AXFR/IXFR this massive database to. So
I feel that part of a "dns firewall" solution is missing by only specifying
this backend document. What is missing is the part where a validating clients
can somehow receive these administratively blocked queries and validate that
the resolver's reply is somehow authenticated. Then the client can make
an independant decision on whether it has enough trust in the current
resolver being used (say Starbucks vs Google DNS vs a VPN supplied DNS)
And of course if such a companion document is created, how to prevent
nationstates from compelling operators to abuse it. I would hope that
anyone implementing such a query firewall would come up with a method
that would still _send_ the DNSSEC validatable data but with some kind
of marker saying "but you should not really use it", so that we are not
actually breaking DNSSEC and its security parameters. This marker could
be a simple BIT relying on transport security that comes as part of the
current efforts for DNS privacy, or it could as part of an RRTYPE from
some kind of online key on the resolver.
I do not object to working group adoption of this document, but I would
strongly prefer that it would only be aopted with a companion document on
how to use such RPZ zones in a way that does not compromise or withhold
DNSSEC results so that endusers will be able to make their own decision
without large scale DNS filtering affecting their legitimate use of DNS.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
