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

[David Shaw]

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".

David