`ipfs name resolve` does not always return the freshest CID for IPNS on Kubo 0.20.0

Help
,
1

With --enable-pubsub-experiment --enable-namesys-pubsub enabled in IPFS 0.20.0, ipfs name resolve does not always return the most recent record I expect. However, if I add the -s option, it returns multiple results, one of which is the most recent one I was expecting. Currently, there seems to be no way to identify the freshness of a record in the CLI/API output. As a workaround, I’ve been using a Redis sorted set to track the first time a CID result appears, but this feels like a hack and I’m looking for a better solution.

2023-06-23 17.31.17
2023-06-23 17.31.171280Ă—260 63.9 KB

In the above example, when I first ran ipfs name resolve , it returned ...xyki , which is an outdated CID for that IPNS. After I added -s , the expected ...aa6m appeared. However, there’s no way to determine from the CLI/API output which one is the most recent.

1 Like
2

After downgrading to Kubo 0.15, following the hints from Kubo versions > 0.15.0 gateway and slow IPNS performance, I am now able to get a stable result from ipfs name resolve immediately after an IPNS is updated to a new CID.

1 Like
3

I think it’d be nice if the verbose output included the sequence field (IPNS Record and Protocol). And then also cache the newest one when it’s seen, ignoring older ones of course. I’m a bit surprised that second point doesn’t already happen…

4

@Jorropo is this a bug?

5
1 Like
6

It seems this issue still happens on 0.29.

When running this command ipfs name resolve -r -s -n rev.eth:

bafybeigzfqjlrn6us3ydgdgcnx24kzx2bdxzdiji77x37suudtjelk7bzu is the expected fresh result, however, sometimes, an outdated record bafybeifpgfpaweza6zw2br7udnrun7asfvy574j2elmdb7n3exwa4y4rfy is returned.

Screenshot 2024-06-13 at 8.49.55 PM
Screenshot 2024-06-13 at 8.49.55 PM1454Ă—286 160 KB

7

The same query always returns correct fresh result on 0.15.

Screenshot 2024-06-13 at 9.04.09 PM
Screenshot 2024-06-13 at 9.04.09 PM1844Ă—1308 377 KB

8

On 0.29, an outdated result pops up from time to time.

Screenshot 2024-06-13 at 9.06.18 PM
Screenshot 2024-06-13 at 9.06.18 PM1804Ă—1348 519 KB

9

The difference you experience is likely due to the more modern IPNS implementation respecting TTL and doing a better job caching a valid IPNS resolution result for longer, and not hitting the network every time.

Older Kubo/go-ipfs had hardcoded cache of 1m for /ipns/ids and that was all. It wasted resources by resolving the same path over and over, when someone browsed a website.

Latest versions respect TTL from IPNS Record and DNSLink (TTL of DNS TXT Record is respected and used for caching just like IPNS TTL one if you use DNS over HTTPS set via DNS.Resolvers).

In both cases, you are able to adjust TTL and its impact on caching as a publisher, or as a reader, see tips in:

10

That IPNS was published with Kubo 0.15 by calling Kubo RPC API with these parameters (snippet from our Swift wrapper code):

let result = try await IPFSDaemon.shared.api(
    path: "name/publish",
    args: [
        "arg": cid,
        "allow-offline": "1",
        "key": id.uuidString,
        "quieter": "1",
        "lifetime": "7200h",
    ],
    timeout: 600
)

At that time, --ttl still carries a (caution: experimental) warning so it was not specifying TTL. I’ll try tweaking the TTL value here.