RRL probably not useful for DNS IP blacklists, was Re: New Versions of BIND are available (9.9.4, 9.8.6, and 9.6-ESV-R10)

[Vernon Schryver]

> From: Eliezer Croitoru <eliezer at ngtech.co.il>

> > Major DNSBL providers have years since limited anonymous clients for
> > business or other reasons.  For example, I think Spamhaus limits
> > anonymous clients to fewer than 3 queries/second.

> and I doubt they use RRL in the application level..

> I assume they limit that on either IPTABLES\FW level.

The only technical reason I know that might stop Spamhaus and the
Spamhaus mirrors from using RRL to throttle anonymous DNSBL clients
is the lingering enthusiasm for RBLDNSD and rsync in the DNSBL community.
RBLDNSD+rsync made sense before the (de facto standard) DNS protocol
had incremental zone transfers and updates.  It is a bug today.
That use of RBLDNSD+rsync has become a serious problem.  Among the
problems it causes are:

  - IPv6 DNS server caches
      If IXFR were used to distribute DNSBL data, then wildcards
      for cover entire CDIR blocks (both IPv4 and IPv6) could be
      published and there would be no IPv6 cache explosion issue.

  - Authentication
      RBLDNSD doesn't support DNSSEC, so that any of the many men
      in the middle between small DNSBL clients and the servers
      they use can "improve" passing DNSBL data.

I know nothing about how Spamhaus and the Spamhaus DNSBL mirrors control
access, but I doubt they use firewalls except to completely block
persistently abusive clients.  Firewalls trying to rate limit need to
keep state, and stateful firewalls are infamous for collapsing under
the weight of irrelevant state when someone tries to apply them to
this kind of problem.


> What is the way to provide DBSBL using bind??

BIND and other full featured DNS implementations are used to answer
DNSBL requests as well as requests for records in larger and more
frequently changing DNS zones than any of the DNSBLs.  Consider what
happens in the major gTLDs today.  Things have changed since RBLDNSD
appeared and when a change to example.com took weeks.

Consider the fact that some Spamhaus DNSBL zones are available as RPZ
zones.  See https://www.google.com/search?q=dns+rpz


> I was looking for something like that but I am sure a dynamic DB is
> needed for the task right?

Large DNSBLs are not very dynamic, because they have relatively few
changes per day.  From another perspective, with the popularity of
dynamically updating forward and reverse DNS zones as end-user IP
addresses changes, why isn't the the machinery in any full featured
DNS implementation a "dyanamic DB"?  The term "database" should not
imply "sql" or even "relational."


Vernon Schryver    vjs at rhyolite.com