[ratelimits] new RRL patch includes RPZ patches

[Vernon Schryver]

> From: Erwin Lansing <erwin at FreeBSD.org>

> It seems that the new RRL patch also includes the RPZ patches and
> is no longer available as a stand-alone patch, unless I'm reading the
> page incorrectly. 

That is correct.

>                    For the FreeBSD ports of Bind 9.8 and 9.9, RPZ and
> RRL are separate options, so I'd also like to make external patches to
> those features available as separate options.

That makes no sense to me, because RPZ has been present in ISC's BIND9
since 2010 and BIND 9.8.0.  Unless you've been removing the RPZ code
from the FreeBSD bind98-* and bind99-* ports and packages, you've long
been shipping RPZ.

On the other hand, obvious Google searches with "site:freebsd.org" and
on http://www.freebsd.org/cgi/ports.cgi find no signs that FreeBSD is
doing anything with the BIND9 RRL patch.

Perhaps you did not mean to talk about making RPZ an option in the
FreeBSD BIND port or package but to make the one or the other version
of faster RPZ code an option.  That would be a mistake, because neither
new version of RPZ nor RRL is ready for release.  When (and if ever)
they are ready, they will appear in official BIND 9 releases or perhaps
somehow in the ISC BIND9 contrib directory.


>                                                Would it be possible to
> have those two split into two different patch sets?

No.

If it were easy to make them independent patches, then it would have
been done.  I maintain 3 separate git branches.  Unfortunately for me
and my hatred of merging and merge-errors, they change some of the
same source and so cannot easily be independent.  In theory, I could
release 6 more patches (rrl, rpz, and rpz2 for two most current ISC
BIND9 releases), but that would confuse me too much and bring too many
bug reports from others trying build their own rpz*+rrl versions.


Please excuse my tone.  I have hard feelings toward repacking second
guessers in general and particularly some in the Linux communities for
their "improvements" (spelled m-i-n-o-r--d-a-m-a-g-e) to DCC (see
https://www.google.com/search?q=dcc+spam ) and more important, for
their refusal to ship stop shipping ancient code with my old, bad bugs.
For the last 7 years they have been responsible for most of the entries
on the blacklist used by the public DCC servers to protect themselves
from deranged clients.  Those who want to fork source ought to have
the courage and honesty to say that's what they're doing and to accept
responsibility for the consequences of their efforts instead of...well,
never mind.


Vernon Schryver    vjs at rhyolite.com