Can't propagate key through public keyservers

Bjoern Buerger b.buerger at
Sat Oct 28 11:32:07 CEST 2006

John Clizbe wrote:
>>I'd recommend  hkp://

The that server has always been a good choice,
since it is maintained by Germany`s National
Research and Education Network and their people
are payed to keep the Service running ;-)

So I would second that recommendation for users
in Germany - especially those in the DFN. But
John is right. Putting only one single server into
the configuration will cause problems. Today, tomorrow
or maybe in a few years. Servers vanish into thin air,
DNS entries change or don't get updates.

But I should clarify the situation with
*, since there might
be a misunderstanding.
is a single keyserver located on a private machine.

The only reason for this server is this:
At the time I set up the machine there was no
subkey-safe server accessible, even
was running broken software and most of the public
announced servers in * and *
where just inaccessible or did not sync their keys correctly.

However, there was the sks keyserver project with
two or three servers and I installed one on my own
machine to get "my very own" Keyserver which was
accessible all the time I needed it. The sks synchronisation
proved to be absolutely stable since all new keys
where also exchanged via mail-sync to the "old"
keyserver network, sks users got the best of both
worlds. And I was a student, which means: Compared
to my situation today I had plenty of time for
this stuff ;-) has always been a
private experiment. The main Problem with the existing was the missing continous maintenance
of this RR-Alias. And when I started the experiment,
most of the Keyservers in the RR Aliases where
broken, not subkey-safe or just not there.

Since I had a cron job running, which updated the
SKS Keyserver Gossip map (based on the status pages
of all known SKS Servers), I feeded that information
into my very own RR Alias:

> I wouldn't, and it has nothing to do with the server choice.

John is absolutely right. As I said before, the
aliases are only experimental and it is a private project.
I have never had any problems with other people using this
service, since it was the most only functional solution for
some time. And I had the ressources to provide the service
to anyone who wanted it.


a) Nowadays there are plenty of SKS Servers out there
b) I am no longer a student and my time for this stuff
   is very limited. I will reaktivate
   sometime, but at the moment the hardware is broken and it
   is just a hobby...
c) is on hold at the moment,
   since the mapping script was runnning on the keyserver.
d) Even if I would setup a new Server for all of this,
   I couldn't handle the Traffic. This was no problem
   in the past, since I had an agreement with my university
   (which was interested in such a service).
e) Things change.
f) I have provided this service for many years now,
   time for someone else to step in ;-)

> Remember, we're discussing automatic key retrieval specified in gpg.conf. One
> doesn't have a forty server drop-down list to cycle through, so it needs to be a
> best guess.


> What if is down or otherwise unreachable? Or
> Or ...? As Bjoern indicated, is down at the moment even
> though it may be the perfect choice otherwise.
> Recommending a single server also is *not* good net citizenship in a case such
> as this. It is the type of advice that causes servers to be overloaded with an
> undue amount of traffic as users take such recommendations as 'Gospel'.

Yes. I would like to see a keyserver-system where each provider offers
their own local keyserver just like they do with DNS, smtp, etc.
Each Server should sync with two or three other Servers via
the SKS synchronisation mechanism which has proven to be very good.

> Ultimately it's the users that suffer the bottleneck. In the worst case, the
> administrator takes the machine offline; bandwidth costs money - directing all
> inquiries to a single server is irresponsible. 


> is a DNS round-robin updated nightly with the
> currently reachable SKS servers. This removes servers that have been down from
> consideration. Only if there is trouble that day or at the same time as the
> query could one worry about the server being unreachable. A round-robin also
> spreads the load among all servers, and since this is SKS, it really is
> unimportant which server you use to update or query.

Yes. But as I stated before, it is a private experiment and may also
vanish some time. And at the moment the update is on hold. I would like
to see such a service on the servers of some public organisation,
e.g. the DFN or Maybe we have to change to status pages of
SKS (or introduce a new machnism just for those RR-Aliases) to support
some kind of "Type" for a Keyserver. E.g. most of the Keyservers in the rotation provide services on the
hkp standard port. But not all of them provide a Webserver on port 80
with a keyservr-request form as known by the servers.
Other Servers provide hkp-service on port 80 for people behind firewalls...

I would like to see different RR-Aliases like

I think you get the picture. Each Server Admin could add his
server to one or more of these groups and the automatic
update mechnism would take care of the rest.

If you would implement this via something like the SKS Status
Pages (and add a compatible status page to all other keyserver
variants, everyone could just use the alias or create
his own RR-Alias in another domain from that information. There
wouldn't be a single point of failure.

Just my 2¢ :-)


CC to pgp-keyserver-folk at and sks-devel at set

More information about the Gnupg-users mailing list