Re: [Sks-devel] pool.sks-keyservers.net having trouble?

[Ryan]

Unfortunately most clients wont DNS fall-over very well in my experiences, if 
you just using gpg you could wrap a script around it to catch a bad exit status 
and make an attempt to repeat the last request, might flush dns but I think 
it'll work w/out a flush.

Yeah, its kind of subjective.. if your to the point where you notice your own 
actions slowing down someone else's server (thus effecting everyone) you have 
already crossed that line IMHO.. Other than that the bandwidth is so minimal I 
doubt many would have an issue until you start transferring several hundred MB 
a day, then again you should be running a local keyserver before you ever get 
to that point. 

I'll also throw in there anyone developing lookup software that uses someone's 
server as a default should most definitely seek permission prior to publishing 
the software.. but thats what many of the existing pools are for right?

I am not sure why I am not in the sks-keyserver pool, I suspect it has to do 
w/my redundant server configuration.. I seemed to disappear from the pool after 
deploying it and I never really brought it to anyone's attention.. perhaps I 
should. 

On Mar 31, 2010, at 11:13 PM, Daniel Kahn Gillmor wrote:

> Hi Ryan--
> 
> On 04/01/2010 12:45 AM, Ryan wrote:
>> Couple thoughts, first of all if you have several
>> machines doing regular queries you might look into running
>> a local keyserver for your servers to sync off of.. if thats
>> not a possibility you might locate your closest server and
>> point it at them.
> 
> I actually co-administer zimmermann.mayfirst.org (though it's not local
> to the hosts i'm talking about), which has been in the pool for a while.
> I hadn't thought about routing issues causing failures, though i would
> have hoped that the client-side tools would have used the DNS failover
> to work around such a failure.
> 
>> Another idea might be run your own DNS pool to your select
>> servers, give you the benefits of hitting multiple servers
>> but still the control over which actual servers get hit. If
>> you doing a TON of queries to a single server you might let
>> the admin know your intentions before hand.
> 
> i'm curious where most keyserver admins draw that line, actually.  where
> do you draw it?  How do you think it should be drawn if a pool is in use?
> 
> I'm willing to entertain setting up another DNS pool, but if i go
> through that trouble, i'd like to set it up for people other than
> myself.  i'd also like to help make sure that pool.sks-keyservers is
> healthy and responsive -- running/using my own pool would make me less
> aware of problems in the main pool which i'd like everyone to be able to
> take advantage of.
> 
>> You can use many external tools such as netstat to see your
>> local/remote socket connections, just look for something
>> hitting a remote hkp port.
> 
> yes, true -- perhaps i need to stage such an intervention on the next
> failure.  that kind of timing seems awkward and race-y, though.
> 
> i suppose i could also make a fakeout wrapper in
> /usr/lib/gnupg/gpgkeys_something that would strace and log relevant
> system calls used by the fetching process.
> 
>> I serve on average ~16.5k keys a day but I haven't been in the
>> sks-keyservers.net pool for some time now.. I am running 2 keyservers
>> and load balancing across the both of them, this is mainly for
>> high-avability as the load impact of a single keyserver is minimal.
> 
> Why aren't your keyservers in the pool?  is that a deliberate choice to
> keep them out somehow?
> 
> Regards,
> 
>       --dkg
>

smime.p7s
Description: S/MIME cryptographic signature

PGP.sig
Description: This is a digitally signed message part