keyserver pools using SRV records for HKP and HKPS [Was: Re: hkps port]

[David Shaw]

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  
>>> choice
>>> is actually running.  Still, it is better than nothing.  If I had  
>>> more
>>> 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  
> "_hkp._tcp.subkeys.pgp.net".

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  
2.0 branch.

David