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.