/ipfs/ and /ipns/ links don't work from a dnslink hosted web space

[dustin]

Version information:

go-ipfs version: 0.4.9-rc1-
Repo version: 5
System version: amd64/darwin
Golang version: go1.8

Type: Bug

Severity: Medium

Description:

When accessing IPFS via a dnslink-serviced host (e.g. ipfs.sallings.org), /ipfs/ and /ipns/ links don't work.

e.g.,:

http://ipfs.sallings.org/ipns/QmP8uqUuowHdixyFASba87ABgVxfoKGj8NyrTH2VLLTFkZ

yields:

ipfs resolve -r /ipns/ipfs.sallings.org/ipns/QmP8uqUuowHdixyFASba87ABgVxfoKGj8NyrTH2VLLTFkZ: no link named "ipns" under QmaYYjrg1rEYddWYLcR96uc9jGLA9cuHkUiCqQYLwbKDnx

I would expect either ipfs or ipns to be handled in this case when it can't be resolved directly (or just always).

This seems minor, but I considered it "medium" severity as it means you can't link to separately managed pages within IPFS from such a host. In the above case, I worked around this by linking to //gateway.ipfs.io/ipns/... -- but this is quite undesirable for a variety of reasons (e.g., can't just browse stuff at localhost).

[whyrusleeping]

@lgierth thoughts here?

[arfonzocoward]

Hi all, I'm seeing this issue with ipfs 0.4.18.

As soon as I remove the TXT record for dnslink, /ipns and /ipfs paths work again on my gateway services. I can reproduce this consistently on multiple nodes.

It's kind of annoying because it then becomes either/or: either you use dnslink to provide a nice non-hash URL-based page, OR you can use /ipns and /ipfs. But not both.

Thanks, keep up the great work!

[Stebalien]

Are you trying to run a public gateway? Personally, I recommend using a separate domain for security/pain reasons.

If you're curious, we handle this by sticking an nginx reverse proxy out in front of our gateway and clearing the Host header for /ipfs, /ipns, etc.

[ghost]

The current behaviour is as expected, but there have been discussions in the past to allow /ipns and /ipfs within dnslink+Host websites, just so that you can reference stuff without a domain.

However, the IPFS Companion browser extension picks up /ipfs and /ipns paths on any domain, so that's not really a problem anymore.

[arfonzocoward]

Thanks guys. In the end we've gone the separate domain route, so I'm relieved to hear that seems to be a suggested solution. Thanks for the tip regarding the reverse proxies, I will keep this in mind, it's good to know how to achieve that functionality (we use varnish, but I think header stripping can be done there if needed).

As for the behaviour being expected: perhaps it bears making this clear(er) in the documentation, I'm not sure I found this anywhere. The docs are otherwise very clear and concise. I guess I was looking at the public gateway(s), thinking my private gateway should operate similarly.

Thanks again for the assistance!

[LeDechaine]

Apparently when an IPFS server (somehow) sees a DNSLink, it caches it for a while / forever (?). How to clear a "DNSLink" from the "cache" after it's deleted from the DNS servers? I don't know. So I got stuck there too.

If it can help anyone, setting "NoDNSLink": true instead of false in the ipfs/config file fixed the problem for me. Otherwise your personal IPFS server (already programmed to redirect everything to /ipns/your-website, for example) just becomes a webpage saying ipfs resolve -r /ipns/dnslink/ipns/your-website: no link named "ipns" under (cid). or something similar.