Some URL don't get redirected to the local Web-Gateway

[RubenKelevra]

Describe the bug
I use a simple URL redirect by my domain provider, to avoid having to run a webserver myself. The redirect looks like this:

http://abc.domain.tld -> HTTP302 -> https://ipfs.io/ipns/abc.domain.tld/

This is currently not caught by the ipfs-companion and the content is fetched from the ipfs.io web gateway.

My domain has a DNSLink-Entry to an IPNS-CID. Using this IPNS-CID directly (to ipfs.io) as a link works.

Demo-Link-Working

Demo-Link-Broken with DNSLink IPNS

Demo-Link-Broken with forward

DNSData:

[ruben@i3 ~]$ nslookup -TYPE=TXT pkg.pacman.store
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
pkg.pacman.store	text = "dnslink=/ipns/QmfYwNBmDaGXP8cxTRxoSmGkYQFRFT4HjeeFjMvc9Y4KHq"
pkg.pacman.store	text = "1|https://ipfs.io/ipns/pkg.pacman.store/"

Authoritative answers can be found from:

Expected behavior
All 3 demo links should load the data from the local gateway.

Desktop (please complete the following information):

• OS: ArchLinux
• Browser Brave
• Version 2.11.0

[lidel]

@RubenKelevra I believe the issue is not caused by the redirect, but your DNS TXT records and the way DNSLink resolution works in go-ipfs.

http://localhost:8080/api/v0/dns/pkg.pacman.store?r=true in go-ipfs 0.5.0 returns:

{"Message":"not a valid domain name","Code":0,"Type":"error"}

Some ideas:

• What is the purpose of 1|https://ipfs.io/ipns/pkg.pacman.store/ TXT record?
  I suspect it may be the source of problem (perhaps it revealed a bug in the way we parse TXT records that are not related to dnslink?
• Can you move DNSLink record from the main domain at pkg.pacman.store to _dnslink.pkg.pacman.store ? (may fix the issue, as there won't be any other TXT records to interfere)

Let me know if any of this helped.

[lidel]

@RubenKelevra Also, you mention:

I use a simple URL redirect by my domain provider, to avoid having to run a webserver myself.

You don't need to run server youself. Just point DNS CNAME record at any public gateway and unless it censors Host header, it will load.

Not all gateway provides give TLS for such setups, but I believe Cloudflare does:
https://developers.cloudflare.com/distributed-web/ipfs-gateway/connecting-website/ → see "Make It All Secure" section.

This should give you https://pkg.pacman.store backed by Cloudflare's gateway

[lidel]

@RubenKelevra any update on this?

[RubenKelevra]

• What is the purpose of 1|https://ipfs.io/ipns/pkg.pacman.store/ TXT record?
  I suspect it may be the source of problem (perhaps it revealed a bug in the way we parse TXT records that are not related to dnslink?

This is the way the hoster implement redirects with DNS. IPFS should ignore this record, as it isn't a dnslink-record.

• Can you move DNSLink record from the main domain at pkg.pacman.store to _dnslink.pkg.pacman.store ? (may fix the issue, as there won't be any other TXT records to interfere)

I've changed my DNS to this. Didn't change anything. Another idea @lidel ?

This should give you https://pkg.pacman.store backed by Cloudflare's gateway

I can't use the Cloudflare gateway. It's for hours unable to receive a perfectly working IPNS record for no apparent reason.

See https://discuss.ipfs.io/t/difficulties-with-the-cloudflare-gateway/7211

[lidel]

Hm.. I filled ipfs/kubo#7439

That upstream bug is the root of the problem. IPFS Companion does not redirect to local gateway, because it gets false-negative from /api/v0/dns/pkg.pacman.store:

[Ktl-XV]

I quickly changed the api endpoint to /api/v0/name/resolve/, repackaged the extension and it worked correctly in Chromium. I don't know enough to be sure if there are any side effects of this change. Can a member of the project explain if this is an option?

[jessicaschilling]

@lidel Can you please advise?

[lidel]

Good catch! I believe there are no side effects.

@Ktl-XV would you like to submit a PR?