-
-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
hostname resolution at peer connection #24
Comments
Well, the DNS is deliberately removed from LNP/BP Core library and nodes, to prevent occasional exposure of the node to DNS servers and deanonymization - as well as many other types of attacks. That's why only IP addresses and Onion. The rule we follow: no outcoming traffic from the node other than peer traffic and RPC interface explicitly defined by the user. One can write a simple script to resolve DNS into IP and paste it as a parameter to the node launching command. PS. DNS, SSL, PKI delenda est |
Thanks for the clear answer. I would really appreciate if you could point out some documentation for the attacks you mention, whenever you have time for it. |
It's a well known attacks: if you don't use SSL nothing guarantees that you connect to the correctly resolved server; any cafe WiFi can direct you on some other host. If you use SSL, you are depending on government authorities authenticating your server and your identity, and the certificate can be revoked/not postponed. |
Should we document this design choice a bit better? I can take this task. |
You are welcome |
Currently
lnp-cli connect <nodeid>@<address>[:<port>]
does not resolve hostnames in the address field, and it accepts only IPv4, IPv6 or onion addresses; same applies to other subcommands such asping
andcreate
. Hostname resolution should be useful for many applications.For instance, it would come handy in a docker setting where nodes connect to each other referring to their respective hostnames within a docker network.
The text was updated successfully, but these errors were encountered: