[RPZ] "DNS Firewalls In Action - RPZ vs. Spam" (circleid)

[Vernon Schryver]

> From: Andrew Fried <afried at isc.org>

> Using a list via rbldnsd works well for a mail dbl.  Using the same data
> in an rpz aware dns server provides coverage for both mail and general
> Internet traffic.

Yes, there are several ways do do that.

> RPZ can incrementally replicate changes to it's slaves in a matter of
> seconds, whereas rsync'ed files take longer, consumes more bandwidth and
> take longer to import since the entire zone needs to be read in during
> each update. 

It's nice to hear good things about RPZ, but I know of only one
thing that might restrict DNSBL data distribution to rsync.  DNSBL
zones and response policy zones are merely DNS zones and so in theory
equally susceptible to distribution by incremental DNS zone transfers
(IXFR), full DNS zone transfers (AXFR), rsync, rdist, ftp, rcp, scp,
http, sneaker-net or whatever fits the particular case.

If you ask me, IXFR is the best fit for both RPZ and DNSBL zones.  I
don't know why all DNSBL operators don't offer IXFR as well as rsync.
IXFR would clearly be easier for DNSBL customers to configure (just
another slave zone) and it sounds easier for DNSBL providers.  Besides
low latency, IXFR has authentication and authorization as well as
tickling the customer's DNS server built into the protocol.

That one thing in favor of rsync for DNSBLs is the popularity of
DNS servers specialized for DNSBLs.  A Linux man page for rbldnsd rants
that "for DNSBLs, AXFR is the stupidiest yet common thing to do."  That
claim would be fine instead of itself stupid if it admitted the existence
of IXFR.  Rbldnsd is a classic example of provincial optimization.
It's advocates convince themselves that a DNSBL server is too busy to
allow real DNS software by ignoring the outer world where SMTP servers
(never mind other applications) often generate more non-DNSBL DNS
requests than DNSBL DNS requests.  (Count DNS requests unrelated to
DNSBLs including the reverse client IP, envelope, header, and SPF/DKMM
requests).  If your DNS servers handle only DNSBL requests (e.g. you
are a DNSBL vendor), then the rbldnsd position on wildcards, IXFR, and
IPv6 might be a good trade-off for your non-bulk DNSBL customers.  If
you are a DNSBL customer, rbldnsd is less likely to make sense.


> The biggest challenge I've seen in providing rpz services is that
> potential customers are either unable or unwilling to hand configure a
> current version of bind on their recursive nameservers.  Without that,
> rpz isn't possible.  I suppose once the *nix distro's finally start
> providing current versions of bind in their distro's that problem will
> go away.  For something like RedHat, that could take another decade,
> since RedHat seems to make it an art-form of using old, back-ported
> software.

Perhaps that problem reflects a mismatch between the nature of the
expected customers of some UNIX-like system vendors and some of their
actual customers.  For example, desktop users are unlikely to use RPZ
not only because they generally shouldn't be running recursive resolvers
but because they're unlikely to pay for abuse data data.

RPZ has been in official ISC BIND9 distributions for a long time.
There have been serveral BIND9 security advisories (unrelated to RPZ)
since RPZ made the offical ISC cut.  That might be why some RPZ has
been in BIND9 packages offered by some UNIX-like system vendors for
some time.  For example, judging from
http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/bind9/CHANGES#rev1.21
some versions of FreeBSD have had RPZ since 2011.


Vernon Schryver    vjs at rhyolite.com