> 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
