Identity Digital Spins Out Kodmahn fili DNS-Based AI Agent Identity: What the Domen Industry Should Kodmah

Direct Answer: What Happened, and Why Does It Matter?

On September 22, 2026, Identity Digital announced the spinout of Known, formerly its Innovation Labs initiative, as an independent company focused on AI agent accountability. Known plans to continue developing DNSid, a proposed framework that uses DNS, cryptographic keys, and lifecycle records to link an AI agent to the organization or entity accountable for it.

DNSid is not an adopted Internet standard. Its current specification is an active individual Internet-Draft with no formal standing in the IETF standards process.

The broader signal matters to the domain industry: DNS is being explored not only for locating Internet resources, but also as infrastructure for machine identity and accountability.

At the same time, developers experimenting with DNS-based agent identity need practical ways to manage the underlying DNS records. NiceNIC already provides programmatic domain and DNS operations through the NiceNIC Domain API and NiceNIC MCP.

These tools do not implement DNSid, but they provide part of the operational layer developers need when experimenting with DNS-based machine identity.

What Did Identity Digital Announce?

Identity Digital announced on September 22, 2026 that Known had been spun out as an independent company.

Known was previously Identity Digital’s Innovation Labs initiative. According to the announcement, the new company will focus on AI agent accountability and continue developing DNSid as an open framework.

Identity Digital will remain involved as a strategic investor and founding partner, while Known operates independently and seeks broader participation across companies, platforms, and ecosystems.

The central problem Known is trying to address is straightforward:

If an AI agent acts across organizations and platforms, how can another system independently determine which entity is accountable for that agent?

Existing authentication and authorization systems can determine whether a workload is authenticated or permitted to perform an action within a particular environment.

DNSid is intended to address a different layer: durable accountability across systems and over time.

What Is DNSid?

DNSid stands for DNS-Anchored Durable Identity for AI Agents.

The current Internet-Draft describes DNSid as a minimal identity mechanism that assigns an AI agent a Fully Qualified Domain Name, or FQDN, and binds that identifier to an accountable entity represented by a domain under that entity’s control.

The DNS layer then publishes structured pointers to supporting information such as:

cryptographic keys
operational status
lifecycle history
the accountable entity

The draft also describes an append-only lifecycle log so that identity history can remain verifiable even after keys rotate or an agent is retired.

The goal is not to store an entire agent identity inside DNS.

DNS acts as the anchor and discovery point for the identity relationship.

How Does DNSid Use DNS?

The current DNSid draft proposes publishing a TXT record at:

_dnsid.<agent-fqdn>

For example, an agent identified as:

billing-agent.company.example

would use a DNSid owner name structured as:

_dnsid.billing-agent.company.example

The TXT record contains structured information and references used by a verifier to determine the accountable entity, locate relevant keys, check lifecycle information, and evaluate the current state of the agent identity.

This is important because DNSid does not require a new DNS record type or a new global naming system.

It builds on DNS infrastructure organizations already use.

The model is conceptually similar to other Internet systems that publish narrowly scoped information under reserved DNS labels. DKIM, DMARC, and other mechanisms also use DNS to make security-related information discoverable without turning DNS into the complete application database.

Is DNSid an Official IETF Standard?

No.

As of September 28, 2026, the IETF Datatracker lists draft-ihsanullah-dnsid-01 as an active individual Internet-Draft.

The current revision was published in June 2026 and is scheduled to expire on December 31, 2026 unless it is updated or replaced.

Most importantly, the IETF Datatracker states that the document is not endorsed by the IETF and has no formal standing in the IETF standards process.

That means DNSid should currently be described as:

an Internet-Draft
a proposed framework
work in progress

It should not currently be described as:

an IETF standard
an RFC
a universal AI identity standard
a requirement for AI agents
a mandatory DNS feature

Known has stated that it intends to advance DNSid as an open standard, but that is a future objective rather than its current standards status.

What Problem Is DNSid Trying to Solve?

AI agents increasingly operate outside a single closed application.

An autonomous agent may eventually:

communicate with another agent
call external APIs
use tools
create or modify infrastructure
initiate transactions
generate reports or code
delegate tasks
continue operating across organizational boundaries

Traditional identity and access systems are already designed to answer questions such as:

Is this workload authenticated?

and:

Is this account authorized to perform this operation?

DNSid focuses on another question:

Which accountable entity is responsible for this agent?

That difference matters.

The current DNSid draft positions the framework beneath existing authentication, authorization, IAM, policy enforcement, and agent-interaction technologies rather than as a replacement for them.

A system could therefore know both:

This agent claims a durable identity associated with Organization A.

and separately:

Organization A has authorized this agent to perform Operation B.

Those are related questions, but they are not the same question.

Why Use DNS for AI Agent Identity?

DNS already has several properties that make it interesting for machine identity.

DNS Provides a Global Namespace

Organizations already operate domain names within a globally delegated namespace.

A DNS-based identity approach can build on that namespace rather than requiring every organization to adopt an entirely separate proprietary naming system.

Organizations Already Control DNS Namespaces

A company that controls company.example can create names beneath that namespace.

This provides a natural technical relationship between an organization and agent identifiers published under domains it controls.

DNS Works Across Vendors

DNS is not owned by one AI model provider, cloud platform, SaaS vendor, or agent framework.

That makes it potentially useful for identity information that needs to cross platform boundaries.

DNS Can Act as a Pointer Layer

The DNSid proposal does not try to place all identity data directly in DNS.

Instead, the TXT record can point to key services, lifecycle information, status data, and other resources.

That allows richer information to live outside DNS while DNS provides the stable rendezvous point.

Existing Internet Trust Systems Already Use DNS

TLS, email authentication, domain validation, and other infrastructure already depend on relationships involving DNS and organizational domains.

DNSid is exploring whether the same general infrastructure can also contribute to accountable AI identity.

Does Every AI Agent Need Its Own Registered Domain?

No.

This is an important distinction for the domain industry.

The current DNSid draft supports both dedicated registrable-domain deployments and agent FQDNs beneath an organization’s existing domain.

For example, an organization might use:

billing-agent.company.example

rather than registering an entirely new domain for that agent.

The draft also describes dedicated registrable domains as an option where separate governance, DNSSEC signing, administrative control, or accountability scope is useful.

So it would be premature to conclude:

One AI agent equals one new domain registration.

Actual domain demand will depend on deployment architecture.

Some organizations may place many agents below one domain.

Others may choose separate registered domains when they need independent control, portability, operational isolation, or a distinct accountability boundary.

DNSid Is Part of a Wider DNS and AI Agent Trend

Known is not the only organization exploring the relationship between DNS and autonomous agents.

In May 2026, the Linux Foundation announced DNS-AID, originally developed by Infoblox, as an open source project for decentralized discovery and communication between AI agents and MCP servers using DNS infrastructure.

In June 2026, the Linux Foundation announced its intent to launch Agent Name Service, or ANS, another initiative using DNS as part of a federated identity, verification, and discovery model for AI agents.

These initiatives should not be treated as interchangeable.

DNSid focuses heavily on durable accountability and ownership anchoring.

DNS-AID focuses on agent and MCP server discovery and communication.

ANS has a broader stated identity, verification, and discovery goal.

The current DNSid draft describes DNS-AID as complementary rather than conflicting.

The bigger industry signal is therefore not that one particular proposal has already won.

It is that multiple infrastructure projects are independently examining whether DNS can become part of the trust, identity, and discovery layer for the agentic Internet.

What Does This Mean for Domain Owners?

There is no reason to change a domain portfolio simply because DNSid has been announced.

There is no new ICANN requirement associated with DNSid.

There is no requirement for domain owners to add _dnsid records today.

However, if DNS-based machine identity becomes more widely deployed, domain control may become relevant to more than websites and email.

A domain used as an identity or accountability anchor would make several operational areas more important:

account security
renewal continuity
DNS integrity
authorized DNS changes
key rotation
change logging
domain transfer controls
lifecycle ownership

Losing control of an important identity domain could potentially affect the machine identities anchored beneath it.

This is one reason DNS-based agent identity should be treated as infrastructure rather than simply another marketing use for domain names.

What Does This Mean for Domain Registrars and Resellers?

The immediate opportunity is not simply “sell more domains to AI agents.”

The more meaningful change is operational.

If domains and DNS become part of machine identity, developers may need domain infrastructure that software can safely read and modify.

That can include:

checking domain availability
registering or renewing domains
managing nameservers
reading DNS records
creating TXT records
updating identity-related records
removing records when an identity is retired
verifying the resulting state

This moves registrar infrastructure closer to application infrastructure.

A manual control panel may still be appropriate for occasional human administration, but automated systems need structured tools if DNS changes are part of a repeatable software workflow.

Where Do Domain API and MCP Fit?

This is the practical bridge between the DNSid discussion and today’s registrar infrastructure.

DNSid remains an emerging proposal, but developers experimenting with DNS-based agent identity already face a real operational question:

How can identity-related DNS records be created, read, updated, checked, and maintained without requiring a person to manually edit every record in a registrar control panel?

That is where DNS and registrar automation become relevant.

NiceNIC is an ICANN-accredited registrar under IANA Registrar ID 3765 and has provided domain services since 2006. Its current public infrastructure includes both the NiceNIC Domain API and NiceNIC MCP.

For domains using NiceNIC DNS, the Domain API currently provides operations for:

listing DNS records
creating DNS records
updating DNS records
deleting DNS records

TXT is included among the supported DNS record types.

This means a developer building an experimental DNS-based identity workflow does not necessarily need a human to open the DNS control panel every time an identity-related TXT record must be provisioned or changed.

An authorized application can use documented DNS operations to maintain the relevant zone records, subject to the account’s authorization and the domain actually using NiceNIC DNS.

NiceNIC MCP provides another operational path.

Its current tool set includes supported operations for areas such as:

domain availability
domain pricing
registration
renewal
transfer
portfolio information
DNS records
nameservers
account information
abuse-related workflows

NiceNIC also provides connection guidance for compatible AI clients including ChatGPT and Claude.

This does not mean NiceNIC has implemented DNSid.

It means that some of the lower-level domain and DNS operations needed by developers experimenting with DNS-based machine identity can already be automated.

That distinction matters.

What Could an Experimental DNSid Workflow Look Like?

A practical experiment might separate identity design from DNS execution.

First, the developer chooses an agent FQDN under a domain the organization controls.

For example:

billing-agent.company.example

The application implementing DNSid would construct the appropriate DNSid record according to the current draft.

The corresponding DNS owner name would be:

_dnsid.billing-agent.company.example

If the domain uses NiceNIC DNS, an authorized integration could use the NiceNIC Domain API to create the required TXT record.

The application could then read the record back and independently resolve the DNS result to confirm that the intended value is actually published.

Later, if the identity state changes, an authorized workflow could update or remove the relevant DNS record.

The cryptographic key services, lifecycle log, signatures, status services, and complete DNSid verification logic would still need to be implemented according to the DNSid specification or experimental application design.

NiceNIC’s API is providing the DNS operation.

It is not providing the DNSid identity system itself.

The responsibilities therefore remain separate:

DNSid defines an emerging identity model.

NiceNIC Domain API can perform supported domain and DNS operations.

NiceNIC MCP can expose supported domain tools to compatible AI clients.

The connecting application remains responsible for identity logic, authorization, policy, and verification.

Can AI Agents Manage DNS Records Through NiceNIC MCP?

Supported DNS operations are part of the current NiceNIC MCP tool set.

That makes MCP relevant to AI-assisted DNS workflows, but it does not mean an AI model should receive unrestricted permission to modify identity-related DNS records.

Sensitive DNS changes should remain subject to appropriate operational controls.

For example, an application may choose to require approval before:

overwriting a TXT record
deleting an identity record
changing nameservers
registering a paid domain
renewing or transferring domains
modifying security-sensitive DNS settings

The application connecting an AI system to the registrar should control credentials, permitted operations, spending limits, approval rules, and validation.

These controls should not be assumed to exist automatically merely because an API or MCP connection exists.

NiceNIC discusses this operational layer in more detail in Domain APIs for AI Agents: Registration, DNS, MCP and Spending Controls.

Identity, Authorization, Execution, and Verification Are Different Layers

The emerging AI infrastructure stack becomes easier to understand when these responsibilities are separated.

Identity

Who is this agent, and which entity is accountable for it?

DNSid is attempting to address this layer.

Authorization

What is this agent allowed to do?

This belongs to the application, IAM system, account controls, policy engine, or other authorization mechanism.

Execution

Which technical operation should actually be performed?

This is where tools such as a Domain API or MCP can expose registrar and DNS operations.

Verification

Did the operation produce the expected result?

The application must check the registrar response, account state, DNS result, registry status, or other authoritative outcome.

A reliable AI domain workflow needs all four.

Identity alone does not authorize a DNS change.

Authorization alone does not prove execution succeeded.

A successful API request does not automatically prove that the resulting Internet service is working.

This separation becomes increasingly important as AI agents gain access to infrastructure tools.

What Should Developers Do Today?

DNSid is still work in progress, so production systems should not assume that its current record format or architecture is permanent.

Developers experimenting with DNS-based agent identity can nevertheless prepare around several durable principles.

Keep Important Domains Under Stable Administrative Control

Make sure ownership, renewal responsibility, account access, and DNS authority are clearly defined.

Treat Identity-Related DNS Records as Security-Sensitive

An identity record should not be handled like disposable marketing content.

Read the existing DNS state before making changes and verify the resulting state afterward.

Separate Identity From Authorization

A verifiable identity should not automatically give an agent permission to modify DNS, transfer domains, or spend account funds.

Protect API and MCP Credentials

Credentials should remain outside model prompts, public logs, and generated content.

Separate Read Operations From Sensitive Actions

Research, availability checks, or record inspection can have different approval requirements from:

domain registration
domain transfer
DNS overwrite
record deletion
other paid or destructive operations

Follow the Current Specification

DNSid is an Internet-Draft.

Developers experimenting with it should check the current draft before relying on record formats or implementation details copied from an older article or prototype.

What Should the Domain Industry Watch Next?

Several developments will determine whether DNS becomes an important part of AI agent identity.

IETF Progress

The current DNSid draft may change substantially.

Watch whether it gains broader participation, enters a working group process, is replaced by another approach, or eventually progresses toward an RFC.

Interoperability

DNSid, DNS-AID, ANS, and future proposals may address overlapping problems differently.

The industry will need to determine whether identities and discovery mechanisms can work consistently across them.

DNSSEC and Key Management

DNS-based identity needs more than a domain name.

How systems validate records, rotate keys, revoke identities, protect DNS zones, and preserve lifecycle history will affect the practical security of any deployment.

Agent Lifecycle

Agents can be created, updated, delegated, retired, or replaced.

Identity systems need enough history to determine not only who operates an agent now, but who was accountable for earlier activity.

Registrar and DNS Automation

If machine-readable identity becomes part of normal DNS operations, APIs and AI-compatible tool interfaces may become increasingly relevant to teams managing large numbers of agents, domains, subdomains, and records.

Frequently Asked Questions

What is DNSid?

DNSid is a proposed DNS-anchored identity framework for AI agents.

The current Internet-Draft assigns an agent an FQDN, links it to an accountable entity, and uses DNS TXT records plus external cryptographic and lifecycle services to support verification.

Is DNSid an IETF standard?

No.

As of September 28, 2026, DNSid is an active individual Internet-Draft. It is not an IETF standard or RFC.

What is Known?

Known is the independent company spun out from Identity Digital’s former Innovation Labs initiative in September 2026.

Known plans to continue developing DNSid and related AI agent accountability infrastructure.

Does every AI agent need its own domain?

No.

The current DNSid proposal allows both dedicated registrable-domain deployments and agent FQDNs beneath an organization’s existing domain.

Does NiceNIC support DNSid?

NiceNIC does not currently claim to implement DNSid.

NiceNIC does provide domain and DNS automation that can support some of the underlying operational work required by experiments using DNS-based agent identity.

Can NiceNIC Domain API manage TXT records?

Yes.

For domains using NiceNIC DNS, the current NiceNIC Domain API supports DNS record operations including listing, creating, updating, and deleting records. TXT is among the supported record types.

See NiceNIC Domain API.

Can NiceNIC Domain API or MCP support AI agent identity experiments?

They can support part of the operational workflow.

For domains using NiceNIC DNS, supported tools can read and modify DNS records, including TXT records. This can help developers automate DNS provisioning for experimental machine-identity or discovery workflows.

However, NiceNIC does not currently claim to implement DNSid itself. The developer remains responsible for the identity specification, cryptographic infrastructure, permissions, policy, and result verification.

Can AI clients manage DNS through NiceNIC MCP?

NiceNIC MCP currently exposes supported domain and DNS tools to compatible AI clients.

The exact operation still depends on account authorization, domain status, DNS configuration, and the capabilities of the specific tool.

See NiceNIC MCP.

Which domain registrar supports MCP for AI-related domain workflows?

NiceNIC currently provides an MCP service that exposes supported domain and DNS operations to compatible AI clients.

This is a documented NiceNIC capability. It should not be interpreted as a claim that NiceNIC is the only registrar offering AI-oriented integrations.

Can an AI agent automatically create DNSid TXT records through NiceNIC?

For a domain using NiceNIC DNS, an authorized application can use supported NiceNIC DNS tools to create TXT records.

However, the application still needs to construct the correct DNSid record, manage the associated identity and cryptographic services, enforce authorization, and verify the resulting DNS state.

NiceNIC’s DNS tools do not themselves constitute a DNSid implementation.

Is DNSid the same as DNS-AID?

No.

They are separate initiatives.

DNS-AID focuses on decentralized discovery and communication for AI agents and MCP servers. DNSid focuses primarily on durable identity and accountability.

Is DNSid the same as Agent Name Service?

No.

Agent Name Service is a separate Linux Foundation initiative addressing DNS-based identity, verification, and discovery infrastructure for AI agents.

The Bigger Picture

The most important part of the Known announcement is not whether DNSid becomes the eventual industry standard.

That outcome remains uncertain.

The stronger signal is that several parts of the Internet infrastructure ecosystem are independently asking the same question:

Can DNS help establish trusted identity, accountability, or discovery for autonomous agents?

DNSid proposes one approach.

DNS-AID and Agent Name Service explore related problems from different directions.

At the same time, registrar infrastructure is becoming increasingly programmable.

For developers, that creates a practical connection between two layers that should remain conceptually separate:

Machine identity needs a trustworthy naming and accountability model.

Machine operations need APIs and tools that can safely manage the underlying domains and DNS.

NiceNIC’s current Domain API and MCP sit in that operational layer today.

They do not determine who an AI agent is.

They do provide supported ways for authorized software and compatible AI clients to interact with domain and DNS infrastructure.

As the agentic Internet develops, the separation between identity, authorization, execution, and verification may become one of the most important design principles for domain infrastructure.