DNSLink redirects to unreachable url

[cypt4]

https://pin.ski/3TNzYjz fails to load because of DNSLink redirect.
There is DNS record for the url, but nodes fail to resolve it.

Steps to Reproduce

1. Enable IPFS local or remote node and DNSLink redirects
2. Open https://pin.ski/3TNzYjz

Actual result:

ipfs resolve -r /ipns/unstoppabledomains.mypinata.cloud/ipfs/QmPFY3HuzddkKBuZUJ5gQ2REoKQSpECk84nmzs1594suir/: could not resolve name: "unstoppabledomains.mypinata.cloud" is missing a DNSLink record (https://docs.ipfs.io/concepts/dnslink/)

Expected result:

Site opens

Reproduces how often:

100%

Brave version (brave://version info)

1.45

Version/Channel Information:

• Can you reproduce this issue with the current release? Yes
• Can you reproduce this issue with the beta channel? Yes
• Can you reproduce this issue with the nightly channel? Yes

[rillian]

There is DNS record for the url, but nodes fail to resolve it.

To be clear, there is no DNSLink record for either the unstoppable domains gateway or pin.ski.

$ dig +short txt _dnslink.unstoppabledomains.mypinata.cloud
<empty response>

So the question is, what is triggering Brave to check for a DNSLink, and why is it requiring that to resolve instead of loading the domain normally? Cloudflare does set x-ipfs-path: /ipfs/QmTZ4vvV926DN2HwZpd8djLyovFptqk3Xbct71YwJxt28A on the http response, so I'd expect the page to load through the redirected mypinata url and then decorate it with an "Open in IPFS" button.

[lidel]

• pin.ski domain does not have DNSLink set up
• HTTP response for https://pin.ski/3TNzYjz has x-ipfs-path HTTP header with CID
  • hypothesis: probably because someone mounted https://127.0.0.1:8080/ipfs/QmTZ4vvV926DN2HwZpd8djLyovFptqk3Xbct71YwJxt28A at `/ using Nginx, and did not use DNSLink support in Gateway
• seems that that is happening is this: Brave does the redirect using the first feature, and not the second (DNSLink) one (assuming both are enabled):

  

It is not a bug per se, everything works as expected (IPFS resource identified by a CID is detected, and redirected to local gateway), but the UX is confusing when DNSLink is missing and website is mis-configured like this.

I think this is the same problem as one described in ipfs/ipfs-companion#1052 – I proposed fix there where we only redirect URLS that follow Public Gateway convention.

Update: I think there is an easier fix: if DNSLink redirect is enabled, Brave should not redirect to /ipns/<domain from url> without confirming DNS TXT record with DNSLink exist.

[stephendonner]

Verified PASSED using

Brave	1.46.24 Chromium: 106.0.5249.65 (Official Build) nightly (x86_64)
Revision	3269dc3633cdd2ab94546fdbe54962e45b17a6e0-refs/branch-heads/5249@{#580}
OS	macOS Version 11.7 (Build 20G817)

Case One - Gateway

Steps:

1. installed 1.46.24
2. launched Brave
3. opened brave://settings/ipfs
4. set Method to resolve IPFS resources to Gateway
5. toggled Automatically redirect to IPFS pages via DNSLink when possible to Enabled
6. loaded https://pin.ski/3TNzYjz
7. confirmed https://unstoppabledomains.mypinata.cloud/ipfs/QmTZ4vvV926DN2HwZpd8djLyovFptqk3Xbct71YwJxt28A loaded, with an IPFS button in the URL bar
8. clicked on IPFS
9. confirmed https://bafybeicnpdfiiozubqar2plzkqvfuygrmm6n7y4zqi4efzppkdycrxrzzm.ipfs.dweb.link/ loaded

brave://settings/ipfs	initial load	IPFS link

Case Two - Brave local IPFS node

Steps:

1. installed 1.46.24
2. launched Brave
3. opened brave://settings/ipfs
4. set Method to resolve IPFS resources to Brave local IPFS node
5. toggled Automatically redirect to IPFS pages via DNSLink when possible to Enabled
6. loaded https://pin.ski/3TNzYjz
7. clicked on IPFS in the URL bar
8. confirmed http://bafybeicnpdfiiozubqar2plzkqvfuygrmm6n7y4zqi4efzppkdycrxrzzm.ipfs.localhost:48081/ loaded

brave://settings/ipfs	initial load	IPFS link