DNS-Native AI Agent Naming and Resolution

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

4.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. Query DNS SVCB records -> obtain version, endpoint, and protocol information¶

2. Query DNS TXT records -> obtain public key and verify identity¶

3. Connect to the TargetName:port specified in SVCB¶

4. Interact according to the protocol specification¶

5.1. TXT Record: Identity Trust Anchor

TXT records [RFC1035] serve as the sole trust anchor for agent identity and integrity. Their responsibilities are strictly limited to four functions:¶

1. Declare agent identity¶

2. Publish public key / fingerprint¶

3. Protect SVCB record integrity via digest (svcb-digest)¶

4. Sign identity and integrity metadata (tamper-proof)¶

_agent.translator.example.com. IN TXT (
  "v=1;"
  "kid=key-2025-01;"
  "alg=Ed25519;"
  "pk=base64-encoded-public-key;"
  "svcb-digest=base64-encoded-sha256-digest;"
  "sig=base64-encoded-signature"
)

5.2. 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
  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
  key65480="v2"
  key65481="a2a"
)

5.3. Version and Protocol Resolution

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

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

6.3. Applicable Scenarios

• Clients that do not support SVCB queries¶

• Browsers / debugging tools¶

• Early ecosystem transition period¶

• Environments where DNS resolution is limited¶

7.1. Security Model Overview

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

1. DNSSEC (RECOMMENDED): Protocol-level cryptographic authentication of DNS data¶

2. Signature-based Security (OPTIONAL but RECOMMENDED): Signing of TXT content, SVCB digest, and JSON fallback¶

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

<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)

7.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 + ";svcb-digest=" + svcb-digest

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

8.1. For Agent Publishers

1. Prepare domain name, configure HTTPS and TLS certificate¶

2. Configure DNS A/AAAA records (basic connectivity)¶

3. Configure DNS TXT record (_agent.xxx), publish public key¶

4. Configure DNS SVCB records, declare version and protocols¶

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

6. (RECOMMENDED) Enable DNSSEC¶

8.2. For Client Developers

1. Query SVCB records, parse version and endpoint information¶

2. Query TXT records, extract public key¶

3. (Fallback) If SVCB unavailable, fetch agent-dns.json¶

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

5. (RECOMMENDED) Validate DNSSEC¶

8.3. DNS Record Configuration Example

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

; Identity trust anchor (with SVCB integrity protection)
_agent.translator.example.com. IN TXT "v=1;kid=key-2025-01;
                    alg=Ed25519;pk=...;svcb-digest=...;sig=..."

; Version resolution (SVCB)
_agent.translator.example.com. IN SVCB 1 agent-v3.example.com. (
  alpn=h2 port=443 key65480="v3" key65481="a2a,anp"
)
_agent.translator.example.com. IN SVCB 2 agent-v2.example.com. (
  alpn=h2 port=443 key65480="v2" key65481="a2a"
)

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

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

• Clients MUST NOT use endpoints that fail verification¶

• Agents MUST synchronously update TXT and SVCB information when versions or endpoints change¶

9.3. DNSSEC Usage

• Agent operators SHOULD enable DNSSEC [RFC4033] 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¶

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

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

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