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 <v...@rhyolite.com> wrote: >> From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <vladimir.cunat+i...@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 v...@rhyolite.com > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
