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

Hi Vernon,

There's a functionality [1] to do all these things (and more), you
just can't read/write complicated rules from RPC compatible format
(DNS zone files). Feel free to contribute of course.

Marek

[1]: http://knot-resolver.readthedocs.io/en/stable/modules.html#dns-application-firewall

On Fri, Oct 6, 2017 at 9:38 AM, Vernon Schryver <vjs@rhyolite.com> wrote:
>> From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <vladimir.cunat+ietf@nic.cz>
>
>> 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    vjs@rhyolite.com
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>