]> Tsinghua University

Beijing 100084 China cuiyong@tsinghua.edu.cn http://www.cuiyong.net/

Applications Network Working Group AI agent DNS SVCB service resolution agent protocol This document specifies DNS-Native Agent Naming and Resolution (DN-ANR) for AI agents. DN-ANR uses domain names (FQDNs) as stable Agent Identifiers and resolves a selected Agent Identifier to verifiable endpoints and supported protocol/version information with a cryptographic integrity chain, with DNSSEC preferred. DN-ANR is a post-selection resolution profile. It does not define agent discovery, capability search, semantic matching, ranking, or routing decisions. Agent discovery, publication, or registry, including DNS-based mechanisms such as DNS-AID, may produce candidate Agent Identifiers; DN-ANR resolves and verifies the identifier selected by such mechanisms or by local policy. Within that scope, DN-ANR additionally defines DNS-based version distribution and deterministic version selection, canonicalized SVCB integrity cross-checking, and a signed HTTPS mirror for clients that cannot perform SVCB queries. While AI agents are the primary use case, the resolution and verification behavior defined here applies to any entity identified by an FQDN, such as services and workloads.

Introduction The emergence of AI agents as autonomous software entities creates concrete requirements for naming, trusted resolution, and endpoint verification. Existing deployments often mix discovery, semantic matching, and resolution into one control plane, which increases coupling and weakens interoperability. This document defines DN-ANR as a DNS-native resolution layer built on and Service Binding (SVCB/HTTPS RRs, , ). The design objective is strict scope control: discovery systems produce candidate Agent Identifiers, while DN-ANR securely resolves a chosen Agent Identifier into connection material. DN-ANR is a DNS-native post-selection resolution and integrity profile for a selected FQDN-based Agent Identifier. Related IETF work on the discovery of agents, workloads, and other named entities (see, for example, and ) frames discovery as an end-to-end problem: learning what entities exist, what they offer, and whether they can be trusted. Within such an end-to-end discovery workflow, DN-ANR addresses the final stage. Discovery mechanisms answer "which entity"; DN-ANR answers "how to reach it, and whether the resolution answer itself is authentic". DN-ANR is therefore intended to serve as a reusable resolution and verification component within layered entity-discovery architectures, and to align with the requirements and information models produced by such efforts.

Goals DN-ANR goals are:

1. Identity naming: use domain names/FQDNs as administratively managed Agent Identifiers.
2. Trusted resolution and connection guidance: resolve an Agent Identifier to endpoint(s), protocol/version declarations, and verifiable integrity material.
3. Post-selection interoperability: provide stable DNS-based resolution semantics that can be consumed after an Agent Identifier has been selected by local policy, user input, a registry, a gateway, or an agent discovery mechanism.
4. Deployment-flexible integrity: provide verifiable resolution integrity in both DNSSEC-enabled and DNSSEC-unavailable environments, via DNSSEC validation and/or application-layer TXT signatures with TLS certificate binding.

Non-Goals DN-ANR non-goals are:

• DN-ANR does not define agent discovery, publication, registry, or search.
• DN-ANR does not define organization-wide agent indexes, DNS-SD enumeration, cross-domain search, or capability search.
• DN-ANR does not provide semantic matching, capability ranking, reputation, governance, or task-routing decisions.
• DN-ANR does not standardize agent capability models, OpenAPI-like schemas, model cards, policy bundles, trust registries, or behavioral attestations.
• DN-ANR does not replace discovery specifications. It only specifies how to securely and deterministically resolve and verify an Agent Identifier after that identifier has been selected.

Relationship to Agent Discovery and Registry Specifications DN-ANR is intended to interoperate with, but not replace, discovery, publication, registry, indexing, or search specifications for agents and other named entities. Such specifications may use DNS, HTTP, private registries, directories, agent gateways, semantic search systems, or other mechanisms to produce one or more candidate Agent Identifiers. Problem statements and terminology for this broader entity-discovery space are being developed in the IETF (see , ); DN-ANR is positioned as the resolution and verification stage of such an architecture, and its requirements and information model are expected to align with the outputs of that work. DN-ANR starts after the selection step. A DN-ANR client is given exactly one selected Agent Identifier and resolves it to endpoint connection material, protocol/version declarations, and integrity metadata. For example, DNS-based discovery specifications such as define mechanisms for publishing AI agents in DNS so that other agents can discover them. Such specifications may define organization-level indexes, capability descriptors, DNS-SD entry points, or other discovery metadata. DN-ANR does not define those mechanisms. DN-ANR defines only the resolution and verification behavior for a selected Agent Identifier. Accordingly, DN-ANR does not define DNS-based enumeration, organization indexes, capability search, semantic matching, ranking, routing, reputation, or governance. These functions are expected to be handled by upper-layer discovery systems, private policy, registries, or operational frameworks.

Co-existence with DNS-Based Discovery Mechanisms DN-ANR is designed so that a publisher can deploy it alongside a DNS-based discovery mechanism such as without conflict. A discovery mechanism resolves "which agent," while DN-ANR resolves "how to connect to, and verify, that agent." An organization MAY use a discovery specification to publish and enumerate its agents, and use DN-ANR to publish the version distribution, deterministic endpoint selection, and integrity material for each individual agent once selected. To keep this co-existence unambiguous, DN-ANR intentionally reuses the _agents underscored owner-name label () that other agent-related DNS specifications, including , also use, rather than requesting a separate label. DN-ANR's usage is scoped one level deeper than an organization-wide inventory label: DN-ANR's records are published under _agents.<Agent Identifier> (for example, _agents.translator.example.com), naming the specific already-selected agent, rather than under _agents.<organization domain> as an inventory or index entry point. See IANA Considerations for further discussion of this label. Agent discovery, publication, registry, and indexing specifications may identify candidate agents. DNS-based discovery mechanisms such as are one example of that class. DN-ANR begins after such a mechanism, or local policy, has selected one Agent Identifier. DN-ANR then resolves that identifier to endpoint, protocol/version, and integrity material.

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., , ). Other DNS-based specifications may carry equivalent protocol identifiers in different DNS parameters; see Relationship to Agent Discovery and Registry Specifications.

Although this document uses AI agents as its primary use case, the resolution and verification behavior defined here applies to any entity identified by an FQDN, such as services or workloads. Where broader entity-discovery terminology (e.g., ) is in use, "Agent" in this document may be read as an FQDN-named entity.

Design Principles This specification follows five core principles:

Principle	Description
DNS-First	DNS is the authoritative source for Agent Identifier resolution; HTTP serves only as a fallback mirror
Layered Scope	Discovery and semantic selection are out of scope; DN-ANR resolves selected identifiers
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

Architecture Overview DN-ANR is a resolution-layer specification inside a three-layer architecture:

Layer	Examples	Scope
Discovery Layer	Web registry, agent gateway, search engine, semantic router, DNS-SD/mDNS	OUT OF SCOPE
Resolution Layer	Agent Identifier (FQDN) -> endpoint, protocol/version, integrity material	DN-ANR scope
Connection Layer	A2A, MCP, HTTPS, gRPC, other application protocols	OUT OF SCOPE

Interface boundary:

• Discovery Layer outputs one or more candidate Agent Identifiers (FQDNs).
• DN-ANR takes one selected Agent Identifier and resolves it into verifiable connection guidance.
• Connection Layer consumes DN-ANR outputs and executes protocol-specific session logic.

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:

1. Obtain (from Discovery Layer or local policy) a candidate Agent Identifier (FQDN)
2. Query DNS SVCB records -> obtain version, endpoint, and protocol information
3. If SVCB is unavailable, use A/AAAA resolution of the Agent Identifier as the default Agent Endpoint
4. Query DNS TXT records (if present) -> obtain optional application-layer security and resolution manifest metadata
5. Apply local security policy (e.g., DNSSEC validation and/or TXT signature validation)
6. Connect to the selected endpoint and interact according to the selected protocol specification

DN-ANR provides only deterministic resolution and verification for an already-selected identifier; it does not perform semantic discovery or ranking.

DNS Record Design This specification keeps DNS payloads minimal and operationally stable. DNS data is classified as MUST/SHOULD/MAY to separate core resolution from optional optimization.

Mandatory DNS Data (MUST)

• A/AAAA : provide baseline reachability and interoperability for resolvers and clients.

Rationale: A/AAAA guarantees minimum connectability and provides a default Agent Endpoint when no SVCB policy is available.

Recommended DNS Data (SHOULD)

• SVCB with endpoint parameters and address hints (ipv4hint, ipv6hint): provide deterministic endpoint selection, protocol/version signaling, and reduced lookup latency.
• DNSSEC : provide origin authentication and integrity for DNS RRsets.
• TXT identity anchor : publish optional application-layer security metadata and optional resolution manifest pointers.

Rationale: SVCB and DNSSEC substantially improve determinism, performance, and security. TXT metadata supports alternative or additional security models and resolution manifest linkage when needed.

Optional DNS Data (MAY)

• TXT signature fields (alg, pk, sig): used when signature-based verification is enabled.
• TXT SVCB integrity digest (svcb-digest): optional integrity cross-check material, especially for HTTPS fallback workflows.
• TXT resolution manifest pointer fields (resolution-manifest, resolution-manifest-sha256): pointer + digest for heavy external metadata.

Rationale: Heavy metadata evolves quickly and can grow large; keeping it out of DNS preserves DNS efficiency while retaining verifiable linkage.

TXT Record: Identity Anchor (Conditional Metadata) TXT records provide optional application-layer metadata. They are not a fallback encoding of service connectivity data: endpoint and connection parameters are carried exclusively in SVCB (or, as a baseline default, A/AAAA). Their responsibilities are strictly limited to:

1. Declare identity metadata (e.g., v, kid)
2. Optionally publish key/signature material (alg, pk, sig) for signature-based security
3. Optionally publish SVCB digest (svcb-digest) for integrity cross-check, especially with HTTPS fallback
4. Optionally publish external resolution manifest pointer metadata (resolution-manifest, resolution-manifest-sha256)

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 (OPTIONAL; REQUIRED when sig is present)
pk	Base64-encoded public key (OPTIONAL; REQUIRED when sig is present)
sig	Signature over selected TXT content (OPTIONAL; used in signature-based security mode)
svcb-digest	Base64-encoded SHA-256 digest of canonicalized SVCB records (OPTIONAL; useful for HTTPS fallback integrity cross-check)
resolution-manifest	Resolution manifest URI for external heavy metadata (OPTIONAL)
resolution-manifest-sha256	Base64-encoded SHA-256 digest of resolution manifest content (OPTIONAL; RECOMMENDED when resolution-manifest is present)

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
Connection Compatibility	Private parameters declare a post-selection connection-profile hint (supported agent protocols)
Performance Optimization	ipv4hint / ipv6hint reduce additional address lookups

SVCB Record Example

Version and Protocol Resolution

SVCB Private Parameters This specification introduces private SVCB parameters (SvcParam) as defined in :

Parameter	Semantics	Example
key65480	Agent version	"v3", "v2.1.0"
key65481	Connection profile (post-selection connection compatibility hint)	"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
• Connection compatibility selection: After an Agent Identifier has already been selected, clients MAY prefer SVCB alternatives whose key65481 (connection-profile) value matches a locally supported connection profile or agent protocol. This is not a discovery or ranking mechanism across different Agent Identifiers.

Scope of Private SvcParamKeys The private SvcParamKeys defined in this document are post-selection connection hints. They are scoped to one selected Agent Identifier and MUST NOT be used as a DNS-based mechanism to enumerate, search, rank, or advertise agents across an organization or across domains.

ALPN Usage DN-ANR treats ALPN as a transport-layer negotiation signal only (e.g., h2, h3). Agent interaction protocols (, ) are declared via SVCB private parameters (key65481, connection-profile), not ALPN values, and are consumed only after an Agent Identifier has been selected. This keeps DN-ANR compatible with existing TLS ecosystems and reserves ALPN identifier space for transport-layer use.

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

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

External Resolution Manifest Locator and Digest in TXT (Optional) DN-ANR supports optional linkage to heavy external metadata while keeping DNS payloads minimal:

• resolution-manifest in TXT contains an absolute URI that identifies a resolution manifest resource.
• resolution-manifest-sha256 in TXT contains the SHA-256 digest of the resolution manifest in Base64 encoding.

DN-ANR standardizes only:

• URI syntax and transport locator semantics.
• Digest algorithm (SHA-256) and digest encoding.
• Client verification flow (fetch resolution manifest -> compute digest -> compare -> consume).

DN-ANR does not standardize resolution manifest content schema (capability model, OpenAPI, model card, I/O schema, etc.). The resolution-manifest field is not a DNS-based discovery mechanism. It is a locator for external metadata associated with an already-selected Agent Identifier. DN-ANR does not define how clients search, rank, compare, or select agents based on resolution manifest contents. The presence of resolution-manifest MUST NOT be interpreted as an organization index, a capability registry, a ranking signal, or a statement that the agent is trusted for any particular task. Resolution manifest semantics, if any, are defined by upper-layer protocols or external specifications. Resolution manifest digest computation rules:

1. Fetch resolution manifest bytes from the URI in resolution-manifest.
2. If the resolution manifest media type is JSON, canonicalize using JCS before hashing.
3. For non-JSON media types, hash the raw octet stream as retrieved.
4. Compute SHA-256 and Base64-encode the result.
5. Compare with resolution-manifest-sha256; mismatch MUST be treated as verification failure.

Interoperability Gating for Resolution-Manifest-Dependent Clients

• A client that depends on resolution manifest data MUST require resolution-manifest; otherwise it MUST treat resolution-manifest-based logic as unavailable.
• A client that requires resolution manifest integrity verification MUST require both resolution-manifest and resolution-manifest-sha256.
• A publisher that wants interoperable resolution manifest verification SHOULD publish both TXT fields together.

Performance and Determinism

Why Address Hints SVCB ipv4hint and ipv6hint improve resolution behavior by:

• reducing extra A/AAAA lookup round-trips;
• improving first-connection determinism;
• reducing resolver-path jitter under recursive caching variance.

Recommended SVCB Publication Strategy

• Publishers SHOULD keep each SVCB RRSet compact and avoid excessive per-version record expansion.
• When many versions exist, publishers SHOULD keep only stable externally supported versions in DNS and move detailed capability/version matrices to external resolution manifests (resolution-manifest + resolution-manifest-sha256 in TXT).
• Publishers SHOULD keep endpoint migration agility by using shorter TTLs for SVCB than TXT.

TTL Guidance

• Identity anchors (TXT) SHOULD use relatively longer TTL values.
• Endpoint/control-plane records (SVCB) SHOULD use relatively shorter TTL values to support endpoint migration and rapid rollback.

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: The HTTPS fallback is a signed mirror for one selected Agent Identifier. It MUST NOT contain an organization-wide list of agents, search results, capability rankings, or registry data that is not part of the DNS resolution data for that Agent Identifier.

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:

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

JSON Signature Verification Clients MUST verify the JSON signature:

1. Fetch the JSON file over HTTPS.
2. Extract the sig field and remove it from the object.
3. Serialize the remaining object using JCS.
4. Obtain the public key from the txt.pk field in the JSON.
5. Verify the signature.
6. (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
• Single-identifier scope: the mirror reflects resolution data for exactly one selected Agent Identifier; it MUST NOT be extended into a multi-agent directory or index
• 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 complementary mechanisms for ensuring integrity and authenticity of agent resolution data:

1. DNSSEC (RECOMMENDED for Internet-facing deployments): Protocol-level cryptographic authentication of DNS data
2. Signature-based Security (OPTIONAL): TXT key/signature validation (pk, sig) with optional digest cross-checks (svcb-digest); if HTTPS fallback JSON is used, fallback signature validation is REQUIRED

Mechanism	Protection Scope	Trust Anchor
DNSSEC	All DNS records (TXT, SVCB, A/AAAA)	DNS root zone
Signature-based Security	TXT signed fields, optional SVCB digest consistency, JSON fallback signature (when fallback is used)	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.

DNSSEC Deployment Recommendations

• For publicly reachable agents, the authoritative zone SHOULD deploy DNSSEC.
• When DNSSEC validation is available and the SVCB RRSet (or TXT RRSet, when used) validates as bogus, clients MUST treat resolution as failure (fail-closed) and MUST NOT use that endpoint.
• Clients SHOULD apply stricter fail-closed behavior at least to SVCB and TXT (when TXT is part of the selected trust path).
• In enterprise/private networks where DNSSEC is not deployed, operators MAY rely on TXT signatures and TLS certificate binding as a minimum trust baseline.

When DNSSEC is enabled:

• All DNS records are signed by the zone's DNSSEC keys.
• Clients with DNSSEC validation can verify record authenticity.
• Application-layer signatures remain useful for defense in depth and for JSON fallback integrity.

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:

1. The TXT record contains the TLS certificate's public key
2. A signature covers the selected TXT fields
3. svcb-digest MAY be included as optional integrity cross-check material (especially for HTTPS fallback consistency checks)
4. 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	JSON signing and/or svcb-digest consistency checks are recommended
Separate keys without DNSSEC	Limited trust; consider additional verification mechanisms

SVCB Integrity Digest (Optional) When svcb-digest is present in TXT, SVCB records can be cross-checked for integrity (for example, during HTTPS fallback reconciliation). 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

1. Collect all SVCB records for the agent's _agents prefix.
2. Exclude AliasMode records (priority = 0).
3. Sort records by priority in ascending order (lowest first).
4. 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:

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

Canonical Format Example Note: alpn is SvcParamKey 1, port is SvcParamKey 3 as defined in . The trailing backslash and line break after key65480="v3" above are wrapping for document display only; the actual canonical string for that record contains no line break at that position.

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:

1. Extract the SubjectPublicKeyInfo from the TLS certificate.
2. Encode using Base64 .
3. 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:

1. Generate a key pair using a supported algorithm.
2. Extract the public key in SubjectPublicKeyInfo format.
3. 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 When signature-based TXT validation is used, the signature input MUST be constructed from TXT fields as follows:

1. Include required fields in this exact order: v, kid, alg, pk.
2. If present, append optional fields in this exact order: svcb-digest, resolution-manifest, resolution-manifest-sha256.
3. Use key=value pairs separated by semicolons, with no trailing semicolon.

Example (line-wrapped for display only; the actual signing input contains no line break):

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:

1. Parse TXT record and extract v, kid, alg, pk, sig, and any optional signed fields present.
2. Reconstruct signing_input using the required/optional field ordering defined above.
3. Decode pk from Base64 to obtain the public key.
4. Decode sig from Base64 to obtain the signature bytes.
5. Verify the signature using the specified algorithm.
6. (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:

1. Establish TLS connection to the agent's domain.
2. Extract the public key from the server's certificate.
3. Compare with the pk field in the TXT record.
4. 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

1. Prepare domain name, configure HTTPS and TLS certificate
2. Configure DNS A/AAAA records (basic connectivity)
3. (OPTIONAL) Configure DNS TXT record (_agents.xxx) for signature metadata (alg/pk/sig), svcb-digest, and/or resolution manifest pointer fields
4. Configure DNS SVCB records with endpoint, protocol/version, and (SHOULD) address hints
5. (OPTIONAL) Publish resolution manifest URI + digest in TXT (resolution-manifest, resolution-manifest-sha256) for heavy metadata externalization
6. (RECOMMENDED) Publish /.well-known/agent-dns.json fallback file
7. (RECOMMENDED for public deployments) Enable DNSSEC

For Client Developers

1. Query SVCB records, parse version and endpoint information
2. If SVCB is unavailable, use A/AAAA of the Agent Identifier as the default endpoint
3. Query TXT records (if present), parse optional fields (pk, sig, svcb-digest, resolution-manifest, resolution-manifest-sha256)
4. If resolution manifest fields are present and required by local policy, fetch the resolution manifest and verify digest before use
5. (Fallback) If SVCB unavailable, fetch agent-dns.json when needed
6. Connect to endpoint per the selected connection-profile (key65481) value
7. Validate DNSSEC when present, and fail closed for bogus SVCB/TXT results that are part of the selected trust path

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 establish at least one validated integrity path before endpoint use: DNSSEC validation, or TXT signature verification when TXT signing fields are used
• Clients MUST perform TXT-SVCB consistency checks when svcb-digest is present and selected by local policy
• Clients MUST use TLS and verify server certificates
• Clients MUST NOT use endpoints that fail verification
• Agents that publish svcb-digest or TXT signatures over endpoint-related metadata MUST synchronously update TXT and SVCB information when versions or endpoints change

Deployment Recommendations

• For Internet-facing agent domains, authoritative operators SHOULD enable DNSSEC .
• If DNSSEC data is present and validates as bogus for SVCB (or TXT, when TXT is part of the selected trust path), clients MUST fail closed for that endpoint.
• For private/enterprise deployments without DNSSEC, clients SHOULD require TXT signature verification and TLS certificate validation as minimum controls.
• This specification does not require DNSSEC as the only trust mechanism; deployments MAY combine DNSSEC and signature-based protections.

Specification Scope DN-ANR verifies the authenticity, integrity, and consistency of agent resolution data. It does not assert that the resolved agent is benign, competent, authorized for a task, compliant with policy, or reputable. Those judgments are made by upper-layer protocols, governance systems, trust registries, organizational policy, or other discovery and selection mechanisms. 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

SVCB Service Parameter Keys This revision uses Private Use SvcParamKeys only for experimentation. No permanent SvcParamKey codepoint is requested in this revision. The following private-use keys are used in examples and experimental deployments:

Private-use key	Experimental name	Meaning
key65480	agent-version	Agent version or endpoint profile revision
key65481	connection-profile	Post-selection connection compatibility hint (supported agent protocols for the selected identifier)

Note: The values 65480-65481 are in the private use range (65280-65534) as defined in . Future revisions may request permanent SvcParamKey registrations for connection-profile (and, if warranted, agent-version) after coordination with related agent discovery, publication, registry, and connection-profile specifications, including possible alignment of protocol identifier values with registries proposed by such specifications.

Underscored DNS Node Names This document uses the _agents underscored owner-name label () as a prefix for per-agent resolution records (for example, _agents.translator.example.com). This is the same label used by DNS-based agent discovery mechanisms, including 's organization-level inventory mechanism; however, DN-ANR's usage is scoped one level deeper, under the specific already-selected Agent Identifier, rather than under an organization's root domain (see Relationship to Agent Discovery and Registry Specifications). Because has already requested registration of _agents in the "Underscored and Globally Scoped DNS Node Names" registry established by , this document does not request a separate or duplicate registration for that label in this revision. Should working-group review determine that the two usages require distinct registry entries, this section will be revisited in a future revision.

References Normative References This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. The SVCB DNS resource record type expresses a bound collection of endpoint metadata, for use when establishing a connection to a named service. DNS itself can be such a service, when the server is identified by a domain name. This document provides the SVCB mapping for named DNS servers, allowing them to indicate support for encrypted transport protocols. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Google ANP Community Infoblox, Inc. Infoblox, Inc. Unaffiliated Deutsche Telekom Amazon

Acknowledgments The author thanks Chenguang Du for his valuable contributions to the design and text of this draft.