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

Allow resolution of .eth names via .eth.link #6448

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@mcdee
Copy link

commented Jun 13, 2019

As per protocol/collab-ens#5 this PR handles the situation where IPNS names ending in .eth are unresolvable due to .eth not being a recognised TLD.

It does so by changing such names to end in .eth.link, which will be resolvable by the EthDNS nameserver to obtain data from the relevant ENS records on-chain in Ethereum.

@lidel
Copy link
Member

left a comment

This PR would add support for ENS at /ipns/example.eth, however now I am having some concerns if patching /ipns/{fqdn} is worth merging given potential problems and known limitations:

What if we use /ens instead of /ipns?

  • Do not change /ipns/
    • /ipns/example.eth.link will still work thanks to regular DNSLink
  • Add /ens namespace as a copy of /ipns that does all DNSLink lookups via EthDNS
  • Support self-hosted resolvers out of the box
    • Let user choose custom resolver in config under Ens.Nameservers
    • If Ens.Nameservers is empty or missing, default to ones provided by ENS project

This is aligned with existing plan to use EthDNS for ENS lookups
and comes with pretty cool set of additional features:

  • Removes the problem with Ethiopia country code
  • Enables resolution of all TLDs imported to ENS via DNSSEC 🚀
  • Enables true decetralization: people could use custom EthDNS resolver (running on localhost or LAN)

Thoughts?
@parkan @Stebalien @ipfs/wg-web-browsers ipfs/notes#348 ipfs/notes#286 ipfs/notes#302 (comment) ipfs/specs#198

@mcdee

This comment has been minimized.

Copy link
Author

commented Jun 14, 2019

  • What if we use /ens instead of /ipns

Personally I think the idea of adding the resolution protocol to the path is overly proscriptive. It would also, in my mind, slow the transition to using ENS.

If paths are out there that already use /ipns/my.domain.com, for example, and my.domain.com moves to ENS, resolution will continue over DNS (successfully) even though ENS would be the primary source of the data and a preferable path to resolution.

There is an argument this could cause problems if DNS and ENS diverge, but this can be resolved by explicitly defining primacy (e.g. records in ENS will always override those in DNS).

@lidel

This comment has been minimized.

Copy link
Member

commented Jun 14, 2019

@mcdee I agree that /ens discussion should not block us from enabling /ipns/example.eth as soon as possible to unlock use of .eth on gateways without Nginx hacks.

I also like the idea of overriding DNS servers via config of go-ipfs (we should support both array of hostnames at ipfs config Dns.NameServers or DoH endpoint at Dns.ResolverUrl). That would enable people to switch their Gateways to ENS for all TLDs if they choose to do so, while maintaining compatibility within existing convention. Should be a separate PR tho.

Sidenote:

Note that DNSLink is already confusing: /ipns/{fqdn} has no relation to actual IPNS (which operates on /ipns/{libp2p-key}), it is actually something like /dns/{fqdn} (ipfs/notes#348). It is a technical/ux debt we did not deal with yet. We are revisiting "what should be a separate namespace and why" in ipfs/specs#198

@Stebalien would it be acceptable to merge this PR as a temporary measure?

Rationale: .eth does not exist in public DNS, so it is safe to do this for now. If .eth becomes a real TLD in the future, then we will add configuration option to disable this rewrite, or move to /ens by then.

@Stebalien
Copy link
Contributor

left a comment

LGTM. This seems like a minimal base that's:

  1. Trivial to maintain.
  2. Unlike to conflict with a future change.
@Stebalien
Copy link
Contributor

left a comment

Actually, this should have a test. @mcdee, could you add a test to namesys/dns_test.go (just verify that we rewrite .eth domains to .eth.link)?

@Stebalien

This comment has been minimized.

Copy link
Contributor

commented Jul 3, 2019

Longer comment:

It may cause problem in the future if .eth becomes a real TLD owned by Ethiopia.

.et is the TLD for Ethiopia. Has anyone submitted a RFC with the IETF for .ETH?

Prior discussions we had ended with consensus that resolvers other than "real" DNS should get own namespaces (cc @Stebalien mentioning ENS in ipfs/notes#302 (comment))

I agree that the DNS namespace shouldn't necessarily be tied to the DNS protocol.

There is an argument this could cause problems if DNS and ENS diverge, but this can be resolved by explicitly defining primacy (e.g. records in ENS will always override those in DNS).

We can make that decision when we get there.

@aschmahmann

This comment has been minimized.

Copy link

commented Jul 3, 2019

Wanted to surface here the comment by @Stebalien at multiformats/multicodec#136 (review) regarding how the IPNS multicodec should not be used for things other than IPNS.

In general, people should also not expect that the syntax /ipns/something-other-than-an-IPNS-key will be supported indefinitely, it's super confusing.

@Stebalien

This comment has been minimized.

Copy link
Contributor

commented Jul 4, 2019

In general, people should also not expect that the syntax /ipns/something-other-than-an-IPNS-key will be supported indefinitely, it's super confusing.

Note: We're going to support that indefinitely as we don't break links. However, there's no reason to introduce the same confusion when encoding them into a compact binary format.

@mcdee

This comment has been minimized.

Copy link
Author

commented Jul 4, 2019

@Stebalien added suitable tests.

Regarding the .eth domain: ICANN have put all of the 3-character ccTLDs in limbo for the moment, with the idea that countries may want them one day (ignoring the fact that they all have 2-character ccTLDs and some of them are already used, but hey) so .eth is unavailable to us.

@Stebalien

This comment has been minimized.

Copy link
Contributor

commented Jul 8, 2019

Regarding the .eth domain: ICANN have put all of the 3-character ccTLDs in limbo for the moment, with the idea that countries may want them one day (ignoring the fact that they all have 2-character ccTLDs and some of them are already used, but hey) so .eth is unavailable to us.

Have you talked to the IETF? That's how .onion did it.

@Stebalien

This comment has been minimized.

Copy link
Contributor

commented Jul 8, 2019

@aschmahmann would you like to continue our discussion here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.