IPNS Published Revisions Appear Slowly

Hi everyone, I’m attempting to publish a revision to my site openbox.studio which uses dnslink to serve /ipns/k51qzi5uqu5dl6lwx0927ot5qg765dny7sne0gl54w4g0mxr9stsjf2z5i2471. When visiting the site canonically (via the link above) the content has updated as expected with the text “Update Test 2” however openbox.studio still shows the old content “Update Test”.

Why does this happen? I’m assuming the issue is DNS related so here are my current records (namecheap):

TXT: host: _dnslink value: dnslink=/ipns/k51qzi5uqu5dl6lwx0927ot5qg765dny7sne0gl54w4g0mxr9stsjf2z5i2471
A: host: @ value:
AAAA: host: @ value: 2602:fea2:2::1

Any help/guidance would make my day :slight_smile: thanks in advance.

Edit: As a side note I am using web3.storage to upload and publish my files.

Edit: The site has updated after removing and readding the DNS records. I’m still confused about why this happened…

The short answer is you are likely receiving a cached result, either due to one of TTLs, HTTP headers, or combination of both. If you need faster propagation, you could set TTLs to a lowert value (e.g. 1 minute), and tweak HTTP headers. Longer explanation below.

It may be more clear if we start from high level first.
You use three systems: DNS, IPNS, and HTTP (IPFS Gateway serving data behind DNSLink).
Each system has a concept of caching, based on implicit or explicit “TTL” value that controls how long cached result is ok to be reused before the system should look for an update.

When you have DNSLink that points at /ipns/{cryptographic-ipns-name} you have two(!) TTLs:

  • TTL of DNS TXT record that has dnslink=/ipns/.. value, it informs DNS servers to cache successful lookup result for the number of seconds indicated by TTL attribute
    • AFAIK usual default is either 5 minutes or 1h (unless you’ve set custom TTL while publishing DNSLink record)
  • TTL of IPNS Record serves similar purpose, but for IPNS Names. IPFS Gateway implementations usually use this value for caching, and will serve cached result and won’t look for updates until within the TTL window.
    • ipfs name publish in Kubo defaults to 1 hour TTL, can be adjusted during publishing (see ipfs name publish --help)

IPFS Gateway will resolve both, and then return HTTP response, which comes with own “ttl” based on HTTP caching headers (Last-Modified and/or Cache-Control headers), which impact HTTP caching on CDNs and in Web browsers. You can override HTTP caching header on a reverse proxy sitting in front of your IPFS gateway, but when it comes to HTTP you want to leverage caching to maximum, keeping TTL and HTTP Cache control as high as possible, to minimize cost of web hosting.