DNSLink: Pointing a Domain Name at IPFS Content

DNSLink is the low-tech answer to the same problem the previous article in this series covers with IPNS: giving IPFS content a stable, human-friendly address. Instead of a cryptographic name derived from a key pair, DNSLink uses something that already exists on every domain, a DNS TXT record, to point a regular domain name at a CID or an IPNS name. No new infrastructure, no key management, just one line in a DNS zone file.

TL;DR:

• DNSLink maps a domain name to IPFS content using a TXT record prefixed with _dnslink, containing a value like dnslink=/ipfs/CID
• Resolving /ipns/example.org looks up that TXT record and follows it to the underlying content, using DNS's own resolution infrastructure instead of the IPFS DHT
• It solves the same core problem as IPNS, one stable address for content that changes, but through DNS's existing update mechanism (edit a record through your registrar) rather than cryptographic key management
• DNSLink and IPNS combine well: pointing a TXT record at an IPNS name instead of a raw CID gets IPNS's cryptographic verifiability with DNSLink's memorable, brandable address
• For anyone building a project on top of pinned AIOZ Pin content, static site, dapp frontend, documentation, DNSLink is the practical way to put a real domain in front of a CID without touching AIOZ Pin's own infrastructure at all

The Problem DNSLink Solves

A CID is precise but not memorable, nobody is typing bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi into a browser on purpose. IPNS, covered in this series' previous article, solves the underlying mutability problem with a cryptographic name, but that name is itself just a different long string, more stable than a CID, still not something a person recognizes as belonging to a specific project or brand. DNSLink closes that last gap using infrastructure that already exists everywhere: the domain name system.

How DNSLink Actually Works

DNSLink uses a TXT record, prefixed with _dnslink, on a domain to map that domain to either an IPFS address or an IPNS name. The exact syntax looks like this:

_dnslink.example.org TXT "dnslink=/ipfs/bafybeifld3uybj6azujisdnxu6cm7mombldpbt3au4g33nwnqx7dsgjrta"

When something resolves /ipns/example.org (note that DNSLink-resolved domains use the /ipns/ path prefix regardless of whether the target is a raw CID or an actual IPNS name, since both represent a mutable-lookup step), it looks up this TXT record on example.org and follows the value to the actual content. Updating what a domain points to is then just a matter of editing that one TXT record through whatever registrar or DNS provider already manages the domain, no different from updating an MX or CNAME record.

DNSLink vs. IPNS: Different Trust Models

The two solve the identical naming problem through genuinely different mechanisms. IPNS resolution is cryptographic: a record signed by a private key, verified against the corresponding public key, propagated through the DHT or PubSub, no central authority involved at any step. DNSLink resolution is DNS: it inherits DNS's existing trust model entirely, whoever controls the domain's DNS records controls what it resolves to, the same way they already control where its A or CNAME records point. That's a meaningfully different trust boundary, DNS resolution isn't self-certifying the way a signed IPNS record is, but it's also infrastructure every domain owner already has and already trusts for everything else about their site.

Combining Both: The Common Real-World Pattern

DNSLink and IPNS are frequently used together rather than as competing choices. A TXT record can point at an IPNS name instead of a static CID: dnslink=/ipns/k51q.... That combination gets the best of each, the domain stays memorable and brandable through DNSLink, and the content behind it can be updated by publishing a new signed IPNS record without ever touching a DNS setting again. Only the initial DNS configuration needs to happen once; every subsequent content update flows through IPNS's own publish mechanism instead.

What DNSLink Does Not Change

DNSLink is purely a naming and resolution layer, it does not change how the underlying content is stored, replicated, or verified. Whatever CID a DNSLink record ultimately points to still needs an actual host serving it, the exact discovery-and-availability problem this series' content-addressing article covers. A DNSLink record pointing at a CID nobody has pinned resolves the name correctly and then hits the same dead end an unpinned CID would hit on its own.

Setting One Up in Practice

Configuring DNSLink is a DNS operation, not an IPFS one: create a TXT record at _dnslink.<yourdomain> (or _dnslink.<subdomain> for a subdomain) with the value dnslink=/ipfs/<CID> or dnslink=/ipns/<name>, using whatever DNS management interface the domain's registrar or DNS host already provides. Propagation follows normal DNS TTL rules, the same delay any DNS change goes through, rather than anything specific to IPFS.

A Common Setup Mistake: The Wrong Record Location

The most common way a DNSLink setup fails isn't a syntax error in the record's value, it's putting the TXT record at the wrong name entirely. The record has to live at _dnslink.<domain>, not at the bare domain itself, easy to get backwards since most other DNS record types (A, CNAME, MX) do go directly on the domain name. For a subdomain like docs.example.org, the record goes at _dnslink.docs.example.org, following the same prefix pattern one level down. A quick way to confirm a setup actually works before pointing real traffic at it is a direct DNS lookup, dig TXT _dnslink.example.org, to check the record resolves and reads back exactly as intended, before testing it end to end through a gateway.

Where This Fits an AIOZ Pin Workflow

Nothing about DNSLink requires AIOZ Pin's involvement, and that's the point, it's a general IPFS technique that works over any CID regardless of who pinned it. A project using AIOZ Pin to keep a static site, dapp frontend, or document set online and replicated can independently set up a _dnslink TXT record on its own domain pointing at the CID currently pinned on AIOZ Pin (or at an IPNS name that gets republished each time a new version gets pinned), giving visitors a real, memorable URL while AIOZ Pin handles keeping the actual content available underneath it.

Frequently Asked Questions

What is DNSLink? A way to map a regular domain name to IPFS content using a DNS TXT record, instead of a cryptographic IPNS name or a raw CID.

What does a DNSLink TXT record look like? _dnslink.example.org TXT "dnslink=/ipfs/<CID>", or pointing at /ipns/<name> instead of a raw CID.

How is DNSLink different from IPNS? IPNS uses a cryptographically signed record verified against a public key. DNSLink uses ordinary DNS records, inheriting whatever trust and access control the domain's DNS already has.

Can DNSLink and IPNS be used together? Yes, and it's a common pattern: a DNSLink TXT record pointing at an IPNS name combines DNS's memorable domain with IPNS's ability to update content without changing the record again.

Does DNSLink replace the need for pinning? No. DNSLink only resolves a name to a CID; the content still needs to actually be hosted somewhere, which is what pinning is for.

Does using DNSLink require going through AIOZ Pin? No. DNSLink is a general DNS-based technique that works over any CID, including content pinned on AIOZ Pin, configured entirely through your own domain's DNS settings.

Related Reading

• IPNS: Mutable Pointers to Immutable IPFS Content - the cryptographic naming system DNSLink is commonly paired with
• Content Addressing vs. Location Addressing: Why IPFS Needs Pinning - why a resolved name still depends on someone hosting the content
• How AIOZ Pin Actually Keeps Your Files Online: Replication, CIDs, and Proof-of-Storage - what actually keeps the CID behind a DNSLink record retrievable
• How to Host a Static Website on IPFS (and Why Pin It) - the practical use case DNSLink most commonly gets paired with

References

• IPFS Docs: DNSLink