DNS-Native AI Agent Naming and Resolution

1.1. 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.¶

1.2. 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.¶

2.1. 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 [DNSAID] 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 ([RFC8552]) that other agent-related DNS specifications, including [DNSAID], 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 [DNSAID] 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.¶

6.1. 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.¶

# Recommended: dedicated subdomains
translator.agents.example.com
assistant.ai.example.org
agent123.agents.example.com

6.2. 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.¶

7.1. Mandatory DNS Data (MUST)

• A/AAAA [RFC1035]: 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.¶

7.2. Recommended DNS Data (SHOULD)

• SVCB [RFC9460] [RFC9461] with endpoint parameters and address hints (ipv4hint, ipv6hint): provide deterministic endpoint selection, protocol/version signaling, and reduced lookup latency.¶

• DNSSEC [RFC4033]: provide origin authentication and integrity for DNS RRsets.¶

• TXT identity anchor [RFC1035]: 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.¶

7.3. 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.¶

7.4. TXT Record: Identity Anchor (Conditional Metadata)

TXT records [RFC1035] 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)¶

_agents.translator.example.com. IN TXT (
  "v=1;"
  "kid=key-2025-01;"
  "alg=Ed25519;"                                       ; OPTIONAL
  "pk=base64-encoded-public-key;"                      ; OPTIONAL
  "sig=base64-encoded-signature;"                      ; OPTIONAL
  "svcb-digest=base64-encoded-sha256-digest;"          ; OPTIONAL
  "resolution-manifest=https://translator.example.com/
                   .well-known/resolution-manifest.json;" ; OPTIONAL
  "resolution-manifest-sha256=x48E9qOokqqrv="          ; OPTIONAL
)

7.5. SVCB Record: Version Distribution and Protocol Negotiation

SVCB (Service Binding) records [RFC9460] are the core resolution mechanism, serving the following responsibilities:¶

# Complete SVCB record example
_agents.translator.example.com. IN SVCB 1 agent-v3.example.com. (
  alpn=h2
  port=443
  ipv4hint=203.0.113.50
  ipv6hint=2001:db8::50
  key65480="v3"              ; Agent version
  key65481="a2a,anp"         ; Connection profile (post-selection)
)

# v2 version (lower priority)
_agents.translator.example.com. IN SVCB 2 agent-v2.example.com. (
  alpn=h2
  port=443
  ipv4hint=203.0.113.51
  key65480="v2"
  key65481="a2a"
)

7.6. Version and Protocol Resolution

8.1. 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.¶

8.2. 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.¶

8.3. 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.¶

9.1. agent-dns.json

For clients that do not support SVCB queries, agents can publish a JSON mirror of DNS records at an HTTPS endpoint:¶

https://{agent-id}/.well-known/agent-dns.json

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.¶

Content-Type: application/json; charset=utf-8
Cache-Control: max-age=300

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.com/agent-dns.schema.json",
  "title": "Agent DNS JSON",
  "description": "Mirror of DNS records for agent resolution",
  "type": "object",
  "required": ["agentId", "txt", "sig"],
  "properties": {
    "agentId": {
      "type": "string",
      "description": "The FQDN identifying the agent",
      "pattern": "^[a-zA-Z0-9]([a-zA-Z0-9-]*[a-zA-Z0-9])?
                  (\\.[a-zA-Z0-9]([a-zA-Z0-9-]*[a-zA-Z0-9])?)*$"
    },
    "txt": {
      "type": "object",
      "description": "Core identity fields from DNS TXT record",
      "required": ["v", "kid"],
      "properties": {
        "v": {
          "type": "string",
          "const": "1"
        },
        "kid": {
          "type": "string",
          "description": "Key identifier"
        },
        "alg": {
          "type": "string",
          "enum": ["ES256", "Ed25519"],
          "description": "Signature algorithm"
        },
        "pk": {
          "type": "string",
          "description": "Base64-encoded TLS certificate public key"
        }
      }
    },
    "svcb": {
      "type": "array",
      "description": "Mirror of DNS SVCB records",
      "items": {
        "type": "object",
        "required": ["priority", "target", "port"],
        "properties": {
          "priority": {
            "type": "integer",
            "minimum": 1,
            "maximum": 65535
          },
          "target": {
            "type": "string",
            "description": "Target hostname"
          },
          "port": {
            "type": "integer",
            "minimum": 1,
            "maximum": 65535
          },
          "alpn": {
            "type": "array",
            "items": {
              "type": "string"
            }
          },
          "agentVersion": {
            "type": "string",
            "description": "Agent version (mirrors key65480)"
          },
          "connectionProfile": {
            "type": "array",
            "items": {
              "type": "string"
            },
            "description": "Post-selection connection
                                    profile (mirrors key65481)"
          }
        }
      }
    },
    "sig": {
      "type": "string",
      "description": "Base64-encoded signature over canonical JSON
                                           (excluding sig field)"
    }
  }
}

{
  "agentId": "translator.example.com",
  "txt": {
    "v": "1",
    "kid": "key-2025-01",
    "alg": "ES256",
    "pk": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE..."
  },
  "svcb": [
    {
      "priority": 1,
      "target": "agent-v3.example.com",
      "port": 443,
      "alpn": ["h2"],
      "agentVersion": "v3",
      "connectionProfile": ["a2a", "anp"]
    },
    {
      "priority": 2,
      "target": "agent-v2.example.com",
      "port": 443,
      "alpn": ["h2"],
      "agentVersion": "v2",
      "connectionProfile": ["a2a"]
    }
  ],
  "sig": "MEUCIQC7..."
}

json_without_sig = { agentId, txt, svcb }
canonical_json = JCS(json_without_sig)
signature = Sign(TLS_private_key, UTF-8(canonical_json))
sig = Base64Encode(signature)

9.2. 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¶

9.3. Applicable Scenarios

• Clients that do not support SVCB queries¶

• Browsers / debugging tools¶

• Early ecosystem transition period¶

• Environments where DNS resolution is limited¶

10.1. 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¶

10.2. 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.¶

<priority> <target> <params>

# Original SVCB records:
_agents.translator.example.com. IN SVCB 2 agent-v2.example.com. (
  alpn=h2 port=443 key65480="v2" key65481="a2a"
)
_agents.translator.example.com. IN SVCB 1 agent-v3.example.com. (
  alpn=h2 port=443 key65480="v3" key65481="a2a,anp"
)

# Canonical representation (sorted by priority):
1 agent-v3.example.com key1=h2 key3=443 key65480="v3" \
  key65481="a2a,anp"
2 agent-v2.example.com key1=h2 key3=443 key65480="v2" key65481="a2a"

canonical_svcb = <line1> + "\n" + <line2> + "\n" + ...
digest_bytes = SHA-256(UTF-8(canonical_svcb))
svcb-digest = Base64Encode(digest_bytes)

10.3. Signature Specification

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

signing_input = "v=" + v + ";kid=" + kid
                 + ";alg=" + alg + ";pk=" + pk
if svcb-digest present:
  signing_input += ";svcb-digest=" + svcb-digest
if resolution-manifest present:
  signing_input += ";resolution-manifest="
                    + resolution-manifest
if resolution-manifest-sha256 present:
  signing_input += ";resolution-manifest-sha256="
                    + resolution-manifest-sha256

v=1;kid=key-2025-01;alg=ES256;pk=MFkwEwYHKoZI...;
resolution-manifest=https://translator.example.com/
.well-known/resolution-manifest.json

signature_bytes = Sign(private_key, UTF-8(signing_input))
sig = Base64Encode(signature_bytes)

11.1. 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¶

11.2. 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¶

11.3. DNS Record Configuration Example

; Basic connectivity
translator.example.com.    IN A     203.0.113.50
translator.example.com.    IN AAAA  2001:db8::50

; Optional TXT identity/security/resolution-manifest metadata
_agents.translator.example.com. IN TXT "v=1;kid=key-2025-01;
            alg=Ed25519;pk=...;sig=...;
            svcb-digest=...;
            resolution-manifest=https://translator.example.com/
            .well-known/resolution-manifest.json;
            resolution-manifest-sha256=x48E9qOokqqr7kbu9DBPE="

; Version resolution (SVCB)
_agents.translator.example.com. IN SVCB 1 agent-v3.example.com. (
  alpn=h2 port=443
  ipv4hint=203.0.113.50 ipv6hint=2001:db8::50
  key65480="v3" key65481="a2a,anp"
)
_agents.translator.example.com. IN SVCB 2 agent-v2.example.com. (
  alpn=h2 port=443 ipv4hint=203.0.113.51 key65480="v2" key65481="a2a"
)

12.1. 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¶

12.2. 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 [RFC8446] and verify server certificates [RFC9525]¶

• 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¶

12.3. Deployment Recommendations

• For Internet-facing agent domains, authoritative operators SHOULD enable DNSSEC [RFC4033].¶

• 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.¶

12.4. 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.¶

13.1. 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:¶

Note: The values 65480-65481 are in the private use range (65280-65534) as defined in [RFC9460].¶

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.¶

13.2. Underscored DNS Node Names

This document uses the _agents underscored owner-name label ([RFC8552]) 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 [DNSAID]'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 [DNSAID] has already requested registration of _agents in the "Underscored and Globally Scoped DNS Node Names" registry established by [RFC8552], 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.¶

14.1. Normative References

[RFC1035]

Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC4033]

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/rfc/rfc4033>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

[RFC8552]

Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/rfc/rfc8552>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9460]

Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

[RFC9461]

Schwartz, B., "Service Binding Mapping for DNS Servers", RFC 9461, DOI 10.17487/RFC9461, November 2023, <https://www.rfc-editor.org/rfc/rfc9461>.

[RFC9525]

Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023, <https://www.rfc-editor.org/rfc/rfc9525>.

14.2. Informative References

[A2A]

Google, "Agent2Agent Protocol (A2A)", 2025, <https://google.github.io/A2A/>.

[ANP]

ANP Community, "Agent Network Protocol (ANP)", 2025, <https://agent-network-protocol.com/>.

[DAWN-PS]

Akhavain, A. and H. Moussa, "Problem Statement for the Discovery of Agents, Workloads, and Named Entities", 2026, <https://datatracker.ietf.org/doc/draft-akhavain-moussa-dawn-problem-statement/>.

[DAWN-TERM]

Farrel, A., "Terminology for the Discovery of Agents, Workloads, and Named Entities", 2026, <https://datatracker.ietf.org/doc/draft-farrel-dawn-terminology/>.

[DNSAID]

Mozley, J., Williams, N., Sarikaya, B., Schott, R., and J. Damick, "DNS for AI Discovery", 2026, <https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/>.