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

[John Clizbe]

Kristian Fiskerstrand wrote:
> On 2012-05-13 17:43, Giovanni Mascellani wrote:
>> Hi.
> 
>> Il 13/05/2012 16:41, Gabor Kiss ha scritto:
>>> OK. I understand the situation. Sksconf and peer's membership 
>>> files must contain the _same_ name whatever it is. In this case 
>>> Giovanni must decide what name to use.
> 
>> I changed the hostname in the configuration, although I find it a 
>> rather funny requirement.
> 
> Thanks Giovanni,
> 
> Its not really a "requirement" per se, the only requirement is that
> the hostname specified is a FQDN that is accessible, as Jeff puts it
> in [0] "Perfect: from this (and other remarks) and other comments
> your definition of "proper FQDN" policy can be inferred (afaict):
> 
>         The hostname reported in sksconf needs to be a "proper FQDN"."

<old fart>
That's it, in effect, but there's a subtle twist. I'll get to that next.

First naming rule: a host's own name does not need to be in its membership
file. HOWEVER, if it is, it MUST match the name in sksconf or recon will try
to connect to itself and deadlock.

The 2nd is a bit more nuanced. The name in membership should reflect the
address that the other server will be seen connecting from. For example, I run
five SKS servers, two of them are gingerbear.net, the other three are
keyservers.net. Requests hit the router and get forwarded to a local box.
Each server's membership file also contains the local names of the other four,
its own name left out because of rule #1.

Found this out by accident when I added the Mac OS box to gingerbear.net.
Recon requests were going out from it, but the server on the other end was
complaining about the name mismatch since sksconf had the local hostname
instead of the network visible name.

I forget at what level of logging the name mismatch messages show up, but Kim
Minh Kaplan may remember.

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.
</old fart>

Rule #1 may have changed with the IP address work done in the 1.0.10 - 1.1.0
timeframe. I'd have to go back and look.