DNS Decentralized Platform

Names and content solve different problems

A familiar domain gives readers an address they can remember. A release identifier specifies content. Keep the owner of the domain, the authoritative DNS operator, the delivery gateway, and the retained release visible as separate dependencies.

DNSLink uses a TXT record under a hostname prefixed with _dnslink to reference an IPFS or IPNS path. Its official documentation describes a mutable naming layer above content addressing. The record alone does not configure every requirement for HTTPS browser delivery.

Stage a publishing change

Build, retain, and test the new release before modifying the public pointer. Record the previous value and the intended new identifier. Use a staging hostname to verify how your DNS interface handles record names and how the gateway serves nested routes.

Limit publication automation to the records it needs where the provider supports that scope. A routine content release should not automatically require unrestricted authority over mail routing and the whole zone.

Verify resolution and delivery independently

Inspect the DNS answer and compare it with the release record. Then open the site over HTTPS, test a deep page and an image, and confirm the visible version. Separate a wrong record from a correctly resolved name whose gateway cannot serve the content.

Rehearse restoring an older pointer while its payload remains retained. Document observed caching and propagation behavior rather than promising an instant global switch. Keep domain recovery instructions available outside the account whose loss you are preparing for.

Reference pointIPFS: DNSLink records and resolution. The checks here are a proposed review framework; verify your own operating environment.