IPNS and DNSLink

Summary

Changing content changes its IPFS content identifier. IPNS and DNSLink put an updateable name in front of that identifier. The name can keep pointing to the current publication while earlier CIDs continue to identify earlier content.

Neither mechanism stores the underlying files. Keep the named content available independently through pins or other retained replicas.

How IPNS works

An IPNS name identifies a public key. Its record contains a target path, a sequence number, validity information and a signature from the corresponding private key. Verification binds the update to that key without requiring a particular server to vouch for it.

Publishing is separate from signing. Records can travel through different routing systems. IPFS documentation describes publishing and resolving them through the DHT, and using PubSub topics to distribute records among interested peers. Kubo documents PubSub as an opt-in transport alongside DHT publication.

An operator must manage three different lifetimes:

A longer validity period can keep a signed record useful when its signer is unavailable, but also leaves an older valid record acceptable for longer. A signature proves authority; it does not prove that a resolver has found the newest update.

How DNSLink works

DNSLink publishes a TXT record at the _dnslink subdomain. Its value has the form dnslink=/ipfs/<CID> or can point to an IPNS path. Updating the DNS record changes the target; DNS caching affects when readers see the change.

The record belongs to the domain's DNS administration. The resulting trust boundary includes the domain controller and DNS resolution path. This follows from storing the binding in DNS: DNSLink does not turn the domain into an independently controlled IPNS key. A DNSLink path displayed under /ipns/ may still be a DNS name rather than a key-based IPNS name.

Trust model / threat model

Protect an IPNS private key as the authority to publish updates. With DNSLink, protect control of the relevant DNS records. If DNSLink points to an IPNS key, verify that key's record as well; the initial DNS binding remains a separate dependency.

A conventional HTTP gateway may resolve the name on your behalf. In that case you trust its resolution result unless your client independently verifies the signed record and addressed content. Naming and gateways also do not conceal which content is requested.

Readiness

Usable, with specifications and implementation documentation. Plan for republishing, resolver caches and recovery of the signing key or DNS account. Test updates through the actual resolution path your readers will use.

Limits

Names can resolve correctly while the content is unavailable. Stale records and caches can delay an update. Losing the IPNS signing key prevents further updates under that key. See An Uncensorable Website for publication planning and Choosing Decentralized Storage for retention choices.

Primary sources

• IPFS documentation: IPNS transports, validity and caching.
• IPNS record and protocol specification.
• DNSLink specification.
• IPFS documentation: DNSLink paths and publication.
• IPFS persistence and pinning.
• IPFS privacy and encryption.

Also in Sovereign Naming