All specs
specs.ipfs.tech/dnslink-gatewayIPFSShould KnowProductBack Office2023

HTTP DNSLink Gateway Specification

Content Addressing & Decentralized Web·IPFS Specifications
WHY YOU NEED THIS

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`.

What It Defines

Defines how an HTTP gateway uses the inbound `Host` header to look up `_dnslink.<host>` TXT records and serve the resolved IPFS/IPNS content as a normal website at the root of that host. This is the spec that makes `https://mysite.example.com/about` Just Work for a browser when `mysite.example.com` is CNAMEd to a DNSLink-aware gateway and `_dnslink.mysite.example.com` contains `dnslink=/ipfs/bafy…`. The gateway resolves the TXT record, fetches the CID, and returns HTML/CSS/JS exactly as if it were hosting the site directly.

Canonical (Normative)

Convenient (Practical)

dnslinkgatewayipfshost-headerhttpcustom-domain
Standards Body
IPFS Specifications

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.

Visit

Related Specs

specs.ipfs.tech/dnslinkIPFSShould Know

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.

ProductBack OfficeContent Addressing & Decentralized Web
Details
specs.ipfs.tech/path-gatewayIPFSShould Know

Path 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.

ProductBack OfficeContent Addressing & Decentralized Web
Details
specs.ipfs.tech/subdomain-gatewayIPFSShould Know

Subdomain Gateway

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.

ProductBack OfficeContent Addressing & Decentralized Web
Details
RFC 1035RFCMust Know

DNS Implementation

The record types (A, MX, TXT, CNAME) you configure in every DNS panel live in this spec. Know what you're setting.

Back OfficeProductNaming & Addressing
Details
RFC 9110RFCMust Know

HTTP Semantics

This is the core contract of every web API, browser request, and server response. You can't design or debug HTTP without knowing this.

ProductHTTP
Details