Agent Identity & Discovery (AID) — v1.2.0

Minimal, DNS-first agent bootstrap standard

Date: 6 February 2026 Editor: Agent Community Status: Final

---

Abstract

Agent Identity & Discovery (AID) answers one question: "Given a domain, where is the agent and which protocol should I speak?" It does so with a single DNS TXT record at a well-known subdomain: _agent.<domain>.

This protocol is an intentionally minimal discovery layer. After a client uses AID to find the correct endpoint or package, richer protocols such as the Model Context Protocol (MCP) or the Agent-to-Agent Protocol (A2A) take over for communication and capability negotiation.

This document defines the record format, a simple client algorithm, and strict security rules. It does not include manifests, capability lists, or runtime orchestration. AID defines a DNS discovery entry point for a specific protocol. It does not attempt to define a universal discovery framework for all agent systems.

---

0. Glossary

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 [RFC2119] and [RFC8174].

---

1. Design Goals

• Zero-Configuration: A user types a domain, and the client automatically discovers how to connect.
• Decentralized and Deployable: The standard uses DNS TXT records, which are universally supported and require no central registry.
• Protocol-Agnostic: AID discovers agents speaking any protocol, including MCP, A2A, OpenAPI, or even local package-based protocols.
• Clear Upgrade Path: A future AID version may adopt a more structured DNS record type, such as SRV or SVCB, while preserving the same _agent discovery label established in this specification.

---

2. TXT Record Specification

A provider MUST advertise its agent service by publishing a single DNS TXT record at _agent.<domain>.

2.1. Format

For AID v1.x, agents MUST use DNS TXT records for discovery. TXT was chosen because it is universally supported by every DNS registrar and provider, enabling any developer to deploy AID discovery without requiring specialized DNS infrastructure. Alternative record types such as SVCB ([RFC9460]) and SRV ([RFC2782]) offer more structured semantics but are not yet uniformly available across registrar control panels, limiting real-world deployability. Future AID versions may adopt alternative record types as provider support matures; the _agent label is designed to remain stable across such transitions (see Section 5).

The record MUST be a single string of semicolon-delimited key=value pairs. Clients SHOULD trim() leading and trailing whitespace from keys and values. Clients MUST ignore unknown keys. If a DNS server splits the record into multiple 255-octet strings, the client MUST concatenate them in order before parsing. Keep the total length under 255 bytes when possible.

Clients MUST recognize single-letter lowercase aliases for all keys. A record MUST NOT include both a full key and its alias. Key comparisons are case-insensitive.

Providers SHOULD emit the short-key form v,u,p,a,s,d,e,k,i for v1.x records. Long keys remain compatibility-only input for existing parsers and deployments.

2.2. Examples

Remote MCP Agent:

_agent.example.com. 300 IN TXT "v=aid1;u=https://api.example.com/mcp;p=mcp;a=pat;s=Example AI Tools"

Local Agent via Docker:

_agent.grafana.com. 300 IN TXT "v=aid1;u=docker:grafana/mcp:latest;p=local;a=pat;s=Run Grafana agent locally"

Remote MCP with PKA and metadata (v1.2):

_agent.example.com. 300 IN TXT "v=aid1;p=mcp;u=https://api.example.com/mcp;k=z7rW8rTq8o4mM6vVf7w1k3m4uQn9p2YxCAbcDeFgHiJ;i=g1;d=https://docs.example.com/agent;e=2026-01-01T00:00:00Z;s=Secure AI Gateway"

Local Zeroconf (v1.2):

_agent.local.test. 300 IN TXT "v=aid1;p=zeroconf;u=zeroconf:_mcp._tcp;s=Local Dev Agent"

2.3. Client Discovery Algorithm

An AID Client, when given a <domain>, MUST perform these steps:

1. Normalize domain. If the domain contains non-ASCII characters, convert it to its Punycode A-label representation ([RFC5890]).
2. DNS lookup. Query the TXT record for _agent.<exact-host-user-entered>. Clients MUST NOT implicitly retry parent hosts such as _agent.<parent-domain>. If no record is found or the lookup fails, the client MAY attempt a .well-known fallback on the same exact host (Appendix E). If both fail, stop with an error.
3. Parse and validate. Parse the returned TXT answers as semicolon-delimited key=value records. Key comparisons MUST be case-insensitive. Clients MUST recognize single-letter aliases for all keys. If exactly one valid AID record is present at the queried DNS name, use it. If more than one valid AID record is present at the same queried DNS name, clients MUST fail due to ambiguity rather than choosing by answer order. Malformed answers do not matter when there is exactly one valid AID record.
4. Optional metadata. If docs (d) is present, clients MAY display it. If dep (e) is in the future, clients SHOULD warn. If dep is in the past, clients SHOULD fail gracefully.
5. Endpoint proof. If pka (k) is present, clients MUST perform the handshake in Appendix D. Use HTTP Message Signatures (RFC 9421) with Ed25519. Clients SHOULD warn on downgrade if a previously present pka is removed.
6. Return result. If validation succeeds, return the discovered details. If the client does not support the discovered protocol token, it MUST fail with the appropriate error code.

Table 1: Standard Client Error Codes

Client implementations SHOULD use these codes to report specific failure modes. See Appendix C for numeric constants.

2.4. Exact-Host Semantics and Explicit Delegation

Discovery is exact-host by default. If the application asks for app.team.example.com, the canonical base query is _agent.app.team.example.com.

Clients MUST NOT walk up the DNS hierarchy looking for _agent.team.example.com or _agent.example.com.

If an operator wants child hosts to inherit a shared record, that inheritance MUST be expressed in DNS for the exact queried name. A common pattern is a CNAME from the child host's _agent label to a shared _agent record.

Examples:

_agent.app.team.example.com. 300 IN TXT "v=aid1;p=mcp;u=https://app.team.example.com/mcp"

_agent.app.team.example.com. 300 IN CNAME _agent.shared.team.example.com.
_agent.shared.team.example.com. 300 IN TXT "v=aid1;p=mcp;u=https://gateway.team.example.com/mcp"

Protocol-specific lookups follow the same exact-host rule. If a client explicitly requests mcp for app.team.example.com, it may query _agent._mcp.app.team.example.com before _agent.app.team.example.com, but it MUST NOT query parent hosts unless the operator has delegated the exact child name in DNS.

2.5. Exposing Multiple Protocols (Non-Normative Guidance)

The canonical location for discovery is the base record: _agent.<domain>. Providers MAY additionally expose distinct agent services (e.g., one for MCP and one for A2A) on protocol-specific subdomains using the underscore form _agent._<proto>.<domain>.

Examples:

_agent._mcp.example.com. 300 IN TXT "v=aid1;p=mcp;u=..."
_agent._a2a.example.com. 300 IN TXT "v=aid1;p=a2a;u=..."

Client behavior:

• By default, clients query the base _agent.<exact-host>.
• When a specific protocol is explicitly requested (by the application), clients MAY first query the protocol-specific subdomain _agent._<proto>.<exact-host> and, if not found, fall back to the base record for that same exact host.
• Providers that publish only the base record remain fully compliant.

---

3. Security Rules

• DNSSEC: Providers SHOULD sign their DNS records with DNSSEC. Clients SHOULD perform DNSSEC validation when DNSSEC-signed answers are available.
• HTTPS: A remote agent's uri MUST use https://. Clients MUST perform standard TLS certificate and hostname validation.
• No Secrets: The TXT record is public and MUST NOT contain any secrets.
• Endpoint Proof (PKA): When the record includes pka/k, clients MUST verify server control of the private key using HTTP Message Signatures (RFC 9421) with Ed25519 (Appendix D). Providers MUST publish kid/i when pka is present. Clients SHOULD warn on downgrade if a domain removes pka after prior discovery.
• Local Execution (proto=local) Safeguards: Clients that support local execution MUST implement the following:
  1. Explicit Consent: Before the first execution, the client MUST display the full, resolved command to the user and require explicit confirmation.
  2. Integrity Check: The client MUST compute and cache a cryptographic fingerprint of the uri and proto values. If these values change on a subsequent lookup, the client MUST re-trigger the full consent process.
  3. No Shell Interpretation: Arguments derived from the uri MUST be passed atomically to the underlying OS execution call to prevent command injection.
  4. No Nested Discovery: Clients MUST reject a local execution uri that could be interpreted as a command initiating another AID discovery request.
  5. Sandboxing: Clients SHOULD run local agents within a sandboxed environment with minimum necessary permissions.
• Redirect Handling: If an initial request to the discovered uri returns an HTTP redirect (301, 302, 307, or 308) to a different origin (hostname or port), the client SHOULD treat this as a potential security risk. Clients MUST NOT follow such cross-origin redirects automatically. Implementations MAY either
  a. terminate with ERR_SECURITY, or
  b. require explicit user confirmation before proceeding.

3.1 Threat Model

AID's security model addresses the following threat landscape:

Assumptions:

• DNS resolvers are trusted for transport. DNSSEC is recommended but not required, preserving deployability across all registrars.
• HTTPS endpoints are verified via standard TLS certificate validation ([RFC6125]).
• The TXT record is public data. No secrets are transmitted via DNS.

Mitigations provided:

• DNS spoofing/cache poisoning: DNSSEC validation (when available) provides cryptographic proof of record authenticity. Enterprise deployments can mandate DNSSEC via policy modes (Section 3.2).
• Endpoint impersonation: PKA (Appendix D) provides endpoint proof using Ed25519 HTTP Message Signatures ([RFC9421]). AID's Ed25519 key material is also compatible with other external key-distribution systems, though AID v1.2 does not depend on or require them.
• Downgrade attacks: Clients track previously seen PKA keys and detect removal or rotation (configurable via policy).
• Command injection (local agents): Local execution safeguards (explicit consent, integrity checks, no shell interpretation) prevent exploitation of proto=local records.
• Cross-origin redirect: Clients reject or flag cross-origin HTTP redirects from discovered endpoints.

Explicitly out of scope:

• Compromised authoritative DNS servers (DNSSEC is the mitigation; AID does not replace it)
• Active network attackers between client and HTTPS endpoint (TLS provides this defense)
• Revocation of compromised PKA keys beyond DNS record update (future work; see Section 5)

3.2 Enterprise Policy Modes

Clients that expose enterprise controls SHOULD provide a preset mode surface and MAY also expose the underlying policy knobs directly.

The normative preset names for v1.2.x are:

• balanced
  • pka: if-present
  • dnssec: prefer
  • well-known: auto
  • downgrade: warn
• strict
  • pka: require
  • dnssec: require
  • well-known: disable
  • downgrade: fail

The underlying policy knobs are:

• PKA policy: if-present | require
• DNSSEC policy: off | prefer | require
• Well-known policy: auto | disable
• Downgrade policy: off | warn | fail

Policy semantics:

• PKA require: discovery MUST fail with ERR_SECURITY if the selected record does not publish pka and kid.
• DNSSEC prefer: clients SHOULD continue when DNSSEC cannot be validated, but SHOULD surface a warning.
• DNSSEC require: clients MUST fail with ERR_SECURITY when DNSSEC validation is unavailable or unsuccessful for the selected DNS answer.
• Well-known disable: clients MUST NOT use /.well-known/agent fallback.
• Downgrade warn: if a previously seen pka disappears or pka/kid changes, clients SHOULD surface a warning.
• Downgrade fail: if a previously seen pka disappears or pka/kid changes, clients MUST fail with ERR_SECURITY.

If discovery succeeds only through .well-known, that result cannot satisfy dnssec=require.

Operational rollout guidance for these modes lives in the Enterprise Rollout Playbook.

---

4. DNS and Caching

• Provider TTL: It is RECOMMENDED that providers set a Time-To-Live (TTL) of 300–900 seconds (5–15 minutes) on their _agent.<domain> TXT record.
• Client Caching: Clients MUST respect the TTL of the DNS record they receive and MUST NOT cache the record for longer.

---

5. Future Path

• Record Type Evolution: AID v2 may adopt a more structured DNS record type such as SRV ([RFC2782]) or SVCB ([RFC9460]) for discovery, depending on registrar support at the time of ratification. Until then, TXT lookup remains the canonical method for v1.x.
• IANA Registration: Formal requests will be submitted for the _agent underscored DNS node name under [RFC8552] and the agent service name under [RFC6335].

5.1 Label Stability

The _agent DNS label is the stable discovery identifier for AID across all protocol versions. If AID evolves from v1 (TXT) to v2 (SRV, SVCB, or another record type), the _agent label remains the stable identifier. Clients use the version field (v=aid1) to determine record format. This ensures that IANA registration of _agent provides long-term stability for operators regardless of future record type transitions.

---

6. Registries and Governance

To ensure interoperability, token registries and community resources are maintained publicly.

• Token Registries: The canonical lists for auth and proto tokens are defined in Appendix A and Appendix B of this specification and maintained as machine-readable constants in the specification repository. Additions require a pull request against the specification repository following the spec extension process and are governed by a "First Come, First Served" policy with expert review.
• Global Index: An open index of AID records discovered across the internet is planned at: https://github.com/agentcommunity/aid-registry AID is decentralized by design; this index is an observational catalog, not a requirement for discovery. The crawler is not yet operational.

---

7. IANA Considerations

This specification requests registration in two IANA registries. The two registrations serve different purposes: the RFC 8552 registration covers AID v1.x TXT-based discovery at _agent.<domain>, while the RFC 6335 service name supports potential future SRV-based discovery at _agent._tcp.<domain>.

7.1. Underscored and Globally Scoped DNS Node Names (RFC 8552)

The _agent global underscored node name is used exclusively for Agent Identity & Discovery (AID) service discovery. A single TXT record published at _agent.<domain> contains semicolon-delimited key=value pairs specifying an agent service endpoint, protocol type, and optional metadata as defined in Section 2 of this specification.

The _agent node name is specific to the AID protocol and does not reserve the broader concept of software agents or agent-related discovery generally.

Protocol-specific labels of the form _agent._<proto>.<domain> (e.g., _agent._mcp.<domain>) are scoped beneath the globally registered _agent node and do not require separate global registration.

7.2. Service Name and Transport Protocol Port Number Registry (RFC 6335)

---

Appendix A: Authentication Scheme Registry (auth)

All scheme tokens are case-sensitive and defined in lowercase ASCII.

• none
• pat (Personal Access Token)
• apikey
• basic (HTTP Basic Authentication)
• oauth2_device
• oauth2_code
• mtls
• custom

Appendix B: Protocol Registry (proto / p)

All protocol tokens are case-sensitive and defined in lowercase ASCII.

Appendix C: Client Error Constants

For cross-language SDK consistency, clients SHOULD use these numeric constants when throwing errors.

Appendix D: PKA Handshake (Normative)

When pka/k is present, clients MUST verify control of the private key. Use HTTP Message Signatures (RFC 9421) with Ed25519.

Pseudocode (client):

function performPKAHandshake(uri, pka, kid):
    nonce = generateRandomBytes(32)
    challenge = base64urlEncode(nonce)
    headers = {
        "AID-Challenge": challenge,
        "Date": currentUTCTime()
    }
    response = sendGET(uri, headers)

    if response.status != 200:
        failWith(ERR_SECURITY)

    sigInput = response.headers["Signature-Input"]
    signature = response.headers["Signature"]

    created = parseCreated(sigInput)
    if |currentTime() - created| > 300 seconds:
        failWith(ERR_SECURITY)

    pubKey = multibaseDecode(pka)
    if not verifyEd25519(signature, sigInput.coveredFields, pubKey):
        failWith(ERR_SECURITY)

Providers MUST include kid/i with pka/k. Clients SHOULD warn on downgrade if a previously present pka is removed.

Appendix E: .well-known Fallback (Non-Normative)

AID is a DNS-based discovery protocol. The .well-known fallback described here is a non-normative convenience for environments where DNS TXT record creation is restricted (e.g., certain managed hosting platforms). It does not affect the _agent DNS registration or its scope under RFC 8552.

• Path: GET https://<domain>/.well-known/agent
• Format: JSON that mirrors TXT keys, including aliases.
• Security: Relies on TLS certificate validation. PKA still applies when present.
• Client algorithm: Use DNS first. Fallback only on ERR_NO_RECORD or ERR_DNS_LOOKUP_FAILED.
• Errors: Use ERR_FALLBACK_FAILED when the fallback fails or is invalid.

References

• [RFC1035] Domain Names - Implementation and Specification
• [RFC2119] Key words for use in RFCs to Indicate Requirement Levels
• [RFC2782] A DNS RR for specifying the location of services (DNS SRV)
• [RFC5890] Internationalized Domain Names for Applications (IDNA)
• [RFC6125] Representation and Verification of Domain-Based Application Service Identity (TLS)
• [RFC6335] Service Name and Transport Protocol Port Number Registry
• [RFC8174] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
• [RFC8552] Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves
• [RFC9421] HTTP Message Signatures
• [RFC9460] Service Binding and Parameter Specification (SVCB/HTTPS)

---

Next Steps:

• Quick Start Guide
• aid-doctor CLI Reference – Official implementation and validation tool