keyserver pools using SRV records for HKP and HKPS [Was: Re: hkps port]
dshaw at jabberwocky.com
Tue Apr 21 04:23:14 CEST 2009
On Apr 2, 2009, at 6:54 PM, David Shaw wrote:
> On Apr 2, 2009, at 10:45 AM, Daniel Kahn Gillmor wrote:
>> On 04/02/2009 08:56 AM, David Shaw wrote:
>>> Ideally, curl would support SRV internally. It can do a better
>>> job than
>>> we can do as a wrapper from outside, as it can properly walk the
>>> list of
>>> returned servers until one answers. The best we can do is do a SRV
>>> lookup, run the selection algorithm, and then hope that the best
>>> is actually running. Still, it is better than nothing. If I had
>>> spare time, I'd just write SRV for curl and donate it to them.
>> I agree that using SRV records is a good idea for HKP and HKPS. And
>> David's suggestion here is structurally the right way to go, even if
>> we're not there yet.
>> But i also note that i don't see any keyserver pools publishing their
>> pool as SRV records at the moment -- only A records. If we're
>> going to
>> say that we're making a least-unhappy choice (which is bound to make
>> some operators unhappy), and that SRV records will be the mitigating
>> factor, we should probably clearly encourage keyserver pool
>> operators to
>> publish their pool as SRV records directly in addition to A records.
>> Or are they already doing this, and i'm just querying the wrong way?
>> dig -t SRV _hkp._tcp.pool.sks-keyservers.net
>> dig -t SRV _hkp._tcp.keys.gnupg.net
> Some pools have SRV already and some don't. Try
I just committed the last bit for re-enabling SRV for hkp (which gives
us hkps as well). Sorry for the delay. I just started a new job, and
it's been a wee bit busy around here.
If anyone who is tracking the 1.4 branch from svn wants to give it a
whirl (especially for hkps), please do, and let me know how it works
for you. Once I get a response or two, I'll integrate it over to the
More information about the Gnupg-devel