sks-devel
[Top][All Lists]
Advanced

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

Re: [Sks-devel] Issue caused by recon process using IP address instead o


From: Phil Pennock
Subject: Re: [Sks-devel] Issue caused by recon process using IP address instead of hostname
Date: Tue, 13 Jun 2017 23:26:06 -0400

On 2017-06-13 at 14:24 -0400, Rob Debouter wrote:
> If I understand the recon process correctly, it reads the peers from the 
> membership file, performs a DNS lookup to retrieve the IP and uses the IP 
> address for all communications.  The TCP connection from client to server is 
> done on port 11370, receives a list possible key changes by hash values and 
> the client then attempts to connect to the server by IP:11371.
> 
> In my case, my reverse proxy returns an http 400 - invalid hostname response 
> during the recon process.  I'm using [2] as a reverse proxy instead of 
> something local on my node because it's a Raspberry Pi 3 and I didn't want to 
> take resources away from SKS.  I'm also already using this reverse proxy for 
> other applications so I'm using it for SKS as well.

To double-check, the problematic response is on port 11371, not port
11370, right?

This is part of why whatever listens on port 11371 must NOT use
virtual-hosting on port 11371.  Do whatever you want on ports 80 or 443,
but all traffic on 11371 needs to be passed through.  This shouldn't be
a hardship, nothing else should be expecting to listen on that port.

If you don't pass through on 11371 then you also can't be part of the
public pools, where you don't know ahead of time the hostnames or CNAMES
to pools which might be used (eg, keys.gnupg.net points to
pool.sks-keyservers.net at present).

And if you're not part of the public pools, then others might ask why
they should pay for bandwidth and processing to provide a service to
you.  Some people will shrug and be happy to, but others won't.

The SKS mesh is very informal, but works through almost everyone
choosing to provide public service back.  You can run private servers
peering to one public server, and do whatever you want on those, but
everyone chips into the public pool first.  (Various servers can be seen
peering with publicly-unresolvable names, so we know this is happening,
and the more surreptitiously-inclined might choose to alter the SKS
codebase to just not report some peers when asked by the outside world.)

-Phil



reply via email to

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