Okay, so you were trying an
/ipfs/ multihash. AFAIK IPFS doesn't store the value for a given block's multihash/key in the DHT -- like it does for IPNS keys; rather, it stores pointers to peers that have said they can provide that multihash/key. So trying to use a raw DHT command to lookup a multihash's value is only going to find peers (which is what I think is in your verbose output, e.g.,
<peer.ID doLjVi> says use <peer.ID YU4giB> <peer.ID e7bRcN>...). I don't know if it would be expected for a DHT command to then query the peers for the actual value, but that sounds like it might be outside the scope of a vanilla DHT value get operation:
ipfs cat, etc.
I am a bit confused though because the abbreviated peer IDs shown in the verbose output don't seem to be the same ones that show up in
ipfs dht findprovs.
Doing DHT lookups using
ipfs dht get /ipns/... seems to be supported, though. If you look at the
ipfs dht put helptext, we can see that it explicitly states the /ipns keytypes are the only ones that are currently supported; so it might make sense that
ipfs dht get doesn't explicitly support any other keytypes at this point, either.
You may only use keytypes that are supported in your ipfs binary: currently
this is only /ipns. Unless you have a relatively deep understanding of the
go-ipfs routing internals, you likely want to be using 'ipfs name publish' instead
Understanding how the DHT is implemented (not sure how current it still is)