sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] sks-keyservers.net


From: Jonathan Wiltshire
Subject: Re: [Sks-devel] sks-keyservers.net
Date: Mon, 21 Mar 2011 23:55:17 +0000
User-agent: Mutt/1.5.20 (2009-06-14)

On Fri, Mar 18, 2011 at 12:06:03AM -0700, David Benfell wrote:
> As near as I can tell, synchronization doesn't depend on
> sks-keyservers.net so that part of the design of this was gotten
> right (yay!).  I haven't paid close attention to how all this works:

Synchronisation of the key database itself is done by peers in a mesh form,
so that part is mostly resilient to outages. The infrastructure that failed
last week was the part users tend to see, pool.sks-keyservers.net and the
DNS servers that let you look up a host from in that pool.

The DNS is now load-balanced across about nine hosts around the world, so
in the event of another outage services will carry on working. Changes to
the zone will not be pushed out to the hosts though.

> 1) Was the function of the pool to daisychain keyservers so we all
> assumed some of the load and nobody (hopefully) got slammed?  If so,
> what can/should be done about a central location where people can
> just go to submit keys?  And how did this work for people
> integrating keyservers into their GnuPG (and maybe OpenPGP?) setups?

The pool is there to spread the load and create redundancy, so failed hosts
don't cause problems for long. A central location for submitting keys isn't
really the point of OpenPGP - much better that keys can be submitted to any
server in the pool.
 
> 2) If sks-keyservers.net is permanently down and/or Kristian is
> unreachable, what can/should be done about a new central location?
> I see (from the WHOIS record) that the sks-keyservers.net domain is
> paid for through the end of the year.

sks-keyservers.net does two main things:
 - the statistics, visible to end-users, which also drive
 - the DNS zone updates

The former is an inconvenience, and the latter just means that DNS won't
get pushed out to the new slaves until the master comes back.

If Kristian really does disappear permanently... well, I think it's
reasonable to cross that bridge when we reach it.



-- 
Jonathan Wiltshire                                      address@hidden
Debian Developer                         http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]