Alternative DNS Roots Are Back: What the Agentic Web Changes

Alternative DNS roots matter again because AI agents need more than a memorable domain. They need a name they can resolve, an identity they can verify, and a machine-readable way to discover what a service can do. That turns a 30-year argument about internet naming into a practical question for the agentic web.

Handshake is not the first alternative root. AlterNIC, New.net, OpenNIC, Namecoin, and others all challenged the assumption that one organization should control the top of the naming system. Most ran into the same wall: a name that does not resolve through the user's normal path might as well not exist.

AI agents do not remove that wall. They make it more important.

First, What Is an Alternative DNS Root?

The DNS root zone is the top of the hierarchy that tells a resolver where to look for top-level domains such as .com, .org, or .th. An alternative root gives the resolver a different source of truth for that top layer.

Before DNS, the early internet depended on a centrally maintained HOSTS.TXT file. Paul Mockapetris defined DNS in RFCs 882 and 883 in 1983, and the system was deployed in 1984–85 under the coordination of Jon Postel.

Jon Postel, RFCs, IANA, and ICANN

• Jon Postel was an early internet researcher who helped coordinate domain names, IP addresses, and protocol numbers. He also served as the RFC Editor for nearly three decades.
• RFCs are “Requests for Comments”: permanent, numbered documents that record internet technical specifications, standards, and engineering guidance. All internet standards are published as RFCs, but not every RFC is a standard.
• IANA stands for the Internet Assigned Numbers Authority. The IANA functions perform technical coordination of globally unique internet identifiers, including DNS root-zone data, number resources, and protocol-parameter registries.
• ICANN stands for the Internet Corporation for Assigned Names and Numbers. It is the nonprofit organization created in 1998 to provide an institutional and globally participatory home for internet naming and identifier coordination.

The simplest distinction is that ICANN is the organization and governance framework, while IANA is the technical coordination function. Since 2016, the IANA functions have been performed by Public Technical Identifiers (PTI), a nonprofit affiliate of ICANN. In root-zone work, IANA processes and coordinates authoritative data changes while independent root server operators make that data available. IANA and ICANN are closely related, but they are not two names for the same thing.

The Internet Architecture Board's RFC 2826 explains why the public internet expects DNS names to have globally consistent meaning. ICANN makes the same unique-root case in ICP-3. When two roots assign the same spelling to different operators, the answer depends on which resolver you asked. Humans see a broken link. Agents may silently reach the wrong endpoint.

That is why an alt root is not just a new suffix or a branding exercise. It is a choice about naming authority and resolution.

The Old Alt-Root Problem Was Distribution

The history is full of technically interesting systems that never became a normal part of how people use the web. Some depended on browser deals. Some required plugins. Some reached only the users of a small resolver network. Some later watched ICANN delegate the same strings in the default root.

The recurring lesson is simple: the default path is the product. Chrome, Safari, iOS, Android, enterprise networks, and internet providers already use the IANA-coordinated default root. Asking someone to install a browser, change DNS, or trust a gateway creates friction before the page even loads.

This is the uncomfortable part for Handshake too. A decentralized root can remain operational while its convenient front doors disappear. The protocol and the distribution layer are not the same thing.

What AI Agents Change

A human can see a social post, recognize a logo, search for a company, and recover from a typo. An agent needs more explicit infrastructure. Before it can call another agent or service, it may need to answer four questions:

1. Resolution: Which network endpoint does this name identify?
2. Identity: What key or credential proves who controls it?
3. Capability: What can this service do, and in what format?
4. Policy: What may my agent send, sign, buy, or disclose?

A domain can help anchor that chain, but it cannot replace the rest of it. Owning helper.agent would not prove that the software is safe, that its manifest is honest, or that a payment request should be approved. The resolver, DNS records, HTTPS or DANE configuration, machine-readable manifest, and the user's own authorization policy all matter.

This is the agentic-web opportunity for alt roots: not “AI will make every Handshake name load in Chrome,” but “software agents can be configured to query the right resolver and inspect structured identity or capability records.” Agents can use DNS over HTTPS (DoH), which sends DNS lookups through an encrypted HTTPS connection to a chosen resolver, a local resolver, or a Handshake-aware browser without pretending the default internet has changed.

Why Handshake Is a Different Experiment

Handshake uses a blockchain to coordinate a decentralized root zone while retaining ordinary DNS below it. Its protocol paper describes the goal as replacing the root zone file and root servers, not replacing all of DNS.

It also made an important compatibility choice: existing ICANN root-zone entries were pre-reserved by consensus, along with a large set of established website names for their existing stakeholders to claim. A Handshake-aware resolver is not supposed to turn .com into a different namespace.

That is a better starting point than an alt root that casually reassigns names people already use. It still does not solve distribution. Users and agents must deliberately choose a Handshake-aware resolution path.

From a Name to an Agentic Service

A practical agentic naming stack could look like this:

1. A human or agent starts with a name.
2. A configured resolver looks up that name in the intended root.
3. DNS records direct the request to the service and help establish cryptographic continuity.
4. A machine-readable manifest describes the service, capabilities, endpoints, and supported payment or authentication methods.
5. The calling agent applies its own permission and risk rules before doing anything consequential.

We have already been experimenting with this direction through .agent, agent manifests, and machine payments. I shared one practical example in Agentic Commerce Live. The important idea is not that a domain makes an agent trustworthy. It is that an open naming layer can give agents a stable place to begin discovery and verification.

That also explains why resolver transparency matters. If an agent silently falls back to a public gateway, a centralized lookup API, or a search engine, the naming system may be decentralized in theory while the actual discovery path depends on one company.

The 2026 Naming Question Is Already Here

ICANN is currently studying whether a global DNS gTLD can be integrated with the same string in an alternative naming system in a secure and stable way. Its Technical Study Group proceeding is open for public comment through 21 September 2026 at 23:59 UTC.

This is not an abstract blockchain debate. If two systems use the same label, humans and agents need to know which root answered, who controls the result, and whether the same identity exists on both sides. A resolver preference hidden deep in a device or cloud environment can decide which service an agent reaches.

Handshake builders should participate with technical, specific comments. ICANN participants should also understand that alternative-root names may already have owners, users, records, and software built around them. Pretending either side does not exist will not make the collision disappear.

The Alt Root Series: Five Planned Articles

This article is Part 1 of a proposed five-article SkyInclude series about the part of internet naming that most people never see. Each numbered topic is intended to become a separate article. Parts 2–5 are planned future articles and will be researched, reviewed, and approved individually before publication.

1. Part 1 — this article: Why alt roots keep returning, and what AI agents change.
2. Part 2 — planned: Why Handshake protected existing ICANN names but still lost the default distribution path.
3. Part 3 — planned: What same-string names such as .chatbot can teach agent builders about resolver-dependent identity.
4. Part 4 — planned: How humans and cloud agents can actually resolve Handshake names in 2026.
5. Part 5 — planned: What ICANN's alternative-naming study means for existing Handshake owners and users.

I do not want to sell the fantasy that one download makes an alternative root universal. The useful work is more concrete: make resolution understandable, make agent identity inspectable, disclose centralized dependencies, and build services people and software can test today.

Download the Alt Root History Slides

We turned the history and agentic-web framework into a free 12-slide visual guide. Download the Alt Root History slides as a PDF to follow along, share with your team, or use in a community discussion.

Try Both Sides of the Agentic Naming Stack

To test the resolution layer, download SkyInclude Browser and try one regular DNS name and one Handshake name in the same session.

To give an AI agent a persistent, machine-readable identity, explore and search for a .agent domain on HeadlessDomains.

For transparency, HeadlessDomains is our company and a centralized service layer built on the decentralized Handshake root. The goal is to make agent identity practical while being clear about which parts are decentralized and which parts are operated by a company.

For the agentic web, what matters most first: a portable agent identity, a capability manifest, or a resolver that works everywhere your agent runs?