ipfs version 0.6.0 without --enable-namesys-pubsub ipfs name resolve QmSeJ41iXwebzm3KPTixBc3zoetBD61df76BRjE4RuY4YB
Error: context deadline exceeded or
Error: failed to dial QmSeJ41iXwebzm3KPTixBc3zoetBD61df76BRjE4RuY4YB: no addresses
The origin node QmSeJ41iXwebzm3KPTixBc3zoetBD61df76BRjE4RuY4YB was down, but when using ipfs dht get /ipns/QmSeJ41iXwebzm3KPTixBc3zoetBD61df76BRjE4RuY4YB > record
can retrieve the record, i can even use the ipfs dht put to broadcast it.
however ipfs name resolve still fails, seems it always try to dial to the origin node to resolve the record.
using DHTRendezvousKey ipfs dht findprovs bafkreiesyzwrb7uo6vrrfeokq7mzqhllc6dgjq343x53ue7ukbjtczeua4
lists several nodes that holds the recrod, most of the nodes are accessible with ipfs ping
not sure why it was not consistent in different command and is there a way to troubleshoot this issue ? @adin
this ipns record can be resolved from a vps in a different region.
@rick-li up until go-ipfs v0.7.0 ipfs name resolve actually resulted in 2 different lookups occurring instead of just one https://github.com/ipfs/go-ipfs/pull/7549 this might have been causing your problem and shouldn’t be an issue going forward.
In particular for some IPNS key /ipns/QmSeJ41iXwebzm3KPTixBc3zoetBD61df76BRjE4RuY4YB it would both try and figure out what the public key was that corresponded to QmSeJ41iXwebzm3KPTixBc3zoetBD61df76BRjE4RuY4YB and also the IPNS record that corresponded to /ipns/QmSeJ41iXwebzm3KPTixBc3zoetBD61df76BRjE4RuY4YB. One way that we tried to find a node’s public key was by doing a DHT search for that peer and then asking that peer for its public key and the other was by doing a DHT record search for the key /pk/QmSeJ41iXwebzm3KPTixBc3zoetBD61df76BRjE4RuY4YB. It’s possible that the public key record was not published in the DHT (especially if the publishing node was offline and you kept just doing ipfs dht puts of the IPNS record). Note, you also could have experienced inconsistency across machines because one of the machines might have had the public key for the IPNS record cached already.
As of go-ipfs v0.7.0 (go-ipfs v0.7.0-rc1 was recently released) we will no longer be doing this unnecessary public key search as searching the the public keys separately from the IPNS record has been unnecessary for a while already (we either embed the public key in the IPNS record, or if it’s small enough, like Ed25519 keys are, then the public key is embedded in the IPNS name).