Native DNS for NFDs
Expose Your .algo Domain via .algo.xyz
Introduction
With the release of DNS support in NFD on Algorand, you can now bind globally-resolvable DNS records to your .algo name—served directly from the Algorand blockchain. Through integration with the .algo.xyz TLD, names like somedapp.algo become somedapp.algo.xyz—and can be accessed via any DNS client, browser, or application worldwide.
Your NFD becomes a real, working domain:
patrick.algo.xyz- accessible via standard DNS
This means you can point your NFD to a website, receive email, configure SSL certificates, and more—all with records you control on-chain.
This creates a true Web3 DNS system using native DNS protocol standards, while retaining:
On-chain data control
Self-custodial ownership
Trustless resolution
How It Works
1. You configure DNS records in your NFD (stored on Algorand blockchain)
↓
2. The NFD DNS service reads your on-chain data
↓
3. Standard DNS queries resolve your NFD as a normal domainWhen someone queries patrick.algo.xyz, the NFD DNS service fetches your records from the blockchain and returns a standard DNS response. No special software needed—it just works with any browser or application.
Background: DNS and RR Types
DNS (Domain Name System) maps human-readable names to machine-usable data using resource records (RRs). Common RR types include:
A
IPv4 address of a host
AAAA
IPv6 address
TXT
Free-form text (often used for verification)
MX
Mail server settings
CNAME
Canonical alias (points one domain to another)
SRV
Advanced service routing
CAA
Certification authority authorization
Traditionally, these records are stored and managed via centralized registrars or DNS providers. In contrast, NFDs allow you to define these records on-chain.
Architecture
Storage
Each NFD stores its DNS records in a dns property—structured JSON stored on-chain inside its associated Algorand smart contract. This property is:
Versioned (requires NFD v3+)
User-editable via the NFD Manager
Strictly owned/controlled by the NFD's controlling account
Ownership & Security
Ownership of DNS records is cryptographically enforced by the Algorand blockchain:
You can use single-signature wallets, multisig accounts, or smart contract wallets to own NFDs.
No third-party registrar required.
Record changes are signed transactions.
This enables advanced workflows like:
Smart contracts updating DNS records automatically.
DAOs owning service domains like
community.algo.Multisig-controlled dApp endpoints (e.g.,
swap.algo.xyz).
DNS Record Format
DNS records are stored as JSON in your NFD. Each record has these fields:
name
Yes
Where the record applies (use @ for your domain)
type
Yes
Record type: A, AAAA, CNAME, MX, TXT, SRV, CAA
rrData
Yes
Array of record values
ttl
No
Cache time in seconds (default: 300)
Name Field
@— Your domain itself (e.g.,patrick.algo.xyz)www— A subdomain (becomeswww.patrick.algo.xyz)mail— Another subdomain (becomesmail.patrick.algo.xyz)grafana— A subdomain (becomesgrafana.patrick.algo.xyz)_dmarc— Special subdomain for DMARC records
Accepted name forms
All of the following are accepted and resolve to the same place under your NFD (patrick.algo):
@
patrick.algo.xyz (apex)
www
www.patrick.algo.xyz
www.@
www.patrick.algo.xyz
www.patrick.algo
www.patrick.algo.xyz
www.patrick.algo.
www.patrick.algo.xyz
www.patrick.algo.xyz
www.patrick.algo.xyz
The .@ suffix (e.g. www.@, _dmarc.@, _http._tcp.@) is the explicit canonical form—it states "this is a subname of my NFD." Bare labels like www work identically.
Scope: every record name is rooted under your NFD. You have DNS authority only over your own NFD and its subnames, so any name you store is interpreted as something inside your NFD's subtree.
A trailing dot in a standard DNS zone file means "fully qualified—don't append the origin." In NFD context that's almost always a mistake. To avoid this footgun, any name that isn't already inside your NFD's zone is re-rooted under it:
_test._tcp.(trailing-dot, no NFD) → serves as_test._tcp.patrick.algo.xyzevil.someone-else.algo.(a different NFD) → serves asevil.someone-else.algo.patrick.algo.xyz(you do not gain authority oversomeone-else.algo)
When in doubt, use the .@ suffix—it makes your intent explicit and is never re-rooted unexpectedly.
TTL (Time to Live)
Minimum: 60 seconds
Maximum: 86,400 seconds (24 hours)
Default: 300 seconds (5 minutes)
Lower TTL = faster updates, but more DNS queries. Higher TTL = better caching, but slower propagation of changes.
Managing DNS Records in Your NFD
Editing via UI
To add or modify DNS records:
Open the NFD Manager and select an NFD (version 3+).
Click DNS Editor.
Use "Add DNS Record":
Type: Choose one of the supported types (
A,AAAA,TXT, etc.)Name: Use
@to represent the root of the NFD (e.g.patrick.algo)TTL: Set time-to-live in seconds
Value: A string or list, depending on type (e.g. multiple IPs for an
Arecord)
How .algo.xyz Resolution Works
.algo.xyz Resolution WorksThe .algo.xyz TLD is backed by nfd-coredns, an open-source CoreDNS plugin that resolves DNS queries for Algorand NFDs by reading on-chain data directly from the blockchain. When a DNS query arrives for a domain like patrick.algo.xyz, the plugin:
Strips the
.xyzsuffixChecks a local cache for previously fetched records
Queries the Algorand blockchain if needed
Converts on-chain JSON data to standard DNS resource records
Returns the response as a normal DNS reply
The resolver supports all NFD DNS record types (A, AAAA, CNAME, MX, TXT, SRV, CAA, NS, SOA, CERT) and honors TTL values.
Run Your Own Resolver
Anyone can run their own NFD DNS resolver using the Docker image:
See the nfd-coredns GitHub repository for configuration details and setup instructions.
Live Resolvers
algo.xyzzone is currently served by:
Subdomain and Delegation Model
Unlike traditional DNS, the NFD subdomain model preserves segment ownership. A segment (e.g. api.patrick.algo) is its own NFD with its own owner, and it always serves its own DNS records—regardless of who owns the root NFD. How a segment combines with the root depends on ownership. There are three cases:
No segment NFD is minted — the root NFD serves the subname directly. A record stored on
patrick.algowith nameapianswersapi.patrick.algo.xyz.Segment owned by the same account as the root — the segment is merged with the root. The root can define sub-records that fall inside the segment, and root records win if both define the same name + type. This lets you manage a root NFD and the segments you own as one zone.
Segment owned by a different account — the segment alone is authoritative for its own subtree (
api.patrick.algoand everything under it). The root NFD owner has no DNS authority inside it, and any root records pointing into the segment's subtree are ignored. This mirrors how segments are sold and operated independently.
This prevents parent domains from hijacking subdomain content they do not own.
"Authoritative" here describes the NFD-ownership boundary, not a DNS delegation. The plugin still answers these names directly—there is no NS referral and no delegated subzone (NFD subdomains never have NS records; see Limitations below).
Resolution examples
The tables below assume a root NFD of patrick.algo. "Resolves to" is what a DNS query actually returns.
Scenario A — no api.patrick.algo segment is minted (root serves the subname):
Query
Record on patrick.algo
Resolves to
patrick.algo.xyz A
@ → 203.0.113.1
203.0.113.1
www.patrick.algo.xyz A
www → 203.0.113.2
203.0.113.2
api.patrick.algo.xyz A
api → 203.0.113.3
203.0.113.3 (root serves subname)
api.patrick.algo.xyz A
(no api record)
placeholder / NODATA
Scenario B — api.patrick.algo is a segment owned by the same account as the root:
Query
patrick.algo defines
api.patrick.algo defines
Resolves to
api.patrick.algo.xyz A
api → 1.1.1.1
@ → 2.2.2.2
1.1.1.1 (root wins the conflict)
api.patrick.algo.xyz AAAA
(none)
@ → 2001:db8::1
2001:db8::1 (segment merged in)
key.api.patrick.algo.xyz A
(none)
key → 3.3.3.3
3.3.3.3 (segment serves its subname)
Scenario C — api.patrick.algo is a segment owned by a different account:
Query
patrick.algo defines
api.patrick.algo defines
Resolves to
api.patrick.algo.xyz A
api → 1.1.1.1
@ → 2.2.2.2
2.2.2.2 (segment authoritative; root ignored)
key.api.patrick.algo.xyz A
key.api → 1.1.1.1
key → 3.3.3.3
3.3.3.3 (root has no authority inside segment)
api.patrick.algo.xyz A
api → 1.1.1.1
(no records)
placeholder (segment exists but empty)
Bluesky Integration
If you've verified your Bluesky account with your NFD, a TXT record for _atproto is automatically added. You don't need to configure this manually.
The system creates:
This enables your NFD to serve as your Bluesky handle.
Limitations
Segment depth: The
.algoname may have at most 4 labels, not counting leading_-prefixed service labels. Sokey.segment.patrick.algo(4 labels) resolves, buta.key.segment.patrick.algo(5 labels) is rejected. Underscore service labels are exempt, so_http._tcp.segment.patrick.algostill works.No NS records for subdomains: Your NFD subdomains are not delegated zones. NS records only work at the zone apex (
algo.xyzitself).Record types: The following types are supported: A, AAAA, CNAME, MX, TXT, SRV, CAA, NS, SOA, CERT
Expiration: If your NFD registration expires, DNS records will return a default placeholder until renewed.
Benefits Summary
Registrar Required
Yes
No
On-chain ownership
No
Yes
Smart contract control
No
Yes
Multisig/domain DAO control
No
Yes
Trustless resolution
No
Yes
Global compatibility
Yes
Yes
Next Steps
DNS Record Types — Complete reference for all supported record types with examples
Testing & Troubleshooting — Verify your DNS configuration and debug common issues
Conclusion
The .algo.xyz DNS bridge transforms your Algorand NFD into a global, resolvable domain using native internet infrastructure. This is a powerful blend of decentralization, security, and real-world interoperability—and it's available now.
Your domain. Your keys. Your records. Accessible from anywhere.
Last updated