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

[Rob Debouter]

On Tue, 13 Jun 2017 23:26:06 -0400
Phil Pennock <address@hidden> wrote:
> 
> To double-check, the problematic response is on port 11371, not port
> 11370, right?

That is correct if the inbound traffic is using the public IP instead of the 
host name.

> 
> 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).

I don't mind if my node is part of the public pool or not.  I did some 
searching and testing to find the CNAME addresses being used.  I had added them 
to the reverse proxy so they would work if my node became part of the pool.
http://sks.funkymonkey.org:11371
http://keys.gnupg.net:11371
http://*.sks-keyservers.net:11371
http://*.sks.pool.globnix.net:11371
http://pgp.ipfire.org:11371

Because of the possible numbers of other unknown domain names, I started adding 
top level domain names to the list like:
http://*.edu:11371
http://*.com:11371

I just can't add:
http://*:11371
or
http://173.33.112.87:11371              (My public IP)

However, with my reverse proxy not adding a "via" header, the script does not 
detect the reverse proxy so it doesn't add my node to the pool.  Microsoft adds 
something like "Microsoft HTTP/API2.0" instead.
 
> 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.

With what I've been testing and playing around with, I'd probably consume more 
bandwidth querying the public servers directly than my personal node uses 
replicating the data (not counting the initial download).
 
> 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.

I agree which is why I'm trying to find a way to make this work for the public 
as well.  If there was a method for the recon process to use the hostname 
instead of IP, this would be easier but I guess there isn't.

I have come up with a couple more ideas to try to get my reverse proxy working 
for *:11371 and I'll be trying them today (so if my node acts up or doesn't 
respond, you'll know why).  I'll still need to find a way to get the "via" text 
in the response headers though for the script to detect the reverse proxy.

The last step if I can't get this working with my existing reverse proxy would 
be to buy another Raspberry Pi to be used as my second reverse proxy.

It might take a few days but I'll get it working in the pool.  :)

Thanks.
Rob D


P.S.
I don't know if the owner of the node http://keys2.kfwebs.net is in this 
mailing list or not but this node is in the pool but appears to have stopped 
replicating with the other nodes for a couple of days now going by the status 
page.

pgpHYg6S08xNZ.pgp
Description: PGP signature