Prevent dns leakage and disable seeding/listening with -connect #914

Prevent dns leakage and disable seeding/listening with -connect

ACK. I think this is the "least surprising behavior" for -connect.

ACK

IRC is already off by default, so there is no need to set-soft it off.

This patch will break some number of p2pool users (it would break me for example). Anyone have any thoughts about what could be done about listening which is less aggressive than shutting it off completely? I'm coming up with nothing at the moment.

Binding the p2p listening socket to 127.0.0.1, perhaps instead of not listening at all?

EDIT: or rather, listening to the same addresses as RPC

Dnsseed makes sense, but Im not sure I agree that nolisten (and, by extension IRC, UPnP) is the "least surprising behavior" when using -connect. If nothing, it should be clearly stated in the help options.

Perhaps generally the nolisten behavior should be to bind only to 127.0.0.1(/same address as rpc)?

I dont think that is the "least surprising behavior" either. (really, we should have a -bind=ip:port)

And a -allow=<netmask> as well?

I'll defer to y'all to work this out; listening only for connections from localhost sounds interesting, although I'll just say I've regretted having subtle interactions between command-line arguments in the past and good documentation might be the best answer (either tell p2pool users to use -connect=... -listen=1 or tell others to use -connect=... -listen=0 ).

I agree that the subtle interactions between command-line arguments can be really confusing (both to developers and users) unless it would result in clearly broken or dangerous behaviour (for example, advertising your node address when not listening). We should have clear command-line flags for these orthogonal concerns:

• Bind to a certain port / interface, or don't listen at all. Maybe even allow bind to multiple ports/interfaces. Only request UPNP (if enabled) on interfaces we bind to.
• Advertise your node, or don't advertise it (irrespective of the used mechanisms, be it IRC, DNS, or whatever is added in the future) for incoming connections.
• Use peer auto-discovery (irrespective of the used mechanisms, be it IRC, DNS, or whatever is added in the future), or connect only to a certain list of nodes for outgoing connections.

Give the user a clear error in case of obviously impossible combinations. That's the "least surprising behaviour". Don't try to make the program guess intent.

Also, we could support SOCKS4a or SOCKS5, and pass connection requests using domain names there, instead of resolving them ourselves.

Disagree with listen=0 policy enforcement in this patch.

I have deployed configurations in the field where local mining nodes accept incoming connections from any node [on my local, firewalled network] but only -connect to specified hosts.