sks-devel
[Top][All Lists]
Advanced

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

Re: [Fwd: Re: [Sks-devel] Alternative to round-robin (was Re: pool.sks-k


From: Kristian Fiskerstrand
Subject: Re: [Fwd: Re: [Sks-devel] Alternative to round-robin (was Re: pool.sks-keyservers.net having trouble?)]
Date: Mon, 05 Apr 2010 23:01:45 +0200
User-agent: Thunderbird 2.0.0.12 (X11/20080305)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

David Shaw wrote, On 04/05/2010 10:50 PM:
> On Apr 5, 2010, at 4:04 PM, Kristian Fiskerstrand wrote:
> 
>> David Shaw wrote, On 04/05/2010 09:25 PM:
>>> On Apr 1, 2010, at 12:30 AM, Jonathan Oxer wrote:
>>>
>>>> On Thu, 2010-04-01 at 00:13 -0400, Daniel Kahn Gillmor wrote:
>>>>
>>>> Sorry I can't answer your other questions, but I just had a look in
>>>> db.log and found ...
>>>>
>>>>> * How often
>>>>> do you see queries?
>>>> ...about 10k queries / day to keys.keysigning.org, which is in that
>>>> pool. I assume that since the pool is using round-robin DNS the number
>>>> should be pretty similar for all machines in the list.
>>> Speaking of round robining - recent versions of GnuPG support more than 
>>> straight round robin.  If you want to express more complex things like 
>>> weighting certain servers more heavily (because they have better 
>>> connectivity or hardware, for example), you can do that with a SRV DNS 
>>> record.
>>>
>>> This doesn't remove the need for the current pool of A records, as not all 
>>> software supports the SRV yet, but it is supported in GnuPG 1.4.10 and 
>>> 2.0.13 if anyone wants to play with it.  As a nice side-benefit, the SRV 
>>> record allows you to run the keyserver on ports other than 11371 and have 
>>> GnuPG automatically hit the right port without having to be configured 
>>> specifically.
>>>
>>> David
>>>
>>>
>> [Resending with a proper sender address]
>>
>> Sounds like a good idea to have such a weighting.. I just have to figure
>> out a way to actually differentiate between the keyservers. Easiest I
>> guess is a manual relative comparison - but anyone have a better idea?
>>
>> For now I just added srv records to the pool with equal weights
>>
>> #############
>>
>> address@hidden Download]$ dig ANY _hkp._tcp.pool.sks-keyservers.net
>> ;; Truncated, retrying in TCP mode.
>>
>> ; <<>> DiG 9.6.0a1 <<>> ANY _hkp._tcp.pool.sks-keyservers.net
> 
> This is good, but note the tag is _pgpkey-http._tcp.xxxxx (as per 
> http://www.dns-sd.org/ServiceTypes.html)
> 
> GPG also understands _pgpkey-https.
> 
> David
> 

Ok. this has been updated.

I also did some minor fiddeling around with the priorities. It still
only returns a limited amount of records (currently 10), but those with
a higher weight are always prioritized in the selection as well.

Feel free to come with input as to the number of records to show and
which servers should benefit from weighting up. Currently I set my own
keys.kfwebs.net to weight 15 and keyserver.gingerbear.net. to weight 30
for test purposes. The default for the rest is 20.

The consequence of this, given that the number of servers exceeds 10 ,
keys.kfwebs.net should never show up in the actual srv pool, whereby
keyserver.gingerbear.net. should always appear. The rest of the
selection should be shuffled based on the selection at the time of the
update.

- --
- ----------------------------
Kristian Fiskerstrand
address@hidden
http://www.sumptuouscapital.com
- ----------------------------
Ne nuntium necare
Don't kill the messenger
- ----------------------------
This email was digitally signed using the OpenPGP
standard. If you want to read more about this, visit:
http://www.secure-my-email.com
- ----------------------------
Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)

iQIcBAEBCAAGBQJLuk+5AAoJEAt/i2Dj7frjYsMP/0Hmx7ep6Qcwt5QsTNjDb2Pe
pceeuzye5rvLd1Bdh3q7mPYTgJhiZplXLIeFGLrNVVdc3YBiP6uXX2CLthkAyTlp
jOcedpYODCJRJZ+gfx94tZ3yNcfcPGvhBm6hWMIRV+EuVu4zCxfHb1/T9ck99bFg
L3FMNTR6jPqxXrPcAHrvQLTomqxRVwbitd1z0r99oPh4MHiqSTXj3m0PHJOMUlLR
RR+diXcrSWyoPlDhXiHFgEo01cnnfqulX448CLut88c+BAAhD8jZWwWbPy55/B9w
980cOdG5dRpL33hzavv1hSYdsjD+lRVvpbgN9K84vI4K7OKpQWZ1a2A+KUmrx3T4
hFWo2y1tujDKwNnRTw+i2prv/G9lyl3TjzYmG0iHfDjlsP1sK3uvcoDlHsGBN4TB
eyHdg843Yqm2j5+V4KaPFLvbbqlmzSPaws5w+KUK0Y8HB5m3k5c7UO1K4CfuOdQ0
P1zssXmCdtLSTTRuxpgVkl62OXwzjt85FLz9Y6JCinPhGqN+6rssxeya4HMUrNZ1
29r6QTklFbjf3sb54oI0OaOjVPnHCK1hh7QeBlUnYcRDOxCZoQXw1y/v2hOSCmbJ
zh+OkdDeGHaSnbhXc+GeYgcxXdPKk8AY6ZgduuS5ygVowY5LmqFbW3xI0gXK2bm7
/oOHRtthTrfAI2kjQrFP
=Ot4a
-----END PGP SIGNATURE-----




reply via email to

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