Feature request: add link type /dns/<domain name>

[buckle2000]

How about we change /ipns/<domain name> into /dns/<domain name>?
The syntax /ipns/<domain name> is really confusing.
Related: ipfs/ipfs-update#80 (comment)

[Stebalien]

So, I believe /dns/domain.name used to resolve to a mulitaddr (location/address). We've since moved to /dnsaddr/domain.name. However, I don't know the history behind /ipns/domain.name.

edit: apparently I'm wrong. It used to be /dns. I'm not sure why it changed.

[bleonard252]

It's not the Domain Name System, it's the Interplanetary Name System, that's why.

[Stebalien]

IPNS maps public keys to paths. That is, /ipns/QmMyKey... can map to /ipfs/QmMyFile. However, here we're using the /ipns prefix for DNSLink. That is, /ipns/ipfs.io. DNSLink is a completely separate system with different security guarantees.

[lidel]

It is fair to say that in the future there will be more resolvers than PeerID-based IPNS and DNSLink-based mainstream DNS. This year alone I've been asked about support for OpenNIC tlds, namecoin, ENS, Handshake etc.

Are there any prior discussions about how we are going to handle more than two resolvers? I've only found ipfs/kubo#3942 about pluggable ipns resolvers, but nothing solid when it comes to path-addressing.

cc @lgierth @kyledrake

[Stebalien]

IMO, we should use different namespaces.

[lidel]

@lgierth do you remember the story behind /dns/{website_with_dnslink} ?
(why we went with /ipns/{website_with_dnslink} etc)

[swedneck]

why not use /dnslink instead of /dns? Since multiformats/go-multiaddr-dns/pull/17 is a thing it seems quite confusing to use /dns to resolve dnslink, and /dnslink is intuitive to me at least.

[lidel]

I agree: /dnslink is clear and removes ambigouity about the purpose of the namespace.

It also matches existing /dnsaddr quite nicely.

[momack2]

@Stebalien @aschmahmann - solving old problems?

[Stebalien]

Solving old problems...

/dnslink is the correct way forward.