Diagnosing a delayed DNSLink release switch
A domain still serves yesterday’s IPFS website after a release. Three observations can separate a DNS publication mistake from a resolver that still has the previous answer cached.
Compare answers for the release domain
Set DOMAIN to the site hostname. Set the two DNS variables to an authoritative server for its zone and a recursive resolver used by the affected client. A DNSLink TXT record for immutable content contains a value like dnslink=/ipfs/<root>. Compare that root with the directory CID from the release.
dig +short TXT "_dnslink.$DOMAIN" @"$AUTHORITATIVE_DNS"
dig +short TXT "_dnslink.$DOMAIN" @"$RECURSIVE_DNS"
ipfs resolve "/ipns/$DOMAIN"
Identify which layer still sees the previous root
If the authoritative server has the old CID, inspect the record owner and the zone where you published it. If only the recursive answer is old, check the remaining TTL there. If both answers have the new root, compare Kubo’s resolved path and request the new root directly from the gateway. A successful direct read narrows the investigation to name resolution or HTTP caching. The DNS change alone does not copy any site files.