John Clizbe wrote: >>I'd recommend hkp://blackhole.pca.dfn.de 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 *.keyserver.penguin.de, since there might be a misunderstanding. sks.keyserver.penguin.de 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 blackhole.pca.dfn.de was running broken software and most of the public announced servers in *.pgp.net and *.keyserver.net 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 ;-) random.sks.keyserver.penguin.de has always been a private experiment. The main Problem with the existing wwwkeys.pgp.net was the missing continous maintenance of this RR-Alias. And when I started the experiment, most of the Keyservers in the pgp.net 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: random.sks.keyserver.penguin.de. > I wouldn't, and it has nothing to do with the server choice. John is absolutely right. As I said before, the penguin.de 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. BUT: 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 sks.keyserver.penguin.de sometime, but at the moment the hardware is broken and it is just a hobby... c) random.sks.keyserver.penguin.de 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. ACK. > What if blackhole.pca.dfn.de is down or otherwise unreachable? Or foo.baz.net? > Or ...? As Bjoern indicated, sks.keyserver.penguin.de 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. ACK. > random.sks.keyserver.penguin.de 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 pgp.net. 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 random.sks.keyserver.penguin.de 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 wwwkeys.pgp.net servers. Other Servers provide hkp-service on port 80 for people behind firewalls... I would like to see different RR-Aliases like sks.rr.pgp.net pks.rr.pgp.net subkeysafe.rr.pgp.net port80.rr.pgp.net some-other-keyserver-group.rr.pgp.net eu-hkp-keyservers-subkeysafe.rr.pgp.net us-hkp-keyservers-subkeysafe.rr.pgp.net [...] 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 pgp.net 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¢ :-) Greetings, Bjørn CC to [EMAIL PROTECTED] and sks-devel@nongnu.org set _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users