# IPNS resolves to the old CID for some time after publishI
**URL:** https://discuss.ipfs.tech/t/ipns-resolves-to-the-old-cid-for-some-time-after-publishi/19994
**Category:** Help
**Tags:** go-ipfs, ipns
**Created:** [January 21, 2026, 12:58pm UTC](https://discuss.ipfs.tech/t/ipns-resolves-to-the-old-cid-for-some-time-after-publishi/19994 "2026-01-21T12:58:08Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@Caian](https://discuss.ipfs.tech/u/Caian)
#### Post date: [January 21, 2026, 12:58pm UTC](https://discuss.ipfs.tech/t/ipns-resolves-to-the-old-cid-for-some-time-after-publishi/19994/1 "2026-01-21T12:58:09Z")
Hi, I’m trying to bring new life to the `git-remote-ipld`project by supporting IPNS. This project still uses `go-ipfs-api`and has some issues with `kubo-rpc`. Nonetheless it’s working flawlessly… except for IPNS…
I’m using `ipfs.Shell.PublishWithDetails` to publish the new CID to a public key. The problem is that the key still resolves to the previous CID for several minutes after publishing on Kubo 0.39.
Is this expected?
This can cause missing refs on the upstream because the next push may not resolve the public key to the previous CID.
Thank you,
---
### Author:  [@ylempereur](https://discuss.ipfs.tech/u/ylempereur)
#### Post date: [January 21, 2026, 3:49pm UTC](https://discuss.ipfs.tech/t/ipns-resolves-to-the-old-cid-for-some-time-after-publishi/19994/2 "2026-01-21T15:49:17Z")
IPNS records have a TTL (just like DNS records do), which defaults to 5 minutes. Submit a smaller TTL at publish time if you want a faster response time.
---
### Author:  [@Caian](https://discuss.ipfs.tech/u/Caian)
#### Post date: [January 21, 2026, 4:10pm UTC](https://discuss.ipfs.tech/t/ipns-resolves-to-the-old-cid-for-some-time-after-publishi/19994/3 "2026-01-21T16:10:34Z")
I tried with a `ttl := time.Nanossecond` and got the same result. I was hoping that a 1ns ttl would instantly invalidate the cache, which it didn’t. Is it there a minimum TTL?
I understand the existence of a cache, but I find it odd that the cache is not consistent within the node and don’t get invalidated when a new publish occurs.
---
### Author:  [@ylempereur](https://discuss.ipfs.tech/u/ylempereur)
#### Post date: [January 21, 2026, 4:13pm UTC](https://discuss.ipfs.tech/t/ipns-resolves-to-the-old-cid-for-some-time-after-publishi/19994/4 "2026-01-21T16:13:10Z")
For super short TTLs, you need to enable `--enable-namesys-pubsub` when you start your daemon.
---
### Author:  [@Caian](https://discuss.ipfs.tech/u/Caian)
#### Post date: [January 21, 2026, 4:36pm UTC](https://discuss.ipfs.tech/t/ipns-resolves-to-the-old-cid-for-some-time-after-publishi/19994/5 "2026-01-21T16:36:22Z")
This combination worked, thank you.
Is it there a reason for a node not to replace it’s cache value when it receives another publish?
---
### Author:  [@ylempereur](https://discuss.ipfs.tech/u/ylempereur)
#### Post date: [January 21, 2026, 4:41pm UTC](https://discuss.ipfs.tech/t/ipns-resolves-to-the-old-cid-for-some-time-after-publishi/19994/6 "2026-01-21T16:41:41Z")
With pubsub enabled, I believe it does. Without, the node doesn’t receive the update until it goes and looks for it (the update is only sent to the DHT, not to the nodes themselves).