Re: [DNSOP] draft-ietf-dnsop-dns-rpz

[Vernon Schryver <[e-mail]>]

> From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <[e-mail]>

> The current very limited implementation of RPZ in knot-resolver [1] is
> done via a couple dozen lines of lua code, i.e. only JIT-compiled.  The
> approach might remain similar, perhaps a bit more modularized, but in
> any case I expect it would be included by default, so I wouldn't fear
> about users having to recompile.
>
> [1]
> https://gitlab.labs.nic.cz/knot/knot-resolver/blob/v1.4.0/modules/policy/policy.lua#L294

I wish I wouldn't offend people when I point out that a mechanism
that uses local zone files is not a very limited response policy
zone implementation.  Such things might be far better than real
"rpz", but they're not "rpz".  (I can make a case for them being
better although I don't buy it, perhaps because I'm biased.)

Overwriting public DNS data triggered by qnames has always been trivial,
but that is not "rpz."  Simply fire up a local authority server with
your own "DNS lies" and point your resolvers to it, perhaps with custom
"hints" files.  If you're running combined authority/resolver code
such as BIND, simply add some local zone files.  But such ad hoc
authority server schemes as well as the new so called "rpz" schemes
of adding local zone files to resolvers the lack features that motiviated
the original implementation of real RPZ including:

  - distributed policy zones, including from external organizations
      This sounds minor, but it is major.  It's related to why so few
      organizations maintain their own anti-spam DNS blacklists. 
      You could use FTP, rsync, HTTP, etc. and a cron job, but in
      practice you won't.  And if you did, it updates would have
      latencies of hours or days instead of seconds with real RPZ.

  - dynamically combine policy from multiple sources
      In theory this could be done with some perl, awk, or even
      Bourne shell code, but not in practice at scale.

  - policies triggered by the contents of A and AAAA responses or by
         the names or IP addresses of authorities
      The bad guys can and do register new domains faster than you can
      update your local blacklist, faster than they can hijack new IP
      addresses for those new domains, and faster than they'd like to
      establish new authorities serving those new domains.

  - no need to restart the resolver to reload the zone
      This not only minimizes end user disruption when the zones
      are reloaded but allows organization-wide policy changes with
      latencies measured in seconds.

In other words, hacking local zone file qname overrides into a
resolver is not hard (including CNAME and DNAME chains).  The horrid
code involves triggering on A or AAAA contents and authority names
and addresses...well there're also SOA timers, IXFR, AXFR, Notify,
and TSIG, but that code is less horrid than voluminous.

Please don't misunderstand me as saying no one else can or should
write real RPZ code.  Many people could and I really wish they
would.  That's why I spent a lot effort outside my comfort zone on
the I-D.  What bugs me are implementations of so called RPZ and RRL
that share only the acronyms with the BIND stuff.


Vernon Schryver    [e-mail]