Skip to content
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

Support hostnames/dns in peers #163

Open
Lassulus opened this issue Mar 18, 2024 · 3 comments
Open

Support hostnames/dns in peers #163

Lassulus opened this issue Mar 18, 2024 · 3 comments
Labels
type_feature New feature or request

Comments

@Lassulus
Copy link

right now it seems like --peers only accepts IP addresses:

error: invalid value 'quic://lassul.us:9651' for '--peers <STATIC_PEERS>...': failed to parse address: invalid socket address syntax

It would be very convenient to use hostnames/dns to specify those.

@LeeSmet LeeSmet added the type_feature New feature or request label Mar 19, 2024
@LeeSmet
Copy link
Contributor

LeeSmet commented Mar 19, 2024

Indeed, this is something which has also been put forward internally. There are some practical considerations, most notably a DNS record (and hostname) can have multiple records, and we need to consider how to handle that. But I do think a basic implementation for this (for now) can be doable (probably as an experimental feature)

@flokli
Copy link
Contributor

flokli commented Apr 3, 2024

How do we handle having the same host, but reachable via different IP addresses/transports in the peers list currently?

I think these problems are kinda the same - I'd resolve these DNS records, and throw all IPs (both address families) into a list of possible paths. For each path, we can then check the pubkey it points to, and then group different paths to the same pubkey (prefer the one with the best metric, but keep the others around as fallback).

This should cover both usecases of people using a dualstacked hostname pointing to a node of theirs, as well as "round robin" usecases, pointing to multiple nodes with different pubkeys.

If we periodically re-resolve, it should also handle DNS changes over time.

@LeeSmet
Copy link
Contributor

LeeSmet commented Apr 3, 2024

In the current behavior the protocol is completely separated from the connection, so opening 2 separate connection between the same peers actually causes the nodes to think they are connected to 2 distinct entities. This is indeed a bit suboptimal (protocol traffic is duplicated over all connections for example). It's something we are thinking about on how to solve it elegantly without tying too many layers together, and should be improved in the future.

As for the DNS resolution, I for sure intend to have periodic resolution. Connecting to all A/AAAA records might be the way to go indeed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type_feature New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants