Skip to content
This repository has been archived by the owner on Mar 10, 2020. It is now read-only.

DNS tests failing in go-ipfs #839

Closed
magik6k opened this issue Aug 26, 2018 · 10 comments
Closed

DNS tests failing in go-ipfs #839

magik6k opened this issue Aug 26, 2018 · 10 comments

Comments

@magik6k
Copy link
Contributor

magik6k commented Aug 26, 2018

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
Copy link
Contributor

daviddias commented Aug 27, 2018

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
Copy link
Contributor Author

magik6k commented Aug 27, 2018

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
Copy link
Contributor Author

magik6k commented Aug 27, 2018

@shunkino
Copy link
Contributor

shunkino commented Sep 1, 2018

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
Copy link
Contributor

lidel commented Sep 1, 2018

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
Copy link
Contributor

alanshaw commented Sep 4, 2018

@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
Copy link
Contributor

shunkino commented Sep 5, 2018

@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
Copy link
Contributor

alanshaw commented Sep 5, 2018

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
Copy link

ghost commented Sep 5, 2018

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
Copy link
Contributor

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

@ghost ghost removed the ready label Dec 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants