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

EIP-1459: Node Discovery via DNS #50

Open
fjl opened this Issue Sep 29, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@fjl
Copy link
Contributor

fjl commented Sep 29, 2018

https://eips.ethereum.org/EIPS/eip-1459

This issue is for discussion of the DNS-based discovery mechanism.

@fjl

This comment has been minimized.

Copy link
Contributor

fjl commented Oct 3, 2018

While working on the go implementation of the EIP, I realized that it might be better to split the 'link' tree from the 'enr' tree. This is better because clients want to track all the links, but don't necessarily want to download the entire tree to find them all.

Having all the links is important to make the web-of-trust work: the client starts with a single 'main' tree and discovers additional trees through links. When a link is deleted from the main tree, the client should stop following the linked tree.

@fjl

This comment has been minimized.

Copy link
Contributor

fjl commented Oct 6, 2018

Note to myself: the plan for creating up-to-date lists is to resolve records through the DHT before generating the tree. The code that does this should check whether there are any changes to record content. If the record found in DHT has identical content but a higher sequence number, it's better to include the older record in the tree to avoid pointless updates.

@divan

This comment has been minimized.

Copy link

divan commented Oct 16, 2018

What weight is on the "always available" part of rationale?

At Status.im we've been exploring different ways of distributing bootnodes' information, and DNS was one of the options, but we're assuming adversary environments, where ISPs are not our friends. It quickly became obvious that in public places (airports, shopping malls, public wifis, etc), DNS is often blocked on transport layer and only Access Point's own DNS server is permitted to use. For the scenarios where the government is actively trying to shut down the service, DNS is a an extremely easy target to control due to its hierarchical nature.

I know our use case is a bit different, but adding it to discussion anyway.

@fjl

This comment has been minimized.

Copy link
Contributor

fjl commented Oct 16, 2018

By "always available", I meant that DNS is widely deployed and you'll always have a name server within reach. That doesn't say the name server will be good. It's worth noting that the server can't modify the node list because it's signed. It can censor it, but any form of network communication can be censored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment