sks-devel
[Top][All Lists]
Advanced

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

Re: [Sks-devel] geokey.webtru.st


From: Phil Pennock
Subject: Re: [Sks-devel] geokey.webtru.st
Date: Thu, 27 Oct 2011 06:08:55 -0400

On 2011-10-27 at 06:26 +0200, Kiss Gabor (Bitman) wrote:
> > The Right Thing would probably be anycast but I doubt any of us is ready
> > to go to the trouble of setting up such a beast. In the mean time we
> 
> Anycast would be great.

Anycast is of most use when you are, for some reason, constrained as to
which IP addresses are in use, because you do not have a higher-level
naming protocol such as DNS, which can be configured to return
non-static data (even if some DNS policy folks scream at the idea of
this).

Anycast adds a whole bunch of complexity to debug and can break TCP
connections when routes shift -- normally rare, but occasionally there's
a storm.  For this, it works best with UDP or very short-lived TCP
connections.

If we really feel that latency of public-facing SKS keyservers is a
concern, then a DNS pool provider could provision a GSLB-aware DNS
server which uses the query's source IP (as modified by
http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-01) to craft
an SRV response which is weighted according to the distribution of the
servers and the source IP.  It will be often wrong, but should often be
"good enough" and is unlikely to be _worse_ than an unweighted response.
By returning the same set of hostnames/IPs in the response, only varying
the weight, you might dodge a bunch of complaints from those who still
believe that GSLB is somehow Wrong.

I throw this out there, but I have no time for this myself and thus this
is noise from the crowd and can safely be ignored by anyone actually
doing work on the topic.

-Phil



reply via email to

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