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. Foundational support for discovery systems: expose only minimal stable pointers/indexes that upper-layer discovery systems MAY reference.¶

1.2. Non-Goals

DN-ANR non-goals are:¶

• DN-ANR does not provide cross-domain agent discovery by semantics or capability.¶

• DN-ANR does not provide semantic matching, capability ranking, or task-routing decisions.¶

• DN-ANR does not standardize heavy capability metadata schemas inside DNS.¶

• DN-ANR only specifies how to securely and deterministically connect after an Agent Identifier has been selected.¶

5.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.company.com
agent123.agents.example.com

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

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

6.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 descriptor pointers.¶

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

6.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 descriptor pointer fields (agent-desc, agent-desc-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.¶

6.4. TXT Record: Identity Anchor (Conditional Metadata)

TXT records [RFC1035] provide optional application-layer metadata. 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 descriptor pointer metadata (agent-desc, agent-desc-sha256)¶

_agent.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
  "agent-desc=https://translator.example.com/
                   .well-known/agent-descriptor.json;" ; OPTIONAL
  "agent-desc-sha256=x48E9qOokqqrv="                   ; OPTIONAL
)

6.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
_agent.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"         ; Supported agent protocols
)

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

6.6. Version and Protocol Resolution

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

7.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 descriptors (agent-desc + agent-desc-sha256 in TXT).¶

• Publishers SHOULD keep endpoint migration agility by using shorter TTLs for SVCB than TXT.¶

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

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

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)"
          },
          "agentProtocols": {
            "type": "array",
            "items": {
              "type": "string"
            },
            "description": "Supported protocols (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",
      "agentProtocols": ["a2a", "anp"]
    },
    {
      "priority": 2,
      "target": "agent-v2.example.com",
      "port": 443,
      "alpn": ["h2"],
      "agentVersion": "v2",
      "agentProtocols": ["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)

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

8.3. Applicable Scenarios

• Clients that do not support SVCB queries¶

• Browsers / debugging tools¶

• Early ecosystem transition period¶

• Environments where DNS resolution is limited¶

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

9.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:
_agent.translator.example.com. IN SVCB 2 agent-v2.example.com. (
  alpn=h2 port=443 key65480="v2" key65481="a2a"
)
_agent.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)

9.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 agent-desc present: signing_input += ";agent-desc=" + agent-desc
if agent-desc-sha256 present: signing_input += ";agent-desc-sha256="
                            + agent-desc-sha256

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

10.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 (_agent.xxx) for signature metadata (alg/pk/sig), svcb-digest, and/or descriptor pointer fields¶

4. Configure DNS SVCB records with endpoint, protocol/version, and (SHOULD) address hints¶

5. (OPTIONAL) Publish descriptor URI + digest in TXT (agent-desc, agent-desc-sha256) for heavy metadata externalization¶

6. (RECOMMENDED) Publish /.well-known/agent-dns.json fallback file¶

7. (RECOMMENDED for public deployments) Enable DNSSEC¶

10.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, agent-desc, agent-desc-sha256)¶

4. If descriptor fields are present and required by local policy, fetch descriptor and verify digest before use¶

5. (Fallback) If SVCB unavailable, fetch agent-dns.json when needed¶

6. Connect to endpoint per agent protocol (key65481) specification¶

7. Validate DNSSEC when present, and fail closed for bogus SVCB/TXT results that are part of the selected trust path¶

10.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/descriptor metadata
_agent.translator.example.com. IN TXT "v=1;kid=key-2025-01;
                    alg=Ed25519;pk=...;sig=...;
                    svcb-digest=...;
                    agent-desc=https://translator.example.com/
                            .well-known/agent-descriptor.json;
                    agent-desc-sha256=x48E9qOokqqr7kbu9DBPE="

; Version resolution (SVCB)
_agent.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"
)
_agent.translator.example.com. IN SVCB 2 agent-v2.example.com. (
  alpn=h2 port=443 ipv4hint=203.0.113.51 key65480="v2" key65481="a2a"
)

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

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

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

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

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

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

13.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/>.