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

[Daniel Kahn Gillmor]

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

both return empty sets.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090402/c4621769/attachment.pgp>