# Reproviding an IPNS record without changing it **URL:** \ **Category:** Kubo\ **Tags:** ipns\ **Created:** [April 7, 2019, 7:15pm UTC](https://discuss.ipfs.tech/t/reproviding-an-ipns-record-without-changing-it/5185 "2019-04-07T19:15:20Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![leerspace](https://avatars.discourse-cdn.com/v4/letter/l/94ad74/32.png) [@leerspace](https://discuss.ipfs.tech/u/leerspace)\ **Post date:** [April 23, 2019, 12:39pm UTC](https://discuss.ipfs.tech/t/reproviding-an-ipns-record-without-changing-it/5185/2 "2019-04-23T12:39:42Z")
> [@BenLubar](#): > > Is there a way to provide an existing IPNS record to the DHT? I don’t think this will be supported until [this issue](https://github.com/ipfs/go-ipfs/issues/1958) is closed. > [@BenLubar](#): > > Confusingly, my node seems to ask the entire DHT if it has a newer version of the record every time I do ipfs resolve on the IPNS key, despite being the only node that has ever held the private key for that PeerID. It seems like this is what’s causing a lot of IPNS-related slowness. You’re right that it’s looking for newer versions. It doesn’t know a priori that if it tries to look up a newer version in the DHT it won’t find one – since private keys for publishing can be shared. > [@BenLubar](#): > > There probably needs to be a way for the node to say “not only is this IPNS record good for 24 hours, but if you see it within 3 hours, you can just stop searching and accept it rather than continuing to search for a newer version.” I don’t know of a way to say “anything within the last 3 hours is fine”, but 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/ ``` --- _[View the full topic](https://discuss.ipfs.tech/t/reproviding-an-ipns-record-without-changing-it/5185)._