[Sks-devel] Annoying malicious keys - any easy solution?

[echelon]

Hi

I´ve redone my keyserver and currently the annoying malicious keys
annoying me.
Somehow it managed to kill sks and OOM my apache2 setup, until I did fix
small sks changes.
command_timeout: 600
wserver_timeout: 30
max_recover: 150

It seems to keep the sks server stable, but these keys:
0x69D2EAD9
0x1013D73FECAC918A0A25823986CE877469D2EAD9
0x2016349F5BC6F49340FCCAF99F9169F4B33B4659
(one of them specially notes "do not use sks keyservers as they are broken")

seems to be asked a lot (200-500 times/hour), and those seems to be
broken with ueseless trash (e.g. requests are handled with 40
MB/keyrequest). Like a email spammer someone ruins the SKS database.

I use apache2 as a proxy webfront to sks, so I could try apache2 to
limit the access.

I know sks devs do not want to take actions, but those keys really do
annoy me and renders server useless, somewhat. It fills the database
with GBs of useless trash (up to 10GB/day on syncing with other DB
servers the last days).

So, what can I do?
I know ths patch (which seems to be included in debian sks package) to
ignore one special malicious key, but that seems to not help about those
noted above. Is there a patch to add more keys to be ignored?
As some IPs requests the same KeyID over and over again (>100 reqs/day),
I do block those IPs with fail2ban.
Anyone has a Apache2 redirect entry to redirect the requests to
$somewhere else with a error page?
Or a way to limit keysize to some 100kb/1MB ?

Yeah, I know all the sideeffects and issues with these hacks, but I do
want to keep my sks server running, but not with these bastard keys
annoyingly using bandwidth and HD space for trash. Sorry.
Also I do know, this persons spamming will use more and more keys, until
a solution in sks is found.

And one note about all this: if this spamming goes on, and sks does not
work around it, it will destroy/remove lots of key servers from the
network, thus killing this nice features.

thank you.

echelon