Re: [Sks-devel] [PATCH] auto-refresh membership DNS

[Kim Minh Kaplan]

Phil Pennock writes:

> On 2009-03-22 at 13:45 +0000, Kim Minh Kaplan wrote:
>
> However, either the membership_reload_interval option needs to be
> completely removed or the reconserver.ml needs to support it -- leaving
> it as a dbserver-only option seems sub-optimal.

I favor of removing it when a better solution is ready.

> Call it paranoia resulting from maintaining mail-server code in previous
> employment, where mtime collisions in a cluster were possible so relying
> on mtime-changed was a bad plan.

Paranoia! :-)

Seriously I do not see what you are refering to in this case.  Something
like multiple processes simultaneously modifying membership while it is
being reloaded?  It is supposed to be hand edited.  And even then the
simplest fix would be to not reload it if the current time is the same
as the modification time.  Mmm...  Ok I'll do that.

> So, "sks-mshp-timed2.patch" should probably go in -- it fixes the
> mailsync reload

Oh, I did not look at this.  I will.

> As is, doesn't your patch lead to a recon connection from a non-peer
> while one of your peers is without DNS being a mini-DoS attack?  So once
> you have a peer with bad DNS, you become susceptible to recon service
> DDoS?

Quite right, I had noticed this too and modified my patch to *not* do
any DNS request in Membership.test anymore.  This fixes it.  The cost is
very slow authorisation of partners (connections to partners still work
fine).  I am working on an easy fix for this.

> The clearest way out of this is to require dbserver/reconserver to have
> event handler callbacks for DNS, use asynchronous DNS callback
> resolution;

This sounds overly complex for the problem at hand.

> So, in short, you've bitten off a bigger problem.

I think I have a much simpler solution for the problem at hand.  As I
just mentionned the first fix is to not do any DNS resolution at client
accept time.  This is trivial and already in my source tree.

Then to mitigate that membership IPs would be slow to come into the
cache, do a round of DNS lookup on all currently unknown IPs at
membership reload time.  Note that the loading of the membership and the
DNS lookup round are done in separate steps.  I.e. the loading will
always success (it's fast) while the lookup may be interrupted partway
by a timeout in which case no harm is done and the cache still contains
more IPs.

See any problem with that approach?

Kim Minh.