DNSLink
DNSLink is how you give an IPFS/IPNS deployment a stable human URL like `mysite.example.com` while the underlying CID changes every release. If you ever host static sites, agent artifacts, or signed manifests on IPFS and want a normal-looking domain, this is the spec.
What It Defines
Convention for storing an IPFS/IPNS path inside a DNS TXT record so a human-readable domain can resolve to content-addressed data. The record lives at `_dnslink.<domain>` (or sometimes the apex) with a value of the form `dnslink=/ipfs/<CID>` or `dnslink=/ipns/<name>`. Lookup is recursive: the value can itself be another DNSLink path, and clients chase the chain until they reach a terminal `/ipfs/...` CID. DNSLink does not replace DNS, HTTP, or TLS — it adds a content pointer layered on top of existing DNS.
Canonical (Normative)
Convenient (Practical)
Related References
Open community of implementers (Protocol Labs, Shipyard, Boost, Helia, Kubo, and others) that maintains the InterPlanetary File System spec family at specs.ipfs.tech. Publishes content-addressing primitives (CID, Multihash, Multibase, Multiaddr), the IPLD data model, naming systems (IPNS, DNSLink), and the HTTP Gateway specs (Path, Subdomain, Trustless, DNSLink) that bridge content-addressed storage to ordinary browsers.
Related Specs
The record types (A, MX, TXT, CNAME) you configure in every DNS panel live in this spec. Know what you're setting.
DNS is the phone book of the internet. Every domain, email MX record, SPF/DKIM TXT record, and service discovery entry depends on it.
Every DNSLink record, IPFS gateway URL, IPNS publish, and Filecoin deal references content by CID. If you do not understand what the bytes after `/ipfs/` mean, you cannot debug deploy/cache issues, validate signed manifests, or design content-addressed pipelines.
If you do not want to update a DNS TXT record on every deploy, point DNSLink at IPNS and republish the IPNS record to the new CID. IPNS is the mutable pointer that makes content-addressed storage usable for evolving sites.
DNSLink alone tells nobody how a browser request actually turns into a served HTML page. The DNSLink Gateway spec is the contract between your DNS records and the gateway that browsers hit — required reading if you operate a custom gateway for user sites under a wildcard like `*.dial.wtf`.
Path gateways break the web origin model — every CID shares the gateway origin. Subdomain gateways are the production-correct choice for hosting independent sites. This is also the only model that makes single-page apps with cookies and Service Workers function on a public gateway.
Path gateways are how a regular browser without IPFS support fetches content-addressed data. Knowing the spec is required to operate a self-hosted gateway, debug 404/range/CORS issues, or build clients that fall back from native IPFS to HTTP gateways.