About the IPFS Redirection Error

Help
1

A website that was fixed three years ago, https://ipfs.io/ipns/tornadocash.eth/, used to redirect to https://tornadocash-eth.ipns.dweb.link/.

However, recently, clicking on this link redirects to https://tornadocash.eth.ipns.dweb.link/ and displays an error:
“This site can’t provide a secure connection. tornadocash.eth.ipns.dweb.link uses an unsupported protocol.”

The cause of this issue is unknown. How can it be fixed?

2

That error message is pretty unfortunate. IIUC it stems from the ENS resolution for that domain not working. It looks like there’s a bug related to that error message not being clear enough, but the real issue (“why can’t I load my website”) isn’t due to this bug.

My guess as to what’s going on here:

  1. The public utility gateways ipfs.io and dweb.link (https://about.ipfs.io/) do not run their own ENS resolvers (i.e. mapping ENS → IPFS names). They have delegated that work to others within the ENS community.
  2. For a long time it was Cloudflare, for whatever reason the Cloudflare resolver is currently broken (you can read up a little more about what’s been going on and figuring out plans going forward for libraries and applications like boxo and kubo at bug: resolver.cloudflare-eth.com is down; change default ENS resolver? · Issue #771 · ipfs/boxo · GitHub), might just be a glitch that happened while people there were on holiday break or something else :person_shrugging:. As a result ipfs.io and dweb.link switched to using eth.limo as the ENS resolver.
  3. eth.limo is a great part of the ENS community but it’s operated by a small team who does not have a Cloudflare-sized army of lawyers … so when they get takedown requests for controversial content like tornadocash they might make a reasonable decision to block it. For what it’s worth ipfs.io and dweb.link could end up in a position to block the content too, but here I’m pretty sure the issue is with the ENS resolver

So where does that leave things:

Today and near future:

For now you can resolve your ENS name into an IPFS address on your own since today there are AFAIK no public resolvers that will do it (Cloudflare down, eth.limo not resolving that name, I’m not aware of others), and then put that CID into a public (or locally run) gateway. There are probably some tools out there that will do this for you if you hand it an ETH RPC endpoint (which there are public ones, free ones if you sign up, etc.). I know a number of libraries in Go, JS, etc. will make this relatively easy but not sure if there’s a nice binary packaging (if you ask on the ENS forums likely someone will know).

A lot of folks are OOO for the end of the year, but likely the next kubo release will have the ability to point at local HTTP endpoints for DoH resolution and so you could run your own gateway locally (fix(dns): allow http:// DoH resolvers by lidel · Pull Request #645 · ipfs/boxo · GitHub) and hook up something like GitHub - wealdtech/coredns-ens if you wanted to. At the moment that won’t work without setting up TLS certs which might be a bit of a pain for you.

Further out (but hopefully not too far)

  1. It’d be great if the ENS ecosystem could have more resilient resolution of ENS names that’s less vulnerable to one or two actors having bad infrastructure days, censoring content that’s controversial in their legal jurisdiction, etc. to that end the issue linked above is probably one to follow. I suspect when folks are back in the new year there’ll be some discussions on the ENS forums as well.
  2. Related to ^ there is a related thread on what happens when moving towards functional browser-based IPFS retrieval (e.g. https://inbrowser.link/) since there’s probably a sizeable number of people who would go to ENS websites that have a browser extension / wallet with a (trusted) ETH RPC endpoint configured anyway that might be able to be leveraged.

Side note: For dApps you want to use a subdomain gateway like <dapp>.ipns.dweb.link rather than a path gateway like ipfs.io/ipns/<dapp> because of how browser origin isolation works. For things like jpegs, etc. that doesn’t matter, but for dApps the security model is much better with subdomains (you can read more here Address IPFS on the web | IPFS Docs)