DNS-Native AI Agent Naming and Resolution

Introduction The emergence of AI agents as autonomous software entities capable of communicating with each other and with humans creates new requirements for naming, resolution, and identity verification. Existing approaches often rely on centralized registries or application-layer discovery mechanisms that introduce single points of failure and do not leverage the globally distributed, well-understood DNS infrastructure. This document proposes a DNS-native approach that builds upon the foundational DNS specification and leverages the Service Binding (SVCB) and HTTPS DNS Resource Records defined in and for advanced service resolution. The core design principles are:

DNS is the authoritative source: DNS TXT and SVCB records serve as the single source of truth for agent identity and resolution, while HTTP-based mechanisms serve only as fallback mirrors.
Protocols are autonomous: Agent interaction protocols (e.g., , ) are decoupled from transport, each defining its own interaction semantics.
Default availability: Basic A/AAAA records ensure minimum connectivity, while enhanced resolution capabilities through SVCB are optional but recommended. When version is not explicitly specified, the highest priority (default) version is provided.

The key innovations of this specification include:

Use of SVCB records for multi-version distribution and protocol negotiation
Use of TXT records as identity trust anchors with public key publication and SVCB integrity protection
An HTTPS-based fallback mechanism (agent-dns.json) for clients without SVCB support
Flexible security model supporting both DNSSEC and signing

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are used throughout this document:

Agent:: An autonomous software entity capable of communicating with other agents or humans using defined protocols.
Agent Identifier:: A Fully Qualified Domain Name (FQDN) that uniquely identifies an agent.
Agent Protocol:: The application-layer protocol used for agent-to-agent communication (e.g., , ).

Design Principles This specification follows four core principles:

Principle	Description
DNS-First	DNS is the sole authoritative source for agent resolution; HTTP serves only as a readable mirror
Path-Independent	Version and endpoint selection are controlled by DNS, not URL paths
Protocol Autonomy	Agent interaction protocols are decoupled from transport
Default Availability	A/AAAA records guarantee minimum connectivity; enhanced features are optional. Default version is provided when not specified

Naming and Resource Location

Domain Name as Identity Each agent is uniquely identified by a stable Fully Qualified Domain Name (FQDN). Domain ownership combined with TLS certificates forms the foundation of agent identity.

Naming Rules

Use domain names or subdomains owned by the organization
Agent version changes do not introduce new identities
No registration with any central authority is required

Naming Examples

Resource Location via DNS This specification does not use URL paths for version expression. All version and endpoint selection is controlled by DNS records:

Query DNS SVCB records -> obtain version, endpoint, and protocol information
Query DNS TXT records -> obtain public key and verify identity
Connect to the TargetName:port specified in SVCB
Interact according to the protocol specification

DNS Record Design This specification uses three types of DNS records , each with distinct responsibilities. The SVCB record type is defined in and :

Record Type	Responsibility	Requirement
A / AAAA	Basic connectivity	REQUIRED - ensures minimum availability
TXT	Identity declaration, public key publication, SVCB integrity (svcb-digest), signature	REQUIRED - identity trust anchor
SVCB	Version distribution, endpoint resolution, protocol negotiation	RECOMMENDED - enhanced resolution

TXT Record: Identity Trust Anchor TXT records serve as the sole trust anchor for agent identity and integrity. Their responsibilities are strictly limited to four functions:

Declare agent identity
Publish public key / fingerprint
Protect SVCB record integrity via digest (svcb-digest)
Sign identity and integrity metadata (tamper-proof)

TXT Record Format

TXT Field Descriptions

Field	Description
v	Version identifier, fixed as 1
kid	Key identifier, used for key rotation
alg	Signature algorithm: Ed25519 (RECOMMENDED) or ES256
pk	Base64-encoded public key
svcb-digest	Base64-encoded SHA-256 digest of canonicalized SVCB records (OPTIONAL but RECOMMENDED when signing is used)
sig	Signature over record content (OPTIONAL but RECOMMENDED)

SVCB Record: Version Distribution and Protocol Negotiation SVCB (Service Binding) records are the core resolution mechanism, serving the following responsibilities:

Level	SVCB Role
Service Location	TargetName + port specify the service endpoint
Version Distribution	Private SvcParam declares agent version
Protocol Negotiation	Private parameters declare supported agent protocols

SVCB Record Example

Version and Protocol Resolution

SVCB Private Parameters This specification introduces two SVCB private parameters (SvcParam) as defined in to declare version and protocol:

Parameter	Semantics	Example
key65480	Agent version	"v3", "v2.1.0"
key65481	Agent protocols	"a2a", "a2a,anp"

Version Selection Behavior Clients can:

Default selection: When version is not specified, the highest priority version based on SVCB priority is used
Specific selection: Specify key65480 value to select a particular version
Protocol filtering: Select only versions supporting specific protocols (key65481)

ALPN Usage ALPN is used for TLS-layer protocol negotiation (e.g., h2, h3). Agent interaction protocols (, ) are declared via SVCB private parameters (key65481), not ALPN values. This ensures compatibility with existing TLS ecosystems and reserves space for future IANA registration.

Relationship Between Version and Protocol This specification clearly distinguishes two layers:

Layer	Declaration Location	Example
Agent Version	key65480	v3, v2.1.0
Agent Protocol	key65481	a2a, anp

HTTPS Fallback Mechanism To ensure "works by default" behavior, this specification introduces an optional but strongly recommended fallback mechanism.

agent-dns.json For clients that do not support SVCB queries, agents can publish a JSON mirror of DNS records at an HTTPS endpoint:

Media Type The agent-dns.json file MUST be served with the following HTTP headers: Servers SHOULD set an appropriate Cache-Control header. A value between 300 seconds (5 minutes) and 3600 seconds (1 hour) is RECOMMENDED.

JSON Signature The JSON file MUST include a signature for integrity protection. Unlike the TXT record signature which covers only TXT fields, the JSON signature covers the complete service binding information. The signature is computed over the canonical JSON representation of the document (excluding the sig field) as defined in (JSON Canonicalization Scheme).

JSON Schema Definition The agent-dns.json file MUST conform to the following JSON Schema:

File Structure Example

JSON Signature Computation The signature over the JSON file is computed as follows:

Construct the JSON object without the sig field.
Serialize using JSON Canonicalization Scheme (JCS) as defined in .
Compute the signature using the TLS private key.
Encode the signature using Base64.

JSON Signature Verification Clients MUST verify the JSON signature:

Fetch the JSON file over HTTPS.
Extract the sig field and remove it from the object.
Serialize the remaining object using JCS.
Obtain the public key from the txt.pk field in the JSON.
Verify the signature.
(RECOMMENDED for TLS-based signing) Verify that txt.pk matches the TLS certificate's public key.

If verification fails, the client MUST reject the JSON file. Note: When agent providers use separate key pairs (not TLS-based), the verification in step 6 is not applicable. In such cases, the integrity of the JSON file depends on the authenticity of the public key in txt.pk, which has the same trust anchor limitations as described in the Security Model Overview.

Design Principles

Mirror, not addition: JSON only mirrors information already in DNS; it does not introduce content absent from DNS
DNS remains authoritative: HTTPS JSON is only a "readable mirror", not a new authoritative source
Signature required: JSON files MUST be signed for integrity protection
Schema validated: Clients SHOULD validate JSON against the defined schema

Applicable Scenarios

Clients that do not support SVCB queries
Browsers / debugging tools
Early ecosystem transition period
Environments where DNS resolution is limited

Security This section defines the security mechanisms for ensuring the integrity and authenticity of agent resolution data.

Security Model Overview This specification provides two approaches for ensuring the integrity and authenticity of agent resolution data:

DNSSEC (RECOMMENDED): Protocol-level cryptographic authentication of DNS data
Signature-based Security (OPTIONAL but RECOMMENDED): Signing of TXT content, SVCB digest, and JSON fallback

Mechanism	Protection Scope	Trust Anchor
DNSSEC	All DNS records (TXT, SVCB, A/AAAA)	DNS root zone
Signature-based Security	TXT content, SVCB digest, JSON fallback	Web PKI (when using TLS keys) or self-declared (when using separate keys)

DNSSEC-based Security (RECOMMENDED) DNSSEC provides cryptographic authentication of DNS data at the protocol level. When enabled:

All DNS records are signed by the zone's DNSSEC keys
Clients with DNSSEC validation can verify record authenticity
No application-layer signatures are required

DNSSEC is the RECOMMENDED approach for environments where it is fully deployed.

Signature-based Security (OPTIONAL but RECOMMENDED) This specification defines an optional but recommended signing mechanism for integrity protection. Agent providers have two options for key management:

Option 1: TLS Certificate Keys (RECOMMENDED) Using the domain's TLS certificate keys provides a complete trust chain:

Uses the domain's TLS certificate private key for signing
Public key is published in the TXT record (pk field)
Enables verification through the established Web PKI trust chain
Clients can verify that pk matches the TLS certificate presented during HTTPS connection

When TLS-based signing is used:

The TXT record contains the TLS certificate's public key
The TXT record contains a digest of SVCB records (svcb-digest)
A signature covers the TXT content including the SVCB digest
Clients can verify the signature using the public key from the TLS certificate chain

Option 2: Separate Key Pair Agent providers MAY use a separate key pair (not derived from TLS certificates) for signing:

Agent provider generates and manages their own key pair
Public key is published in the TXT record (pk field)
Signature is computed using the corresponding private key

Trust Anchor Limitation: When using separate keys, the trust anchor is limited to the TXT record itself. If the TXT record is tampered with (e.g., via DNS spoofing or cache poisoning), an attacker could replace both the public key and signature, rendering the integrity protection ineffective. This is because:

The public key in the TXT record is self-declared without external verification
Clients have no independent trust anchor to verify the authenticity of the public key
SVCB records and agent-dns.json cannot be reliably verified if the TXT record is compromised

For this reason, when using separate keys:

DNSSEC deployment becomes more important to protect the TXT record itself
Clients SHOULD treat records from non-DNSSEC zones with appropriate caution
Out-of-band key distribution mechanisms MAY be used to establish trust

Choosing a Security Mechanism

Scenario	Recommended Approach
DNSSEC fully deployed	DNSSEC alone is sufficient
DNSSEC not available	Use TLS-based signing (Option 1)
High security requirements	Use both DNSSEC and signing (defense-in-depth)
HTTPS fallback required	Signing required for JSON integrity
	Using separate keys without DNSSEC	Limited trust; consider additional verification mechanisms

SVCB Integrity Protection When signature-based security is used, SVCB records are protected via a digest stored in the TXT record. This section defines the canonicalization and digest computation procedures.

SVCB Canonicalization To compute the svcb-digest, SVCB records MUST be canonicalized as follows:

Step 1: Collect and Sort

Collect all SVCB records for the agent's _agent prefix.
Exclude AliasMode records (priority = 0).
Sort records by priority in ascending order (lowest first).
If priorities are equal, sort by TargetName lexicographically.

Step 2: Normalize Each Record For each SVCB record, construct a canonical string in the following format: ]]> Where: - priority: Decimal integer with no leading zeros - target: Fully qualified domain name in lowercase, with trailing dot removed - params: SvcParams in sorted order by key number, formatted as key=value

Step 3: SvcParam Normalization SvcParams MUST be normalized as follows:

Sort by SvcParamKey number (ascending).
Format each parameter as: key<number>=<value>
String values are enclosed in double quotes.
List values (e.g., alpn) use comma separation with no spaces.
Separate parameters with a single space.

Canonical Format Example Note: alpn is SvcParamKey 1, port is SvcParamKey 3 as defined in .

Digest Computation + "\n" + + "\n" + ... digest_bytes = SHA-256(UTF-8(canonical_svcb)) svcb-digest = Base64Encode(digest_bytes) ]]> The resulting svcb-digest is approximately 44 characters (32 bytes encoded in Base64).

Signature Specification This section defines the signature mechanism when signature-based security is used.

Public Key Requirements The pk field contains the public key used for signature verification. There are two options:

When Using TLS Certificate Keys (RECOMMENDED) The pk field MUST contain the public key from the domain's TLS certificate:

Extract the SubjectPublicKeyInfo from the TLS certificate.
Encode using Base64 .
The certificate MUST be valid for the agent's domain name.

When Using Separate Key Pair The pk field contains the agent provider's self-managed public key:

Generate a key pair using a supported algorithm.
Extract the public key in SubjectPublicKeyInfo format.
Encode using Base64 .

Note: When using separate keys, the public key is self-declared and lacks an independent trust anchor. See Security Model Overview for implications.

Supported Key Types

EC P-256 (for ES256 algorithm) - RECOMMENDED
Ed25519 (for Ed25519 algorithm)

Signature Input Construction The signature input MUST be constructed by concatenating the following fields in order, separated by semicolons, with no trailing semicolon: Example: ~~~ v=1;kid=key-2025-01;alg=ES256;pk=MFkwEwYHKoZI...;svcb-digest=K7gNU3sdo+OL... ~~~

Signature Generation Where private_key is either: - The TLS certificate's private key (Option 1, RECOMMENDED), or - The agent provider's separately managed private key (Option 2) For ES256: signature is 64 bytes (r || s format), resulting in 88 Base64 characters. For Ed25519: signature is 64 bytes, resulting in 88 Base64 characters.

Signature Verification Procedure Clients MUST perform the following steps:

Parse TXT record and extract v, kid, alg, pk, svcb-digest, sig fields.
Reconstruct signing_input from v, kid, alg, pk, svcb-digest.
Decode pk from Base64 to obtain the public key.
Decode sig from Base64 to obtain the signature bytes.
Verify the signature using the specified algorithm.
(RECOMMENDED for Option 1) Verify that pk matches the TLS certificate presented during connection.

If verification fails, the client MUST reject the TXT record. When using Option 2 (separate key pair), clients should be aware that the signature only proves consistency between the TXT record content and the private key holder. Without DNSSEC or TLS binding, there is no external trust anchor to verify the key's authenticity.

TLS Certificate Binding Verification (Option 1 Only) When TLS certificate keys are used (Option 1), clients SHOULD verify that the pk in the TXT record matches the server's TLS certificate:

Establish TLS connection to the agent's domain.
Extract the public key from the server's certificate.
Compare with the pk field in the TXT record.
If mismatch, treat as verification failure.

This binding ensures that the entity controlling the TLS private key is the same entity that published the DNS records. Note: This verification is not applicable when separate key pairs are used (Option 2), as the pk in the TXT record will not match the TLS certificate.

Implementation Checklist

For Agent Publishers

Prepare domain name, configure HTTPS and TLS certificate
Configure DNS A/AAAA records (basic connectivity)
Configure DNS TXT record (_agent.xxx), publish public key
Configure DNS SVCB records, declare version and protocols
(RECOMMENDED) Publish /.well-known/agent-dns.json fallback file
(RECOMMENDED) Enable DNSSEC

For Client Developers

Query SVCB records, parse version and endpoint information
Query TXT records, extract public key
(Fallback) If SVCB unavailable, fetch agent-dns.json
Connect to endpoint per agent protocol (key65481) specification
(RECOMMENDED) Validate DNSSEC

DNS Record Configuration Example

Security Considerations This specification uses DNS as the authoritative source for agent resolution and identity information. Its security objectives are to ensure the authenticity, integrity, and verifiability of resolution results, rather than evaluating agent service quality or behavioral trustworthiness.

Threat Model This specification primarily considers the following threats:

DNS poisoning or cache pollution leading to incorrect endpoint resolution
Tampering with resolution results to redirect clients to unintended endpoints
Downgrade attacks inducing clients to use older versions or weaker protocols
Trust violations caused by expired or replaced identity declarations

Mandatory Security Requirements To address the above threats, this specification mandates:

Clients MUST complete TXT verification before using any SVCB resolution results
Clients MUST perform TXT-SVCB consistency checks
Clients MUST use TLS and verify server certificates
Clients MUST NOT use endpoints that fail verification
Agents MUST synchronously update TXT and SVCB information when versions or endpoints change

DNSSEC Usage

Agent operators SHOULD enable DNSSEC for their domains to enhance DNS-layer data integrity
Clients MAY verify DNSSEC signatures
This specification MUST NOT rely on DNSSEC as the sole security mechanism; its absence SHOULD NOT cause system unavailability

Specification Scope This specification guarantees the following properties:

Verifiability of agent identity
Integrity and consistency of resolution results
Encryption and tamper-proofing of connections

This specification does NOT attempt to address:

Agent capability authenticity
Service quality (SLA) or behavioral compliance
Agent reputation or governance issues

These concerns should be handled by upper-layer protocols, operational frameworks, or governance mechanisms.

IANA Considerations This document requests IANA registration of the following SVCB SvcParamKeys:

Number	Name	Meaning	Reference
65480	agent-version	Agent version identifier	This document
65481	agent-protocols	Comma-separated list of supported agent protocols	This document

Note: The values 65480 and 65481 are in the private use range (65280-65534) as defined in . Upon publication, these should be replaced with IANA-assigned values from the Expert Review range.