Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

[Mukund Sivaraman <[e-mail]>]

Disclaimer: As a BIND developer, I've been co-maintaining RPZ for a few
years now (and have exposure to how it's used/deployed in various
places). I don't like these DNS tricks (ECS, RPZ, etc.) at all; they
reduce the elegance of DNS, but I've learned over the years that some
things are a practical necessity. They are a double-edged sword.. good
things and bad things can be done with them.

The RPZ feature was first documented as a technote by ISC. The same
authors (Vixie and Vernon Schryver) as the current draft were involved
in that effort:

https://ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt

This feature is deployed out of necessity at several ISPs. Two popular
classes of deployments are:

* Preventing non-computer-savvy ("laymen") users from self-harm that may
  be caused by visiting a malware website or connecting to a rogue
  service, and collective harm to the service/global internet. For the
  RPZ illiterate among us, there are feeds available of bad domains and
  subnets that can be transferred as DNS zones into a resolver from
  providers like Spamhaus. This is similar to spam filtering by ISPs
  using DNSBLs.

* Preventing a user from visiting a blocked/restricted website as per
  that country's local laws without which a service provider cannot
  operate. E.g., to block child pornography.

It can be said that the second kind could be used as an attack on
free-speech (as it can be used to block any website), but in practice,
current deployments at ISPs are for preventing harm and it is deployed
in this way. RPZ is popular, no doubt about it.

In our world, things are not as clear as black and white. We have to
accomodate a lot of the grey area, protocols that can be used for good
and mis-used for bad.

The ISC technote linked above is now obsolete, but the derived protocol
being followed currently is loosely established among vendors (producers
and consumers of the RPZs) and uses the BIND implementation and
behaviour as a (moving) reference.

(1) Regardless of the WG adopting the current document or not, it is
    very unlikely that RPZ deployment will change due to this.

(2) As there is no standard and vendors guess or may extend the protocol
    as they wish, there is the chance of incompatibilities and more harm
    than good because there is no standard.

The WG should consider (2) more than (1). Those who want to deploy RPZ
already know how to find it, it is implemented in current DNS products
and current operator deployment is not going away because the IETF
didn't rubberstamp it.

There is no need for anyone to use a provider's resolver (implementing
RPZ lies) if they do not want their responses to be affected by RPZ. Run
your own resolver. Is there a requirement that an ISP's resolver doesn't
lie? Currently, resolvers may refuse to provide answers to queries for
practical reasons. This is only growing.. a TTL stretching draft is
being worked on by Warren and Tale that will cause resolvers to lie that
RDATA has not expired. It is a practical necessity in some
situations. (Bad things can also be done due to some ideas.)

To speak my mind, even though the current authors of this draft are the
original authors of RPZ, in the future I'd rather that the WG is able to
influence its direction and what goes into it for the same reasons that
there are objections. I don't want just the authors to decide this
outside a WG process. Towards this, I appreciate that the authors have
brought it to the IETF.

On Mon, Mar 13, 2017 at 07:11:46AM -0400, Paul Wouters wrote:
> I have proposed a method that would not change the RPZ response for a
> non-DNSSEC client, but would add data for DNSSEC capable clients to be
> notified the DNSSEC data was modified (and possibly state why) giving
> DNSSEC capable clients a method to act differently, knowing the data
> was changed for a reason and is not simply a DNS spoofing attack. It
> can be added without breaking existing deployments. If the authors
> aren't willing to do this, why should IETF rubberstamp a DNS protocol
> that breaks DNSSEC?

In what I understood from Vixie, the authors want the current behavior
to be captured initially (so that any DNS implementation which wants to
implement the current behavior may do so in conformance, and providers
of RPZ feeds may provide them in conformance - today), and then
immediately afterwards, extended as bis within the WG. If we call the
current protocol as version 1, it has to be set in stone for what's
there today. A future version can modify it, but this version 1 cannot
be defined as anything else or current deployments will break (there are
producer and consumer sides to RPZ deployments).

I have a couple of extensions (features users want) sitting in branches
that cannot be merged into BIND master or provided to any customers
because it will implicitly extend RPZ for everybody (as BIND behavior is
more or less looked at as the reference right now).

This case of making it an informational RFC seems very similar to
CLIENT-SUBNET. RFC 7871 sucks (having co-developed the resolver
CLIENT-SUBNET implementation in BIND, I think the protocol design per
RFC 7871 is poor, not to mention the general idea), but it needed to be
done to document what's being used. I dislike the idea but several
operators desire it. Until ECS became RFC, what was documented in
various revisions of the draft changed and there were differences among
implementations. Now, if somebody comes to us and says "resolver ECS
support is broken in BIND", we can check it against RFC 7871 or point
the reporter to the RFC to demonstrate it isn't broken. Right now
there's no way for DNS RPZ implementations to check for conformance. An
ECS bis was expected but I don't want to hold my breath.

If the WG is opposed to the idea of RPZ on ethical grounds, then it is
doubtful RPZ (the idea) can be improved in any way that makes it become
any more ethical for adoption.

If the WG is not opposed to the idea of RPZ on ethical grounds, it isn't
a bad move to support adoption of this first version so that current
deployments can synchronize and the WG can take its time to revise it in
the future.

		Mukund