Strange command behaviors

[dylanPowers]

I'm getting a number of strange command behaviors. One of them being ipfs name resolve <url> giving an error of: Error: multihash too short. must be > 3 bytes when it worked fine on older versions. I'm also used to my daemon running as a system user and having my ipfs commands run through it. I can no longer do that. Was this done on purpose? Are ipfs commands no longer being routed through the daemon's http api server?
Another command nitpick is when ipfs cat is run "offline" I get an error of: Error: blockstore: block not found when I would expect the old behavior of being told the daemon is offline.

[wking]

On Tue, Jun 09, 2015 at 03:21:26PM -0700, Dylan Powers wrote:

I'm getting a number of strange command behaviors. One of them being
ipfs name resolve giving an error of: Error: multihash too short. must be > 3 bytes when it worked fine on older versions.

‘ipfs name resolve …’ is currently just for name entries using the DHT
(see #1307). Until we settle that, you should use one of:

$ ipfs resolve /ipns/
$ ipfs resolve --recursive /ipns/

But I just fixed a problem with non-recursive resolution in #1351
(currently unmerged).

[dylanPowers]

I didn't realize ipfs resolve existed, cool. However ipfs resolve --recursive /ipns/<url> is failing with Error: could not resolve name. for me on every url I enter.

[wking]

On Tue, Jun 09, 2015 at 04:35:47PM -0700, Dylan Powers wrote:

I didn't realize ipfs resolve existed, cool. However ipfs resolve --recursive /ipns/<url> is failing with Error: could not resolve name. for me on every url I enter.

It works for me. Without a local daemon:

$ ipfs --debug resolve --recursive /ipns/tremily.us
16:49:41.926 INFO cmd/ipfs: IPFS_PATH /home/wking/.ipfs main.go:282
16:49:41.926 DEBUG cmd/ipfs: looking for running daemon... main.go:292
16:49:41.926 DEBUG cmd/ipfs: Calling pre-command hooks... main.go:276
16:49:41.926 DEBUG cmd/ipfs: Executing command locally main.go:336
16:49:42.807 DEBUG namesys: Attempting to resolve /ipns/tremily.us with dns base.go:19
16:49:42.807 INFO namesys: DNSResolver resolving tremily.us namesys.go:71
16:49:42.809 DEBUG namesys: Resolved /ipns/tremily.us to /ipns/QmbqDJaoZYoGNw4dz7FqFDCf6q9EcHoMBQtoGViVFw2qv7 namesys.go:55
16:49:42.809 DEBUG namesys: Attempting to resolve /ipns/QmbqDJaoZYoGNw4dz7FqFDCf6q9EcHoMBQtoGViVFw2qv7 with dns base.go:19
16:49:42.809 DEBUG namesys: Attempting to resolve /ipns/QmbqDJaoZYoGNw4dz7FqFDCf6q9EcHoMBQtoGViVFw2qv7 with proquint base.go:19
16:49:42.809 DEBUG namesys: Attempting to resolve /ipns/QmbqDJaoZYoGNw4dz7FqFDCf6q9EcHoMBQtoGViVFw2qv7 with dht base.go:19
16:49:42.809 DEBUG namesys: RoutingResolve: 'QmbqDJaoZYoGNw4dz7FqFDCf6q9EcHoMBQtoGViVFw2qv7' namesys.go:71
16:49:42.809 DEBUG namesys: pk hash = QmbqDJaoZYoGNw4dz7FqFDCf6q9EcHoMBQtoGViVFw2qv7 namesys.go:71
16:49:42.810 DEBUG namesys: Resolved QmbqDJaoZYoGNw4dz7FqFDCf6q9EcHoMBQtoGViVFw2qv7 to /ipfs/QmV2FrBtvue5ve7vxbAzKz3mTdWq8wfMNPwYd8d9KHksCF namesys.go:55
/ipfs/QmV2FrBtvue5ve7vxbAzKz3mTdWq8wfMNPwYd8d9KHksCF16:49:42.810 INFO cmd/ipfs: Shutting down node... main.go:221
16:49:42.810 DEBUG core: core is shutting down... core.go:339
16:49:42.810 DEBUG blockservi: blockservice is shutting down... core.go:371
16:49:42.810 DEBUG blockservi: blockservice provide worker is shutting down... blockservice.go:148

And with a daemon (in which case the guts happen on the daemon):

$ ipfs --debug resolve --recursive /ipns/tremily.us
16:50:13.099 INFO cmd/ipfs: IPFS_PATH /home/wking/.ipfs main.go:282
16:50:13.099 DEBUG cmd/ipfs: looking for running daemon... main.go:292
16:50:13.099 INFO cmd/ipfs: a daemon is running... main.go:402
16:50:13.099 DEBUG cmd/ipfs: Calling pre-command hooks... main.go:276
16:50:13.099 INFO cmd/ipfs: Executing command on daemon running at /ip4/127.0.0.1/tcp/5001 main.go:322
/ipfs/QmV2FrBtvue5ve7vxbAzKz3mTdWq8wfMNPwYd8d9KHksCF

[dylanPowers]

I get the following when running offline:

$ ipfs --debug resolve --recursive /ipns/tremily.us
17:23:40.868  INFO   cmd/ipfs: IPFS_PATH /home/dylan/.ipfs main.go:282
17:23:40.868 DEBUG   cmd/ipfs: looking for running daemon... main.go:292
17:23:40.868 DEBUG   cmd/ipfs: Calling pre-command hooks... main.go:276
17:23:40.868 DEBUG   cmd/ipfs: Executing command locally main.go:336
17:23:41.028 DEBUG    namesys: Attempting to resolve /ipns/tremily.us with dns base.go:19
17:23:41.028  INFO    namesys: DNSResolver resolving tremily.us namesys.go:71
17:23:41.031 DEBUG    namesys: Attempting to resolve /ipns/tremily.us with proquint base.go:19
17:23:41.031 DEBUG    namesys: Attempting to resolve /ipns/tremily.us with dht base.go:19
17:23:41.031 DEBUG    namesys: RoutingResolve: 'tremily.us' namesys.go:71
17:23:41.031 WARNI    namesys: RoutingResolve: bad input hash: [%s]
tremily.us namesys.go:71
17:23:41.031 WARNI    namesys: No resolver found for /ipns/tremily.us base.go:19
17:23:41.031 WARNI    namesys: Could not resolve /ipns/tremily.us namesys.go:55
Error: could not resolve name.

[wking]

On Tue, Jun 09, 2015 at 05:24:16PM -0700, Dylan Powers wrote:

17:23:41.028 DEBUG namesys: Attempting to resolve /ipns/tremily.us with dns base.go:19
17:23:41.028 INFO namesys: DNSResolver resolving tremily.us namesys.go:71
17:23:41.031 DEBUG namesys: Attempting to resolve /ipns/tremily.us with proquint base.go:19
…
17:23:41.031 WARNI namesys: No resolver found for /ipns/tremily.us base.go:19

That's showing the all-protocol resolver iterating through available
resolvers 1 and failing with DNS 2. I don't know why you're
request fails while mine succeeds. You can test just the DNS resolver
with a build of #1351 :

$ ipfs --debug dns tremily.us
20:22:45.120 INFO cmd/ipfs: IPFS_PATH /home/wking/.ipfs main.go:282
20:22:45.120 DEBUG cmd/ipfs: looking for running daemon... main.go:292
20:22:45.120 DEBUG cmd/ipfs: Calling pre-command hooks... main.go:276
20:22:45.120 DEBUG cmd/ipfs: Executing command locally main.go:336
20:22:45.120 INFO namesys: DNSResolver resolving tremily.us base.go:19
20:22:45.128 DEBUG namesys: Resolved tremily.us to /ipns/QmbqDJaoZYoGNw4dz7FqFDCf6q9EcHoMBQtoGViVFw2qv7 dns.go:41
/ipns/QmbqDJaoZYoGNw4dz7FqFDCf6q9EcHoMBQtoGViVFw2qv7

Or a trace of the current master (which errors out but shows a good
first resolution):

$ ipfs --debug dns tremily.us
20:23:45.772 INFO cmd/ipfs: IPFS_PATH /home/wking/.ipfs main.go:282
20:23:45.772 DEBUG cmd/ipfs: looking for running daemon... main.go:292
20:23:45.772 DEBUG cmd/ipfs: Calling pre-command hooks... main.go:276
20:23:45.772 DEBUG cmd/ipfs: Executing command locally main.go:336
20:23:45.772 INFO namesys: DNSResolver resolving tremily.us base.go:19
20:23:45.774 DEBUG namesys: Resolved tremily.us to /ipns/QmbqDJaoZYoGNw4dz7FqFDCf6q9EcHoMBQtoGViVFw2qv7 dns.go:41
Error: could not resolve name (recursion limit exceeded).

If neither of those are working for you, can you post whatever your
local DNS service is getting for TXT tremily.us?

$ dig tremily.us TXT +short
"v=spf1 a include:verizon.net ~all"
"dnslink=/ipns/QmbqDJaoZYoGNw4dz7FqFDCf6q9EcHoMBQtoGViVFw2qv7"
"spf2.0/pra"
$ dig @8.8.8.8 tremily.us TXT +short
"v=spf1 a include:verizon.net ~all"
"dnslink=/ipns/QmbqDJaoZYoGNw4dz7FqFDCf6q9EcHoMBQtoGViVFw2qv7"
"spf2.0/pra"

And if that looks reasonable, I'd try running the namesys tests:

$ cd $GOPATH/src/github.com/ipfs/go-ipfs/namesys/
$ go test .
ok github.com/ipfs/go-ipfs/namesys 0.074s

[daviddias]

Can we get an update on the issue found? Is it still happening on 0.3.10 and 0.4.0? Thx

[lockedshadow]

Yes, it still happening on current 0.4.4. And due to this issue, DNS lookup redirect in IPFS Firefox addon looks broken with IPNS links (as described in issue referenced above).

[lidel]

ipfs dns → Error: could not resolve name (recursion limit exceeded) is tracked in #4293

[Stebalien]

The resolution logic has changed significantly since this issue was last touched and I can't reproduce. Feel free to reopen/comment if this is still an issue in the latest release.