Use eth.domains instead of eth.link for .eth names

[Arachnid]

Since moving to a Cloudflare-hosted gateway for eth.link, we're looking to reduce the impact our (ENS's) infrastructure has on the reliability of the service. We currently operate custom proxying nameservers on eth.link that forward to CloudFlare's DoH nameservers.

Thanks to some improvements at cloudflare, we can migrate eth.link to using their nameservers directly, except that their servers won't serve the TXT records required by IPFS's .eth integration. In order to allow this improvement to the eth.link service without affecting IPFS users who rely on the TXT records, we'd like to move IPFS to resolving records via eth.domains instead of eth.link. We'll maintain this service exclusively for IPFS and other systems needing to look up ENS content hashes as text records, while direct traffic will continue to go to eth.link via the new, more efficient path using only CloudFlare infrastructure.

If you're happy to merge this and push it into the next release, @lidel, I'd be most grateful.

[lidel]

• This is a cosmetic change to a temporary hack (Allow resolution of .eth names via .eth.link kubo#6448) that will go away soon

  • After support for configurable resolver per TLD lands in go-ipfs (Proposal: Configurable DNS resolvers for human-readable names protocol/web3-dev-team#42) we will be pointing .eth resolution (without suffix) at https://eth.link/dns-query, and this hack will be removed

• My only concern was that ENS needs to keep DNSLinks on eth.link alive until Brave and Gateways update to go-ipfs with this PR

  • We agreed on 3 month transition period with a check-in at the end to not float the boat in-between.

@aschmahmann is this something we can include in 0.9.0, or is it too late?