Re: [Sks-devel] [GnuPG-users] sks-keyservers.net: Changes to pools / SRV Weights

[Phil Pennock]

On 2012-05-13 at 15:20 -0500, John Clizbe wrote:
> So I'd restate Kristen's requirement as a server's peers need to have in their
> membership file the name in the host's sksconf file, be that an A record or a
> CNAME (or an entry in /etc/hosts). In actual practice, this is, as Kristen
> described it, a FQDN. It works if two names for the same server resolve to the
> same IP address, but that clutters the status pages with duplicate entries. If
> a server's recon process is active on two Internet facing IP addresses,
> membership needs a unique entry for each interface -- that's often the reason
> why you see IP addresses in my membership file -- or the second interface
> generates unauthorized connection attempt messages.

Hrm.  When I was new to SKS, I set up "sks.spodhuis.org" and
"sks-peer.spodhuis.org".  My hope was to use different filtering on
different addresses, but that was before I was aware of the 11371 port
use as part of the recon process.

I've been consistent in supplying sks-peer.spodhuis.org for membership
files.

My intuition has me reluctant to change my current split; sure, recon
still goes through the proxy, that's not it.  I just view "use as a
client" and "use for peering" as two different roles of the server and
the addressing used for those roles should be distinct, for potential
segregation.

I remain tempted to drop the IPv4 record from sks.spodhuis.org, leaving
the client hostname as IPv6-only; one day, when I need to reclaim that
IPv4 address, I will do so, but not just yet.  I'm pleased at the spread
of IPv6 support in the SKS network.  When I do reclaim the IPv4, I'll
probably split sks/sks-peer to two different IPv6 addresses and set up
appropriate packet-filtering on the v6 address, so that peering can
remain up even in the face of DoS against the service address, provided
my link doesn't saturate.

-Phil