Allow resolution of .eth names via .eth.link

[mcdee]

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 human-friendly IPNS and private files using blockchain 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]

• 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]

@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:

1. Trivial to maintain.
2. 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]

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]

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]

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]

@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]

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]

@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]

@lidel thanks for writing up the decision.

[lidel]

@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]

Yes.

[parkan]

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)