Allow resolution of .eth names via .eth.link by mcdee · Pull Request #6448 · ipfs/kubo

mcdee · 2019-06-13T14:11:39Z

As per https://github.com/protocol/collab-ens/issues/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

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:

This works only for .eth, which means it does not give us ENS support for all the other TLDs imported via DNSSEC
It may cause problem in the future if .eth becomes a real TLD owned by Ethiopia.
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))

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 · 2019-06-14T10:44:58Z

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 · 2019-06-14T13:34:12Z

@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

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

Trivial to maintain.
Unlike to conflict with a future change.

Stebalien

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 · 2019-07-03T20:01:34Z

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 · 2019-07-03T23:56:08Z

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 · 2019-07-04T18:00:00Z

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 · 2019-07-04T23:44:22Z

@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 · 2019-07-08T16:44:01Z

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 · 2019-07-08T16:46:38Z

@aschmahmann would you like to continue our discussion here?

lidel

Ok, we had various discussions since then, and given the surgical scope of this PR and the fact that:

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.

And:

.et is the country code top-level domain (ccTLD) for Ethiopia.

@Stebalien I feel its ok to merge this.

tl;dr this PR unlocks use of /ipns/ipfs.enstest.eth and custom code can be removed if .eth becomes real TLD st some point in the future.

Stebalien · 2019-08-05T04:39:05Z

@lidel thanks for writing up the decision.

lidel · 2019-08-14T09:01:11Z

@Stebalien just for the record: will this be released in v0.5.0, correct?

v0.4.22:

$ curl http://127.0.0.1:8080/ipns/ipfs.enstest.eth/
ipfs resolve -r /ipns/ipfs.enstest.eth/: not a valid proquint string

$ ipfs name resolve /ipns/ipfs.enstest.eth
Error: not a valid proquint string

master is 👌

$ ipfs name resolve /ipns/ipfs.enstest.eth.link
/ipfs/QmRAQB6YaCyidP37UdDnjFY5vQuiBrcqdyoW1CuDgwxkD4

$ ipfs name resolve /ipns/ipfs.enstest.eth
/ipfs/QmRAQB6YaCyidP37UdDnjFY5vQuiBrcqdyoW1CuDgwxkD4

Stebalien · 2019-08-14T16:13:11Z

Yes.

.eth TLD is not recognised by mainstream DNS, however ENS provides DNS compatibility service at .eth.link This change enables resolution of ENS names ending with .eth on systems that have regular DNS set up More context at the go-ipfs counterpart: ipfs/kubo#6448 License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

parkan · 2019-10-07T01:30:46Z

this doesn’t seem to be the issue

~~hmm am I right in thinking that the sync Resolve code path here doesn’t hit this change?~~

https://github.com/ipfs/go-ipfs/blob/b15edf287df6f7d8d99f7b7befb548469579a20c/namesys/namesys.go#L54

I’m having a bit of trouble figuring out what’s calling what but this would be consistent with the failure of the gateway to load .eth names via Host: header (works fine via /ipns/foo.eth)

Allow resolution of .eth names via .eth.link

1a9ff60

lidel requested changes Jun 13, 2019

View reviewed changes

lidel mentioned this pull request Jun 13, 2019

human-friendly IPNS and private files using blockchain ipfs/notes#302

Open

aschmahmann mentioned this pull request Jun 13, 2019

IPNS with multiple resolvers ipfs/specs#198

Open

Stebalien approved these changes Jul 3, 2019

View reviewed changes

Stebalien requested changes Jul 3, 2019

View reviewed changes

Add test for resolution of .eth names

a7f322f

lidel approved these changes Aug 3, 2019

View reviewed changes

Stebalien approved these changes Aug 5, 2019

View reviewed changes

Stebalien merged commit 5f652ca into ipfs:master Aug 5, 2019

lidel mentioned this pull request Aug 20, 2019

feat: resolution of .eth names via .eth.link ipfs/js-ipfs#2373

Merged

parkan mentioned this pull request Oct 7, 2019

gateway doesn’t load .eth domains from Host: header #6699

Closed

lidel mentioned this pull request Mar 25, 2020

docs: EthDNS/eth.link support in go-ipfs 0.5 ipfs/ipfs-docs#145

Merged

This was referenced May 10, 2020

Custom/local DNS name resolver support without ipfs server dns configuration #6915

Closed

Unstoppabledomains/feature ipfs/ipfs-companion#875

Closed

feat: add .crypto and .zil from UnstoppableDomains jbenet/go-is-domain#17

Merged

dzhelezov mentioned this pull request Jul 10, 2020

Expand IPNS concept doc ipfs/ipfs-docs#244

Closed

lidel mentioned this pull request Mar 30, 2021

Use eth.domains instead of eth.link for .eth names ipfs/go-namesys#8

Merged

lidel modified the milestone: go-ipfs 0.9 Apr 5, 2021

lidel mentioned this pull request Apr 13, 2021

feat: support custom DoH resolvers #8068

Merged

7 tasks

Uh oh!

Conversation

mcdee commented Jun 13, 2019

Uh oh!

lidel left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

What if we use /ens instead of /ipns?

Uh oh!

mcdee commented Jun 14, 2019

Uh oh!

lidel commented Jun 14, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Stebalien left a comment

Choose a reason for hiding this comment

Uh oh!

Stebalien left a comment

Choose a reason for hiding this comment

Uh oh!

Stebalien commented Jul 3, 2019

Uh oh!

aschmahmann commented Jul 3, 2019

Uh oh!

Stebalien commented Jul 4, 2019

Uh oh!

mcdee commented Jul 4, 2019

Uh oh!

Stebalien commented Jul 8, 2019

Uh oh!

Stebalien commented Jul 8, 2019

Uh oh!

lidel left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Stebalien commented Aug 5, 2019

Uh oh!

lidel commented Aug 14, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Stebalien commented Aug 14, 2019

Uh oh!

parkan commented Oct 7, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

lidel left a comment •

edited

Loading

What if we use `/ens` instead of `/ipns`?

lidel commented Jun 14, 2019 •

edited

Loading

lidel left a comment •

edited

Loading

lidel commented Aug 14, 2019 •

edited

Loading

parkan commented Oct 7, 2019 •

edited

Loading