DNS tests failing in go-ipfs

[magik6k]

https://ci.ipfs.team/blue/organizations/jenkins/IPFS%2Fgo-ipfs/detail/PR-5053/110/tests/

Apis / js-api-linux-10.4.1 / should resolve a DNS link – interface-ipfs-core tests .dns
expected [Error: could not resolve name (recursion limit exceeded)] to not exist

Apis / js-api-linux-10.4.1 / should resolve an IPNS DNS link – interface-ipfs-core tests .resolve
expected false to be true

ipfs dns ipfs.io needs to be called with -r flag as ipfs.io uses 2-level dnslink (/ipns/ipfs.io -> /ipns/website.ipfs.io -> /ipfs/QmWebsite)

Blocks ipfs/kubo#5053

[daviddias]

These tests pass on js-ipfs-api master which gets tested with the latest go-ipfs released (0.4.17). Do you use js-ipfs-api master to run those tests?

[magik6k]

I use v24.0.1 + go-ipfs master. Testing locally, ipfs dns ipfs.io on 0.4.17 returns the same error. Can you test with go-ipfs master?

[magik6k]

(this is how the test is run: https://github.com/ipfs/go-ipfs/pull/5053/files#diff-b7ff5824046cf0b1acd30703f283738dR140)

[shunkino]

Hi @magik6k, I think I also had a same problem.

I was able to successfully execute the test by modifying codes as follows to enable recursive ipns resolve as you pointed out in the first post. Thank you.
https://github.com/ipfs/interface-ipfs-core/blob/master/js/src/miscellaneous/dns.js#L37
ipfs.dns('ipfs.io', {r: true}, (err, path) => {

https://github.com/ipfs/interface-ipfs-core/blob/master/js/src/miscellaneous/resolve.js#L95
ipfs.resolve('/ipns/ipfs.io', {r: true},(err, path) => {

I assume this fix should be done toward interface-ipfs-core repo, but I'm too new to the project and not sure this is correct way to fix the problem... :(

[lidel]

cc upstream issue: ipfs/kubo#4293 (comment)
(the issue is that ipfs dns is not recursive and recently ipfs.io switched to indirect dnslink)

[alanshaw]

@shunkino if you're able to send a PR to interface-ipfs-core that would be fantastic ✨. Shout if have any questions.

We shouldn't really be relying on external services in our tests but I don't have a better idea right now :( Suggestions and PRs welcome 😎

[shunkino]

@alanshaw Sure, will send it soon! Thanks, let me ask you when I get one.
Yeah, I think same way as you about tests. But, dependence to ipfs.io is minimal, so I think it's acceptable.

# by the way, is there any reason ipfs.io has become multi-level IPNS name?

[alanshaw]

by the way, is there any reason ipfs.io has become multi-level IPNS name?

yes, there was - @lgierth should be able to comment (apologies I saw you explained this in IRC but I forgot the reason)

[ghost]

by the way, is there any reason ipfs.io has become multi-level IPNS name?

We wanted the dnslink to be in a different zone than the MX records, so that we can safely update automatically via Jenkins. It wasn't a hard requirement, just general security hardening.

[alanshaw]

This was fixed in ipfs-inactive/interface-js-ipfs-core#362