# Pin IPNS entries? **URL:** \ **Category:** Help\ **Tags:** js-ipfs, go-ipfs, ipns, dht\ **Created:** [April 24, 2019, 5:48pm UTC](https://discuss.ipfs.tech/t/pin-ipns-entries/5290 "2019-04-24T17:48:10Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![npfoss](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/npfoss/32/1318_2.png) [@npfoss](https://discuss.ipfs.tech/u/npfoss)\ **Post date:** [April 24, 2019, 5:48pm UTC](https://discuss.ipfs.tech/t/pin-ipns-entries/5290/1 "2019-04-24T17:48:10Z")
Is it possible to pin IPNS _entries_ so that your peers don’t have to wait forever for the DHT? Interested in the answer for both go-ipfs and js-ipfs. (I know DHT support is still not released for js-ipfs, but not whether this is written or even planned.) ---
**Author:** ![leerspace](https://avatars.discourse-cdn.com/v4/letter/l/94ad74/32.png) [@leerspace](https://discuss.ipfs.tech/u/leerspace)\ **Post date:** [April 25, 2019, 1:29am UTC](https://discuss.ipfs.tech/t/pin-ipns-entries/5290/2 "2019-04-25T01:29:02Z")
> [@npfoss](#): > > Is it possible to pin IPNS entries so that your peers don’t have to wait forever for the DHT? You mean like cache the entry? I think this already happens to some extent. It seems like the part that takes a long time is trying to find newer/better entries from the DHT. There are already timeout parameter and DHT limit parameters that can cut down on how long IPNS resolution takes if you don’t care about having the newest value. To copy paste from a [different thread](https://discuss.ipfs.tech/t/reproviding-an-ipns-record-without-changing-it/5185/2), you can do a couple of things to speed up name resolution if you don’t care about the newest record. ```bash # stream DHT entries as they're returned ipfs name resolve --stream /ipns/... # look for 2 records from the DHT to resolve the address, and only take up to 5 seconds ipfs name resolve --dhtrc 2 --dhtt 5s /ipns/ ``` ---
**Author:** ![npfoss](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/npfoss/32/1318_2.png) [@npfoss](https://discuss.ipfs.tech/u/npfoss)\ **Post date:** [April 27, 2019, 9:40pm UTC](https://discuss.ipfs.tech/t/pin-ipns-entries/5290/3 "2019-04-27T21:40:29Z")
That’s really useful to know, thank you! I guess my followup question then is: can you deliberately cache some entries? Also, how easy would it be to override which of your peers you asked for the lookup? For context, my use case is a social network. I’d like friends to be peers when online and cache each other’s IPNS entries (ID -\> profile-hash). On updates to your profile you send the new IPNS entry to your friends, they update their records, and then hopefully lookup done by another friend is fast. So recency does matter as well here. ---
**Author:** ![leerspace](https://avatars.discourse-cdn.com/v4/letter/l/94ad74/32.png) [@leerspace](https://discuss.ipfs.tech/u/leerspace)\ **Post date:** [April 28, 2019, 2:26pm UTC](https://discuss.ipfs.tech/t/pin-ipns-entries/5290/4 "2019-04-28T14:26:35Z")
> [@npfoss](#): > > I guess my followup question then is: can you deliberately cache some entries? Not that I’m aware of. There appears to be [some limited 1 minute caching](https://github.com/ipfs/go-ipfs/pull/1887) for all IPNS records, though that can be disabled during resolution. There’s also an experimental `ttl` option I haven’t played around with much. ```plaintext --ttl string - Time duration this record should be cached for. Uses the same syntax as the lifetime option. (caution: experimental). ``` > [@npfoss](#): > > Also, how easy would it be to override which of your peers you asked for the lookup? The IPNS key lookups go through the DHT. I’m not familiar enough with the code base to say how difficult it would be to specify that _only_ specific nodes should be used for IPNS DHT lookups. If you stay connected to nodes you want to use for IPNS resolution, I’d expect the current DHT lookups should already hit them.