]> Infoblox, Inc.

jmozley@infoblox.com

Infoblox, Inc.

nic@infoblox.com

Unaffiliated

sarikaya@ieee.org

Deutsche Telecom

roland.schott@telekom.de

ops dnsop DNS AI Service Discovery agent-to-agent The emerging field of agent-to-agent protocol standards introduces new requirements in order to facilitate discovery, trust signaling, session negotiation and communication. This document specifies a method for utilizing the Domain Name System (DNS) to facilitate scalable and interoperable discovery between AI agents. The proposed mechanism, referred to as Brokered Agent Network for DNS AI Discovery (BANDAID), defines a structured DNS namespace and record usage model to support metadata exchange and capability advertisement. BANDAID introduces a leaf zone convention (e.g., _agents.example.com) containing Service Binding (SVCB) records (e.g., chat._agents.example.com) that encode application-specific metadata. These records enable agents to retrieve operational parameters prior to initiating a session, supporting both targeted lookups and capability-based discovery. The approach leverages existing DNS infrastructure, including DNS Service Discovery (DNS-SD), DNSSEC, and DANE, to provide integrity, authenticity, and automation without requiring human intervention. Lastly, the draft for Domain Control Validation (DCV) proposes a best current practice to prove an agent is authorized to act on behalf of a domain. This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the WG Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

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.

Introduction Agent-to-agent communication introduces novel requirements for service discovery, authorization signaling, and metadata exchange. While several proposals have explored new discovery protocols, the DNS remains the most widely deployed and interoperable mechanism for service discovery, with decades of operational maturity. Existing DNS record types (including SRV, NAPTR, SVCB, TXT, and A/AAAA) are routinely used to locate services and convey configuration metadata. It is therefore reasonable to assume that AI agents will interact with this network protocol during discovery, session initiation, and their application exchange. If a user at $company asks their agent "clean up my Salesforce data based on this email," how does $company agent then know where to find Salesforce's agents? How would the Salesforce agent validate the $company agent and make the correct requested changes to Salesforce data? The former question is a DNS-solvable problem, the latter is not in the scope of this draft. DNS can convey authorization and intent: DNS provides an organization a way to indicate that an agent is authorized to act on behalf of a domain (DCV draft), publish allowed endpoints or capabilities (SVCB), advertise service metadata in a way that’s cacheable, verifiable, and language-agnostic (tree domain etc), all while creating tamper-proof records and binding identities to certificates (DNSSEC + DANE). Additionally, DNS contributes to agent security by enabling connections to trusted nameservers, mitigating risks from typosquatted or malicious domains, and enforcing geographic or jurisdictional boundaries through country-code top-level domains (ccTLDs) and regionally scoped authoritative servers. These features collectively support secure, policy-compliant agent interactions at scale. Unlike proposals that rely on centralized registries or ungoverned discovery networks, BANDAID builds upon existing infrastructure and governance models. It preserves operator sovereignty, supports decentralized publication, and benefits from support in the form of legal dispute processes and vulnerability disclosure programs. This document aims to address key concerns in governance, commerce, security, and performance, allowing agent protocol designers to focus on data exchange standards while relying on the DNS for discovery. Agent-to-agent communication would take place after initial discovery, but some key data can be put into the DNS as a shortcut to make it more efficient. The problem statement addressed by this draft is and also relevant is although this draft is related to the discovery of agents rather than protocols used directly in agent-to-agent communication.

Challenges with Existing Proposed Mechanisms and Benefits of DNS Several alternative approaches to agent discovery have been proposed, including centralized registries, blockchain-based naming systems, and proprietary service directories. While these models may offer novel features, they introduce significant architectural, operational, and governance challenges. Centralized registries concentrate control and introduce single points of failure, limiting resilience and scalability. Blockchain-based systems often lack integration with existing internet infrastructure, suffer from latency and cost constraints, and present jurisdictional ambiguity due to decentralized governance. Proprietary directories fragment the discovery ecosystem and inhibit interoperability across agent frameworks and administrative domains. Furthermore, securely delegating authority to AI solution providers on behalf of your organization requires interfacing between this central authority as opposed to business-to-business.

Development The DNS benefits from decades of global development and operational deployment. It is supported by mature ecosystems for vulnerability disclosure, patch management, and protocol evolution, with active participation from security researchers, vendors, and operators worldwide. This distributed development model ensures that no single entity maintains disproportionate control over the protocol’s trajectory or security posture. DNS infrastructure is also tightly integrated with existing cybersecurity practices. Connections to trusted nameservers, protections against typosquatted or malicious domains, and support for jurisdictional scoping via country-code top-level domains (ccTLDs) contribute to a robust security baseline. These features are particularly relevant in agent-to-agent contexts, where automated systems make trust decisions without human oversight... and importantly, may be maliciously modified without human awareness. In contrast, the introduction of a novel discovery protocol would require the establishment of new governance structures, security models, and operational tooling. Early implementations would likely be centralized among a limited set of stakeholders, introducing bottlenecks in protocol evolution and risk mitigation. Building a comparable ecosystem would require sustained investment, cross-organizational coordination, and long-term trust-building—resources that DNS already possesses.

Opportunity Cost Introducing a new protocol for agent-to-agent discovery imposes nontrivial infrastructure and operational requirements. In particular, organizations may be required to deploy and maintain additional components such as specialized cache servers or registry interfaces, which increases complexity and operational overhead. Some proposals suggest a generic top level domain (gTLD) like .aiagent, which is more cost to advertise as domains are purchased by early opportunists. These requirements may present barriers to adoption, especially for small or resource-constrained entities, and risk reinforcing disparities in access to AI technologies. DNS, by contrast, is already deeply integrated into global infrastructure and supported by mature tooling, operational expertise, and deployment models. Its use for agent discovery enables rapid adoption without introducing new layers of technical debt. Leveraging DNS allows organizations to participate in agent-to-agent ecosystems using existing infrastructure, reducing onboarding friction and accelerating innovation. This approach supports incremental deployment and minimizes opportunity cost by avoiding the need for parallel protocol development and infrastructure investment.

Governance The DNS operates within a well-established and internationally recognized governance framework. Oversight is provided by entities such as the Internet Assigned Numbers Authority (IANA), top-level domain (TLD) operators, and national network information centers (NICs). These organizations maintain accountability mechanisms and support dispute resolution processes, including domain takedowns, mitigation of impersonation, and remediation of malicious behavior. The governance structures surrounding DNS have evolved over decades and are supported by legal, technical, and operational norms that facilitate cross-jurisdictional trust and stability. DNS also enables policy enforcement at the infrastructure level. For example, country-code top-level domains (ccTLDs) and regionally scoped authoritative servers allow for jurisdictional boundaries to be respected, which may be relevant in agent deployments subject to regulatory constraints. Additionally, DNSSEC and DANE provide cryptographic assurances that bind domain identities to certificates, supporting automated trust decisions without requiring centralized registries or manual validation. In contrast, alternative discovery proposals—such as blockchain-based registries or neutral third-party systems—lack formal integration with existing governance bodies and may be susceptible to fragmentation, influence, or jurisdictional ambiguity. These models do not currently offer the same level of operational recourse or reliability. Leveraging DNS for agent discovery allows organizations to build on trusted infrastructure while maintaining compatibility with existing governance frameworks, providing a stable foundation for innovation as more experimental models mature. Establishing a new governance structure based on new agent discovery protocols would be time consuming, involve all stakeholders agreeing on the structure, establishing the structure in a specific jurisdiction (which may not be suitable for all parties), and involve creating the technical infrastructure to support it. The DNS already has all of these components in place.

Sovereignty The DNS supports decentralized control while maintaining global interoperability. Organizations may operate their own authoritative DNS infrastructure, publish service records independently, and retain full control over how their services are discovered. This model enables entities to maintain autonomy over their service exposure and operational boundaries without reliance on centralized intermediaries which may not share their same interests. Proposed alternatives—such as blockchain-based registries, single-purpose generic top-level domains (gTLDs), or third-party discovery networks—often introduce opaque governance models, unclear trust boundaries, and dependencies on external infrastructure. Although these systems may be described as “decentralized,” they frequently concentrate control within protocol maintainers, validator networks, or registry operators, which may not be accountable to the organizations they serve. DNS provides a proven and extensible registry model that supports secure, independent publication of agent metadata. It aligns with principles of digital sovereignty and operational self-determination, allowing organizations to participate in agent ecosystems without relinquishing control over discovery infrastructure.

Commerce A critical consideration in the design of agent discovery infrastructure is the potential for commercialization to compromise integrity. In the absence of established norms or constraints, new registry-based discovery mechanisms may evolve into visibility-driven platforms, where agent discoverability is influenced by paid placement rather than technical merit, trust, or reputation. This introduces incentives that prioritize commercial interests over operational reliability and security, undermining the predictability and neutrality of agent interactions and the free and open Internet as a whole. DNS, by contrast, is built on open standards and governed by transparent, non-commercial processes. It provides mechanisms for validation and authentication, such as DNSSEC, and certificate bindings via DANE that are not subject to monetization. The resolution process is deterministic and not influenced by financial incentives, preserving the integrity of service discovery. Leveraging DNS ensures that agent discovery remains a technical function grounded in verifiable identity and operational metadata, rather than a commercial battleground. This supports fair access and trustworthy interactions across heterogeneous agent ecosystems.

Application Regardless of how agent discovery is initiated, agent-to-agent communication ultimately intersects with existing network infrastructure. Agents may require access to internal services, external APIs, or shared data repositories, all of which are typically addressed through conventional networking and resolution mechanisms. Introducing a separate discovery protocol that fragments the location and representation of service metadata introduces architectural complexity and increases the risk of cascading failures across systems. Operators would be required to manage multiple layers of resolution logic, synchronization mechanisms, and failure domains, which complicates deployment and undermines operational reliability. DNS, by contrast, is already embedded in the fabric of networked applications and provides a natural point of integration for discovery. It enables metadata publication to remain proximate to the services it describes, reducing latency, simplifying architecture, and aligning with existing operational models. This approach supports innovation in agent systems while avoiding brittle dependencies and minimizing architectural drift. DNS is predictable for agents to use for the purposes of discovery, requiring no advanced configurations to consume the service, rather it is embedded in all pieces of the application stack eliminating the need to retrofit legacy devices to operate in an agent-to-agent environment.

Granularity DNS supports fine-grained control over service discovery through its hierarchical zone structure and flexible record types. Organizations may define zones and records at varying levels of specificity, including per-host, per-service, per-environment (e.g., staging vs. production), or per geographic region. This granularity enables precise targeting and segmentation of agent capabilities, facilitating operational clarity and policy enforcement. Service Binding (SVCB) records further enhance granularity by allowing metadata to be associated with individual service endpoints. This includes transport preferences, supported protocols, and application-specific parameters. Combined with DNS Service Discovery (DNS-SD), these features allow agents to discover services with high specificity, reducing ambiguity and improving interoperability. The DNS model supports modular deployment and incremental adoption, making it well-suited for diverse agent architectures and operational contexts.

Performance DNS is well-suited to meet the scale and responsiveness requirements of agent discovery, where billions of agents may generate trillions of queries. Its architecture supports high-throughput, low-latency resolution through mechanisms such as caching, retry logic, and autom,atic zone distribution to secondary servers. Recursive resolvers may be further optimized by locally hosting the root zone , reducing lookup latency and improving fault tolerance. Additional features such as pre-fetching and negative caching allow resolvers to anticipate agent behavior and reduce query overhead. Country code (ccTLD) and Generic Top Level Domain (gTLD) operators have global infrastructure to support localized resolution and improve performance for AI-specific applications. These capabilities enable scalable deployment without requiring protocol redesign or new infrastructure layers. Furthermore, DNS-based discovery enables immediate connection establishment. Once an agent endpoint is resolved, transport protocols such as QUIC may be used to initiate communication directly, benefiting from features such as 0-RTT and multiplexed streams. This eliminates the need for a separate handshake or negotiation phase for discovery, reducing latency and improving throughput in high-volume environments. DNS thus provides a performant and extensible foundation for agent discovery at global scale.

Lifecycle / Management DNS provides robust provisioning and lifecycle management capabilities that align with the dynamic nature of agent-based systems. Mechanisms such as Incremental Zone Transfer (IXFR) and Full Zone Transfer (AXFR) allow for rapid propagation of zone updates across authoritative servers. When backed by database-centric DNS implementations, zone data may be treated as replicable state, enabling near-real-time onboarding or decommissioning of agents. Operational observability is supported through query logging, zone monitoring, and resolver telemetry, which can be used to track agent utilization patterns and identify stale or inactive records. These lifecycle management capabilities are mature, widely supported, and compatible with existing operational tooling. They enable high-churn agent ecosystems to be managed efficiently without requiring the development of new provisioning, monitoring, or cleanup protocols.

Trust In agent discovery, trust encompasses more than identity verification — it includes confidence in the provenance, behavior, and reliability of the agents being discovered. The DNS provides a recognizable and auditable namespace rooted in organizational domains (e.g., microsoft.com, openai.com), enabling systems to make informed decisions about agent interactions based on domain ownership and established reputational context. This is particularly critical in AI environments, where agents may initiate autonomous actions or access sensitive data. DNS enables organizations to publish agent endpoints under domains they control, establishing a clear chain of accountability. This trust model supports cryptographic validation through DNSSEC and DANE, allowing agents to verify domain ownership and certificate bindings without manual intervention. By contrast, discovery mechanisms lacking verifiable lineage introduce significant risk and complexity, particularly when agents are discovered through opaque or ungoverned registries. The BANDAID model builds on the DNS’s trust infrastructure to support safe and scalable agent discovery. It allows agents to assess the authenticity and authority of remote endpoints prior to interaction, reducing the likelihood of misrouting, impersonation, or unauthorized access. This trust-validation-first approach is foundational to enabling secure automation in agent ecosystems.

Agent Properties As agent-to-agent protocols evolve, it is likely more metadata will need to be signaled in the discovery phase to allow agents to make more informed decisions. An example of how DNS provides a platform to facilitate this is below. Service Binding (SVCB) records, as defined in , support extensible key-value parameters that may be registered through the IANA SVCB Parameter Registry. These parameters can provide agent systems with operational context prior to session initiation, enabling informed decisions about whether and how to engage with a remote agent. It is possible to publish metadata such as input (e.g. expected token counts) or cost (e.g. cost per token bundle) directly within DNS records. This model supports a trust-validation-first approach to agent interaction, where expectations around resource usage and pricing are transparently advertised. It reduces the need for handshake-based negotiation or out-of-band signaling, and allows for deterministic, cacheable discovery workflows. For instance, by embedding cost-related metadata in DNS, discovery becomes not only scalable and performant, but also semantically rich, supporting economically-aware agent ecosystems without introducing new protocols or registries.

Control Agent discovery mechanisms must operate within the constraints of enterprise security policies, regulatory compliance requirements, and operational boundaries. DNS enables the presentation of distinct DNS views based on the source of the query. This allows organizations to expose different sets of agent records to internal versus external resolvers. For example, internal agents may resolve _a2a._agents.internal.example.com to discover services not intended for public exposure, while external agents receive responses only for _a2a._agents.example.com containing externally authorized endpoints. Enterprise-grade network controls such as firewalls, Response Policy Zones (RPZs), and access control lists (ACLs) provide additional enforcement mechanisms. These controls may restrict outbound DNS queries to designated resolvers, filter inbound queries to approved zones, and block unauthorized resolution attempts. This ensures that agent discovery adheres to organizational boundaries and complies with internal security policies. For example, an enterprise may configure its network security to allow internal agents to query only *.internal.example.com zones, while blocking access to external agent zones unless explicitly permitted. Similarly, DNS servers may enforce query logging and rate limiting to detect anomalous behavior or potential abuse. Segmented discovery via DNS aligns with compliance requirements related to data residency, privacy, and access control. By scoping agent visibility to specific zones and enforcing resolution boundaries, organizations can ensure that discovery mechanisms respect jurisdictional constraints, internal governance models, and support auditability. Query logs, zone access telemetry, and resolver behavior can be monitored to verify that agent interactions conform to policy. This provides a foundation for regulatory reporting, incident response, and continuous compliance validation without the need for extensive additional operations that require more technical staffing or specialized solutions.

Mechanisms for Successful Agent Communication The explicit goal of the DNS is to provide a mechanism for name resolution, enabling agent discovery without requiring new protocols, trust anchors, or infrastructure layers. Leveraging DNS for agent discovery ensures compatibility with existing operational models, supports incremental deployment, and avoids the risks associated with experimental or ungoverned discovery mechanisms.

Service Binding Records, aka SVCB The SVCB resource record as defined in , enables DNS to convey structured service metadata that facilitates optimized connection establishment. SVCB records support the advertisement of protocol identifiers (via ALPN), transport parameters (e.g., port numbers), endpoint hints (e.g., IP addresses), and extensible key-value attributes. These capabilities are particularly relevant for agent-to-agent communication, where protocol negotiation and metadata exchange must occur without human intervention. In the context of BANDAID, SVCB records are used to publish agent-specific service endpoints under structured leaf zones (e.g., _chat._agents.example.com). These records allow querying agents to retrieve operational parameters prior to initiating a session, including supported protocols, privacy features (e.g., Encrypted Client Hello via ECH), and failover configurations. This eliminates the need for heuristic-based connection attempts and reduces round-trip latency. SVCB records also support protocol agility and privacy-preserving features. For example, agents may advertise support for QUIC, HTTP/3, or custom agent-to-agent protocols via ALPN declarations. Operators may specify alternate endpoints or migrate services across domains without relying on CNAME indirection, improving performance and reducing DNS resolution complexity. When paired with attribute leaf zones and custom SVCB parameters, this mechanism enables fine-grained discovery of agent capabilities. For instance, an agent querying _a2a._agents.example.com may receive an SVCB record indicating supported modalities (e.g., chat, image-to-text), expected input formats, and cost-related metadata (e.g., token pricing). This structured discovery model supports deterministic, cacheable, and semantically rich interactions between agents.

DNS Security Extensions, aka DNSSEC DNSSEC as defined in , , and , enables resolvers and clients to verify that a response originates from an authoritative source (authenticity) and DNS data has not been modified in transit (data integrity). In the context of BANDAID, DNSSEC serves as a foundational trust mechanism for agent discovery. By signing agent-related resource records—such as SVCB, TXT, or custom metadata—organizations can ensure that querying agents receive authentic and tamper-proof information. This is particularly critical for agent-to-agent communication, where autonomous systems must make trust decisions without human oversight. DNSSEC supports the establishment of cryptographic trust anchors via Delegation Signer (DS) records and facilitates secure delegation of authority across zone boundaries. This allows organizations to publish agent metadata under subdomains (e.g., _a2a._agents.example.com) while maintaining verifiable control over the zone hierarchy. Furthermore, DNSSEC eliminates the need for hardcoded trust lists or centralized validation services. Agents can validate responses using the DNSSEC chain of trust, enabling decentralized and scalable trust verification. This model supports zero-trust architectures and aligns with modern security principles by minimizing implicit trust and enforcing explicit validation. When combined with DANE (DNS-Based Authentication of Named Entities), DNSSEC enables binding of TLS certificates to DNS names, further enhancing the authenticity of agent endpoints. This integration supports secure session initiation and mitigates risks associated with certificate mis-issuance or man-in-the-middle attacks. The use of DANE may improve performance and enable automation in the dynamicism of agent lifecycle.

DNS Service Discovery, aka DNS-SD DNS-SD as defined in , extends the capabilities of the Domain Name System to support service-type-based discovery. Unlike traditional DNS resolution, which requires prior knowledge of a specific hostname, DNS-SD enables clients to discover services based on their functional type (e.g., _http._tcp, _printer._udp) within a given domain. In the context of BANDAID, DNS-SD provides a mechanism for AI agents to discover other agents or services based on declared capabilities rather than explicit names. For example, an agent may issue a query for _data-cleaner._a2a._agents.example.com to locate services capable of performing data sanitization tasks. This type-based discovery model supports dynamic ecosystems where agent roles and capabilities may evolve over time. DNS-SD operates over both multicast DNS (mDNS) and unicast DNS, allowing for flexible deployment in local networks and globally scoped domains. In enterprise or cloud environments, unicast DNS-SD enables structured and policy-compliant discovery across organizational boundaries. When combined with SVCB records, DNS-SD allows agents to retrieve detailed service metadata, including transport preferences, protocol support, and operational parameters. This model supports federated agent architectures, where multiple agents may advertise similar capabilities under different domains. By leveraging DNS-SD, agents can perform capability-based queries and receive a list of candidate services, each accompanied by structured metadata for evaluation and selection. DNS-SD also supports extensibility through TXT records and custom service naming conventions, enabling organizations to encode additional attributes relevant to agent interaction (e.g., supported data formats, authentication requirements, or cost models). These features make DNS-SD a suitable foundation for scalable, interoperable, and semantically rich agent discovery workflows.

DNS-Based Authentication of Named Entities, aka DANE DANE as specified in and , enables domain owners to associate Transport Layer Security (TLS) certificates with DNS names using TLSA resource records. When protected by DNSSEC, these records provide cryptographically verifiable bindings between domain names and public keys, allowing clients to authenticate services without relying solely on external certificate authorities (CAs). In the context of BANDAID, DANE enhances the trust model for agent-to-agent communication by enabling agents to validate the authenticity of remote endpoints based on domain-controlled assertions. This is particularly relevant in automated environments where agents must establish secure sessions without manual certificate validation or user interaction. By publishing TLSA records under agent-specific service names (e.g., _a2a._tcp.agent.example.com), organizations can declare the expected certificate fingerprint or public key for a given agent endpoint. Querying agents can then validate the TLS connection against the DANE record, ensuring that the certificate presented during session initiation matches the domain’s published intent. This mechanism mitigates risks associated with certificate mis-issuance, man-in-the-middle attacks, and reliance on third-party trust anchors. It also supports deterministic validation workflows, which are critical for agents operating in headless or GUI-less environments where interactive certificate warnings cannot be resolved. When combined with DNSSEC, DANE provides a robust, decentralized, and verifiable trust infrastructure for agent discovery and communication. It aligns with zero-trust principles by enabling domain owners to assert and control trust relationships directly through DNS, without introducing additional registries or validation services.

Domain Control Validation, aka DCV DCV refers to the process by which an entity demonstrates authoritative control over a DNS domain. As described in draft-ietf-dnsop-domain-verification-techniques, DNS-based DCV typically involves the placement of a DNS record—most commonly a TXT record—containing a challenge token or assertion at a designated location within the domain. This record is then queried by an Application Service Provider (ASP) to confirm control. In the context of BANDAID, DCV provides a mechanism for agents to assert delegated authority on behalf of a domain. For example, an organization may publish a TXT record under a structured leaf zone (e.g., _agent-roles._a2a._agents.example.com) containing metadata such as:

• ai-role=data-cleaner; crm=salesforce; access=readonly

This record signals that a specific agent is authorized to perform scoped operations under the domain's authority. When protected by DNSSEC, such assertions become cryptographically verifiable, mitigating risks of spoofing or unauthorized delegation. DCV within BANDAID supports both ephemeral and persistent validation models. Ephemeral validation may be used for short-lived agent credentials or session-based delegation, while persistent records enable long-term authorization signaling. TTL and expiration considerations, as discussed in the draft, are critical to ensuring that validation records do not persist beyond their intended scope. Furthermore, BANDAID encourages the use of application-specific naming conventions and token formats to avoid service confusion and collision. Validation records should be scoped to the intended service and include unguessable tokens or structured metadata to prevent unauthorized reuse across federated agent ecosystems.

Service Resilience The DNS architecture is inherently resilient due to its distributed, hierarchical design. Authoritative zones are replicated across multiple servers, and recursive resolvers implement caching, retry logic, and failover mechanisms to ensure continuity of resolution. Failover, anycast, and replication continue to add resiliency and redundancy provided through the DNS. This fault-tolerant model supports agent discovery even in the presence of partial network outages, denial-of-service conditions, or upstream failures. Unlike centralized registries or proprietary APIs, DNS does not rely on a single point of availability, making it suitable for high-availability agent ecosystems operating across diverse network environments.

Observability, Auditability DNS provides built-in observability through query logging, resolver telemetry, and zone monitoring. These features enable operators to track agent discovery patterns, detect anomalous behavior, and perform forensic analysis of agent interactions. This auditability is critical in regulated environments where agent actions must be attributable and verifiable, and where discovery mechanisms must align with enterprise governance models. Logs may be used to validate compliance with access policies, identify stale or misconfigured records, support incident response workflows, and/or be used in lifecycle management of unused or oversubscribed agents.

Interoperability BANDAID is designed to be agnostic to agent implementation frameworks. Whether agents are built using open-source libraries, proprietary orchestration platforms, or custom runtimes, DNS-based discovery provides a common substrate for metadata publication and retrieval. This interoperability ensures that agents operating under different protocols, vendors, or administrative domains can participate in shared discovery workflows without requiring protocol translation or framework-specific integration. DNS’s ubiquity across operating systems and network stacks further reinforces its suitability as a universal discovery layer.

Multitenancy, Federation DNS’s hierarchical namespace supports multi-tenant and federated discovery models. Organizations may delegate subdomains to tenants (e.g., customer1._agents.vendor.com) or publish agent metadata under federated zones (e.g., region1._a2a.example.org). This enables scoped discovery, policy enforcement, and operational isolation across tenants, departments, or geographic regions. Combined with DNSSEC and access controls, this model supports secure delegation and trust signaling in complex agent ecosystems, including SaaS platforms and cross-organizational collaborations.

Architecture

Example Communication Agent (org1) wants to find other agents provided by another entity (org2) and discover/verify capabilities DNS SVCB Query ┌────────┐ _a2a._agents.example.com ┌────────┐ ┌────────┐ │AI Agent├─────────────────────────────►│Resolver├───────────►│Auth DNS│ │ (ORG1) │ ◄────────────────────────────┤ (ORG1) │◄─────┬─────┤ (ORG2) │ └────────┘ └────────┘ │ └────────┘ │ ┌─────────────────────────────────────────────────┴─────────────┐ │_a2a._aiagent.org2.com. 3600 IN SVCB 1 ai-index-svc.org2.com. (│ │ alpn="a2a" │ │ port=443 │ │ ipv4hint=192.0.2.1 │ │ ipv6hint=2001:db8::1 │ │) │ └───────────────────────────────────────────────────────────────┘

Example Record _a2a._aiagent.org2.com. 3600 IN SVCB 1 ai-index-svc.org2.com. ( alpn="a2a" port=443 ipv4hint=192.0.2.1 ipv6hint=2001:db8::1 ) _a2a._aiagent.example.com.: The service name, following the SVCB naming convention (_service._agents.example.com). 3600: TTL (Time to Live) in seconds. IN SVCB: The record type. 1: SVCB priority. 0 is for alias mode; 1+ is for service mode. ai-index-svc.org2.com.: The target name of the service. alpn="a2a": Specifies the ALPN protocol identifier. This is where your custom protocol is declared. port=443: The port on which the service is available. ipv4hint and ipv6hint: Optional hints for clients to connect directly.

Example Use Cases

• A user instructs their internal agent to “clean up Salesforce contacts based on this email.” The agent must discover Salesforce’s authorized agents, validate its own delegation to act on behalf of the enterprise, and initiate a secure session. BANDAID enables this by publishing agent endpoints and roles under DNS zones controlled by each organization.

• A research consortium deploys agents across multiple institutions. Each institution publishes its agents under its own domain (e.g., _a2a._agents.universityA.edu), allowing collaborators to discover services based on capability (e.g., _data-annotator._a2a.universityB.edu) while respecting institutional boundaries and trust models.

• A SaaS provider hosts agents for multiple customers. Each customer’s agents are published under tenant-specific zones (e.g., customer1._agents.saas.com), enabling scoped discovery and policy enforcement. BANDAID supports this model through hierarchical zone delegation and metadata-rich SVCB records.

• Lightweight agents deployed on mobile or edge devices require low-latency, cacheable discovery mechanisms. DNS’s distributed architecture and support for SVCB hints (e.g., IP addresses, preferred protocols) enable efficient resolution and connection bootstrapping in constrained environments.

• In regulated industries, agents must operate within jurisdictional boundaries and maintain audit trails of interactions. DNS supports geographic scoping via ccTLDs and split-horizon configurations, while query logging and DNSSEC provide observability and integrity guarantees.

BANDAID Overview The BANDAID model is designed for incremental and non-disruptive deployment within existing DNS infrastructure. It introduces no new DNS message formats, opcodes, response codes, or resource record types. Instead, it defines a structured namespace convention and usage profile for existing record types... primarily SVCB, TXT, and TLSA all within designated leaf zones (e.g., _a2a._agents.example.com). Organizations may adopt BANDAID by publishing agent metadata under delegated subdomains, leveraging DNSSEC for integrity and authenticity, and optionally implementing Domain Control Validation (DCV) to signal delegated authority. These zones may be exposed selectively via split-horizon DNS, enabling differentiated discovery views for internal and external agents. No changes are required to recursive or authoritative DNS server implementations beyond standard support for DNSSEC and SVCB. This model supports opt-in adoption, allowing agent operators to publish discovery metadata without coordination with external registries or protocol maintainers. It is compatible with existing DNS tooling, including zone provisioning systems, monitoring platforms, and resolver configurations. BANDAID is therefore suitable for deployment across enterprise, cloud, and federated environments, and may coexist with other discovery mechanisms without conflict.

Zone and Other Requirements

Delegation and Chain of Trust An external authoritative zone used for the purposes of BANDAID MUST use DNSSEC . The BANDAID external zone MUST establish a complete chain of trust to a publicly recognized trust anchor. For zones delegated from a public parent, DS records MUST be present and maintained at the parent zone. DS digests MUST use SHA‑256 (Digest Type 2) as specified in ; SHA‑1 (Digest Type 1) MUST NOT be used. Where feasible, automation of DS maintenance SHOULD be performed using CDS and CDNSKEY as specified in and operationalized per .

Algorithms and Parameters Authoritative signers for the BANDAID External Zone MUST use DNSSEC algorithms and key sizes consistent with current implementation and usage guidance in . Implementations SHOULD prefer elliptic‑curve or EdDSA algorithms for efficiency and security, specifically ECDSA P‑256 (Algorithm 13; ) or Ed25519 (Algorithm 15; ). Zones MUST NOT rely on RSA/SHA‑1 signatures. If RSA is used for transitional reasons, key sizes SHOULD be ≥ 2048 bits and migration to ECDSA or EdDSA SHOULD be planned. Separation of roles between a Key‑Signing Key (KSK) and a Zone‑Signing Key (ZSK) is RECOMMENDED for operational agility, consistent with practices in . Private keys SHOULD be protected by appropriate controls (e.g., HSMs or equivalent) commensurate with organizational risk.

Authenticated Denial of Existence The BANDAID External Zone MUST provide authenticated denial of existence. NSEC3 is RECOMMENDED to mitigate trivial zone enumeration for zones where record names or labels might reveal sensitive information. If NSEC3 is used, the number of iterations SHOULD be kept modest to balance CPU cost for signers and validators, per guidance in . Use of NSEC with White Lies is OPTIONAL where operationally justified.

Signature Validity Signature validity windows MUST be chosen to balance cache efficiency and replay risk. In general, a signature lifetime on the order of days to a small number of weeks is RECOMMENDED, with staggered resigning to avoid mass expiration events . Resource Record TTLs MUST be set to values that support timely updates to BANDAID capability data while allowing effective caching; operational defaults SHOULD be validated against change frequency. Negative caching behavior MUST follow .

Key Rollover Zones MUST support planned key rollovers and emergency key replacement consistent with the procedures in . Pre‑publication and double‑signature techniques SHOULD be used to minimize validation failures during ZSK and KSK rollovers. Parent DS changes SHOULD be orchestrated using CDS/CDNSKEY signaling . Post‑compromise recovery procedures MUST be documented, including revocation, re‑signing, and DS replacement timelines.

Transport and Message Size Because DNSSEC increases response sizes, authoritative servers for the BANDAID External Zone MUST implement EDNS(0) per and MUST support TCP fallback for queries per . Authoritative operators SHOULD configure UDP response sizing to minimize IP fragmentation risk and SHOULD ensure that large responses (e.g., DNSKEY, NSEC3 chains) remain retrievable via TCP.

Transfer and Integrity When secondary authoritative servers are used, zone transfers MUST be authenticated and protected with TSIG . Use of DNS NOTIFY and incremental transfer (IXFR; ) is RECOMMENDED to reduce propagation latency and bandwidth. To provide at‑rest integrity verification between primaries and secondaries, publishing a ZONEMD record is RECOMMENDED where supported .

Monitoring Operators MUST monitor DNSSEC validity from multiple vantage points to detect stale signatures, DS/DNSKEY mismatches, and other validation failures. Alarms SHOULD be configured for impending signature expiration, key compromise indicators, and DS inconsistencies. Signing infrastructure SHOULD be tested under load and failure scenarios consistent with the scalability requirements of this specification.

Abuse Resistance Authoritative servers for the BANDAID External Zone SHOULD implement DNS Cookies to reduce off‑path spoofing and amplification risks. Operators SHOULD follow best practices to limit amplification and to shape responses under attack, consistent with maintaining DNSSEC validity.

BANDAID Records All BANDAID‑specific discovery records (e.g., SRV , SVCB/HTTPS , TXT/URI used for capability descriptors, and any BANDAID‑defined RRTypes) MUST be signed and published in the BANDAID External Zone. Where BANDAID endpoints rely on TLS, publication of DANE TLSA records SHOULD be used to bind endpoint certificates to DNSSEC‑validated names . Resolver behavior consuming BANDAID data MUST treat DNSSEC‑bogus responses as failures and MUST NOT act on unsigned or invalidly signed discovery data.

Performance Optimization(s) The discovery namespace for BANDAID SHOULD be structured to minimize query depth, RRset size, and update blast radius. To that end, implementers SHOULD allocate per‑service, per‑agent leaf names and avoid aggregating high‑cardinality data under a single owner name. A deterministic mapping (e.g., a stable hash of an Agent Identifier) to leaf labels SHOULD be used to support sharding and parallel administration. Where cardinality requires, sub‑zones MAY be delegated (zone cuts) to distribute authority and update load. Each agent service endpoint SHOULD be published using SVCB in ServiceMode (or HTTPS RR for HTTPS endpoints) to convey connection parameters and capability locators with a single lookup . SVCB “address hints” (ipv4hint, ipv6hint) SHOULD be used to reduce A/AAAA follow‑up queries; resolvers MAY still validate final addresses via canonical resolution. Where human‑friendly names are required, SVCB AliasMode (priority 0) MAY be used to map from a stable alias to a hashed leaf, avoiding record duplication while preserving cache locality. Authoritative servers MUST support EDNS(0) and TCP fallback . Operators SHOULD target response sizes that avoid IP fragmentation on common paths (e.g., ≤1232 bytes on IPv6), preferring compression and layered indirection over oversized RRsets. TTLs MUST be chosen to reflect the volatility of capability data; index/indirection records may use longer TTLs than frequently changing endpoint or capability descriptors. Negative caching MUST conform to . When high update rates are expected, IXFR and NOTIFY SHOULD be used to reduce propagation latency. Resolvers and authoritative operators SHOULD take advantage of SVCB’s ALPN, port, and (for HTTPS) ECH parameters to enable connection pre‑establishment and reduce round‑trips, subject to client policy and security posture . Where privacy policies prohibit client geolocation, EDNS Client Subnet SHOULD NOT be relied upon for performance. A representative naming pattern is shown below; the exact label order is deployment‑specific, but the leaf per service, per agent rule applies: ``` ; Hashed, per-agent, per-service leaf a4k2f9._mcp._bandaid.example.org. 600 IN SVCB 1 svc-a4k2f9.example.org. alpn="h2,h3" port=443 ipv6hint=2001:db8::5 ipv4hint=192.0.2.5 ; Optional alias for a friendlier owner name billing._mcp._bandaid.example.org. 300 IN SVCB 0 a4k2f9._mcp._bandaid.example.org. ```

Customization(s) BANDAID deployments MAY define additional SVCB parameters (SvcParamKeys) to convey agent‑specific capability metadata, provided that interoperability safeguards in are observed. During experimentation, unregistered keys MUST use the numeric keyNNNNN presentation form, and any client behavior that depends on them MUST be gated via the mandatory SvcParam to ensure downgrade safety. This specification defines the following provisional SvcParamKeys for BANDAID (names are illustrative; production deployments MUST register through IANA per or use keyNNNNN until standardized):

• cap — a capability descriptor locator or inline identifier (e.g., a URN or compact JSON‑Ref) that identifies the agent’s advertised capability schema/version. cap-sha256 — a base64url‑encoded SHA‑256 digest of the canonical capability descriptor to support integrity checks and cache revalidation. bap — a comma‑separated list of BANDAID Application Protocols and versions understood by the endpoint (e.g., bap="a2a/1,mcp/1,acp/2"). This is distinct from transport‑level alpn. policy — a URI or URN identifying a policy bundle applicable to this agent (e.g., jurisdiction, data handling class) for client‑side selection. realm — an opaque token for multi‑tenant scoping or authz realm selection during protocol bootstrapping.

Clients that require any of these parameters MUST verify their presence via the mandatory key; otherwise, the SVCB record MUST be ignored. Example: Single-RRTYPE publication with custom params (experimental keys shown) a4k2f9._mcp._bandaid.example.org. 600 IN SVCB 1 svc-a4k2f9.example.org. alpn="h2" port=443 ipv4hint=192.0.2.5 mandatory=alpn,port,key65001,key65002,key65010 key65001="cap=urn:cap:example:mcp:invoice.v1" key65002="cap-sha256=yvZ0n7q8bE2gYkz8m1j1s0yQG0mC2F6qj3b9pVb6Gk0" key65010="bap=a2a/1,mcp/1" Where endpoints are HTTPS, the HTTPS RR variant SHOULD be used to co‑locate transport parameters such as ech with capability metadata; otherwise, generic SVCB MAY be used. Future standardization SHOULD define the exact syntax (e.g., ABNF) and registry policy for these keys, including error handling for malformed or conflicting parameters. Until registration is complete, deployments MUST treat unknown keyNNNNN parameters as opaque and MUST NOT infer semantics without out‑of‑band agreement.

Implementation Guidance

AI Operators

Separation of Roles Operators MUST separate authoritative servers for BANDAID zones from recursive resolvers to prevent cache poisoning and reduce operational coupling. Authoritative servers MUST NOT perform recursion. Recursive resolvers SHOULD be deployed close to query sources (e.g., within organizational networks or edge PoPs) to minimize latency and reduce upstream load.

Local Root Zone Copy Recursive resolvers serving BANDAID traffic SHOULD maintain a local copy of the root zone as specified in . This eliminates dependency on external root servers for priming queries, reduces resolution latency, and improves resilience during partial Internet outages or denial‑of‑service events targeting root infrastructure.

Aggressive Caching and Prefetch Resolvers MUST implement RFC‑compliant caching and SHOULD enable the aggressive use of DNSSEC‑validated cache to synthesize negative answers from NSEC/NSEC3 and reduce upstream lookups, consistent with . This behavior improves latency, lowers authoritative load, and can mitigate certain attack patterns by answering within validated non‑existence ranges. Resolvers SHOULD implement serve‑stale as specified in . When authoritative servers are unreachable or fail to refresh data, a resolver MAY return expired records from its cache to preserve availability, subject to policy caps on staleness. updates the TTL semantics to allow use beyond expiration under these exceptional conditions and RECOMMENDS capping staleness on the order of days, with a typical cap of 7 days. When serving stale data, the TTL in the response MUST be set to a value greater than zero (with 30 seconds RECOMMENDED) so clients and intermediaries do not cache a zero‑TTL response indefinitely. Resolvers implementing serve‑stale SHOULD follow the timer guidance in : continue background refresh (“stale‑while‑revalidate”), bound total resolution work with a query‑resolution timer, avoid excessive re‑tries with a failure‑recheck timer (no more frequently than ~30 seconds is RECOMMENDED), and ensure client responsiveness with a client‑response timer (on the order of ~1.8 seconds is RECOMMENDED). These controls balance resiliency with freshness and protect upstream authorities during outages or attack conditions. Operators MUST consider DNSSEC interactions when serving stale data. Stale answers can increase the likelihood that signatures are outside their validity windows; implementations MUST NOT misrepresent validation status (e.g., AD bit handling MUST follow DNSSEC semantics where the bit is only set if all relevant RRsets are cryptographically verified according to local policy). Prefetch of popular BANDAID names SHOULD be used to keep caches warm, and negative caching MUST follow to avoid unnecessary upstream traffic during flaps. Where serve‑stale is enabled, operators SHOULD monitor stale‑answer rates and staleness distribution to ensure that policy caps and refresh behavior meet availability and freshness objectives.

EDNS(0) Transport Resilience All servers MUST support EDNS(0) and TCP fallback to accommodate DNSSEC and SVCB responses that exceed traditional UDP size limits. Operators SHOULD configure UDP response sizing to avoid IP fragmentation (e.g., ≤1232 bytes for IPv6 paths) and SHOULD monitor truncation rates to detect misconfigurations or path MTU issues.\

Load Distribution Authoritative servers for BANDAID zones SHOULD be deployed using IP anycast to provide global reachability, load balancing, and DDoS resilience. Recursive resolvers SHOULD be deployed in a geographically distributed manner to minimize latency for agent queries and to provide failover during regional outages.

Monitoring and Telemetry Operators MUST implement continuous monitoring of query latency, cache hit ratios, DNSSEC validation success rates, and transport fallback events. Alarms SHOULD be configured for anomalies such as sudden TTL exhaustion, signature expiration, or upstream unreachability. Logging MUST respect privacy and regulatory constraints while providing sufficient detail for operational troubleshooting and compliance audits.

Encrypted Resolver Steering (Informative) AI clients and operators MAY implement Encrypted DNS Server Redirection (EDSR) to permit an encrypted resolver to redirect a client to another encrypted resolver for performance, locality, or policy reasons Any acceptance of redirection MUST follow the verified-discovery model of DDR , including validation of the designated relationship and TLS authentication of the target resolver. If redirection validation fails or exceeds a single hop, clients MUST continue to use the original resolver configuration. When available, network-designated resolvers provisioned via DNR take precedence over unsolicited redirection unless local policy dictates otherwise. EDSR is currently an Internet-Draft and is referenced as an OPTIONAL extension.

AI Consumers

DNS-Based Service Discovery DNS-Based Service Discovery AI clients that consume BANDAID discovery data MUST implement DNS‑based service discovery consistent with and . Clients SHOULD query for SVCB or HTTPS records at well‑defined service labels (e.g., _mcp._bandaid.example.org.) and interpret alpn, port, and custom SvcParams as specified in this document. Where multiple priorities are returned, clients MUST honor the SVCB priority and weight semantics for selection and failover. Clients MUST validate DNSSEC signatures for all discovery responses and MUST NOT act on unsigned or bogus data. Clients SHOULD implement caching consistent with TTLs and negative caching rules in . Prefetching of high‑traffic names MAY be used to reduce latency, provided that it does not violate policy or privacy constraints. Clients MUST support EDNS(0) and TCP fallback to handle large responses.

Communication Failure / Retry When a discovered agent endpoint is unreachable, clients MUST implement retry logic that respects exponential backoff and avoids synchronized retry storms. Clients SHOULD attempt alternate SVCB targets in priority order before declaring failure. Where serve‑stale responses are received, clients MUST treat them as advisory and MUST NOT assume freshness beyond the TTL indicated in the response. Clients SHOULD log stale usage for observability and compliance.

Domain Control Validation To prevent impersonation and unauthorized data access, BANDAID deployments MUST support Domain Control Validation (DCV) using DNS. This mechanism allows application owners to verify that a requesting service is authorized to act on behalf of a domain (e.g., “AI, sync all customer contacts from my approved CRM for acme.org”). DCV MUST follow a challenge‑response model where the domain owner publishes a cryptographically strong token in a DNS TXT record under a well‑defined label (e.g., _bandaid-challenge.acme.org.). The token MUST be bound to the requesting service identity and have a bounded validity period. Clients performing DCV MUST validate the token against the expected value and expiration before granting delegated access. Tokens SHOULD be single‑use and MUST be removed from DNS after successful validation. All DCV interactions MUST occur over DNSSEC‑validated channels to prevent spoofing or downgrade attacks.

AI Developers

Publishing Schema Publishers SHOULD expose per‑service discovery records using SVCB (or HTTPS for HTTP origins) at stable, well‑scoped owner names (e.g., agent-id._mcp._bandaid.example.org.). SVCB ServiceMode conveys connection parameters and capability locators in a single round trip; AliasMode MAY be used to map a friendly name to a hashed leaf for sharding without duplicating RRSets. Initial connection parameter keys (alpn, port, address hints) and the mandatory key MUST be honored by clients. Minimal example: ; ServiceMode SVCB for an MCP-capable agent a4k2f9._mcp._bandaid.example.org. 600 IN SVCB 1 svc-a4k2f9.example.net. alpn="h2,h3" port=443 ipv6hint=2001:db8::5 ipv4hint=192.0.2.5 mandatory=alpn,port SVCB/HTTPS semantics and SvcParam processing MUST follow to ensure interop and correct fallback.

TTLs, Update Agility Publishers SHOULD assign longer TTLs to relatively static indirection records (aliases, stable service labels) and shorter TTLs to volatile endpoint/capability records to balance cache efficiency with rollout safety. Consumers will apply negative caching per , so publishers SHOULD avoid unnecessary NXDOMAIN flaps during deployments (e.g., prefer blue/green leaves over in‑place deletions).

Capability Retrieval When capability metadata is referenced via URI from SVCB/HTTPS, retrieval MUST occur over authenticated, confidential channels. Publishers SHOULD offer TLS 1.3 and MAY bind endpoint identity via DANE TLSA where resolvers validate DNSSEC; otherwise, WebPKI validation applies. Operational guidance for DANE usage (certificate usage selections, rollover) SHOULD follow Where using HTTPS RRs, publishers MAY advertise the ech SvcParam to enable Encrypted Client Hello for privacy; client/server behavior and key distribution MUST follow the semantics described in for the ech parameter.

Example DCV Flow Example DCV Flow (Normative Sketch) The relying service issues a DCV challenge with a nonce bound to its identity and an expiration time. The domain owner publishes the nonce at _bandaid-challenge.domain. as a TXT RR until validation completes. The verifier performs a DNSSEC‑validated TXT query and compares the presented nonce and binding; on success, access is granted and the TXT is removed. need a sketch for how this looks

Example Zonefile ``` $ORIGIN example.org. $TTL 3600 ; ---------------------------------------------------------------------- ; SOA / NS ; ---------------------------------------------------------------------- @ IN SOA ns1.example.org. hostmaster.example.org. ( 2025091901 ; serial (YYYYMMDDnn) 7200 ; refresh 1800 ; retry 1209600 ; expire 3600 ) ; minimum IN NS ns1.example.org. IN NS ns2.example.org. ns1 IN A 192.0.2.53 ns1 IN AAAA 2001:db8::53 ns2 IN A 192.0.2.54 ns2 IN AAAA 2001:db8::54 ; ---------------------------------------------------------------------- ; BANDAID discovery (MCP example): per-service, per-agent leaf ; - Leaf is a stable mapping from AgentID -> label (e.g. hashed). ; - Use SVCB ServiceMode (priority > 0) to bind connection parameters. ; ---------------------------------------------------------------------- ; AliasMode to keep a friendly name stable even if the leaf changes billing._mcp._bandaid 300 IN SVCB 0 a4k2f9._mcp._bandaid.example.org. ; Leaf per agent/service (ServiceMode). Shorter TTL for agility. a4k2f9._mcp._bandaid 600 IN SVCB 1 svc-a4k2f9.example.net. \ alpn="h2,h3" \ port=443 \ ipv4hint=192.0.2.5 \ ipv6hint=2001:db8::5 \ mandatory=alpn,port ; (Optional) Another service face for the same agent (A2A) a4k2f9._a2a._bandaid 600 IN SVCB 1 svc-a4k2f9.example.net. \ alpn="h2" port=8443 \ mandatory=alpn,port ; (Optional) HTTPS RR at apex for web-style consumers of BANDAID metadata @ 900 IN HTTPS 1 web-gw.example.net. \ alpn="h2,h3" port=443 ; ---------------------------------------------------------------------- ; Capability / policy signaling via SVCB custom keys (experimental) ; Use numeric keyNNNNN until you register IANA SvcParamKeys. ; Gate client requirements with "mandatory". ; ---------------------------------------------------------------------- ; Example: reference a capability descriptor and advertise supported app protocols. ; NOTE: Values and key numbers are illustrative. a4k2f9._mcp._bandaid 600 IN SVCB 1 svc-a4k2f9.example.net. \ alpn="h2,h3" port=443 \ mandatory=alpn,port,key65001,key65010 \ key65001="cap=urn:cap:example:mcp:invoice.v1" \ key65010="bap=a2a/1,mcp/1" ; ---------------------------------------------------------------------- ; Domain Control Validation (DCV) for BANDAID authorization ; Publish a short-lived token to prove control over example.org. ; Remove after successful validation. Resolver MUST DNSSEC-validate. ; ---------------------------------------------------------------------- _bandaid-challenge 300 IN TXT "bnd-req=svc:crm-sync@vendor.example;nonce=3Qz6l8pA;exp=2025-09-19T06:00:00Z" ; ---------------------------------------------------------------------- ; Optional DANE TLSA for the service endpoint used above. ; Owner: _<port>._tcp.<endpoint-FQDN> ; Usage 3 (DANE-EE), Selector 1 (SPKI), Match 1 (SHA-256) ; Replace the hash with the actual SPKI hash of the leaf certificate. ; ---------------------------------------------------------------------- _443._tcp.svc-a4k2f9.example.net. 1800 IN TLSA 3 1 1 ( 0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789AB ) ; ---------------------------------------------------------------------- ; (Optional) Address records for the service endpoint, if hosted in-zone ; If hosted out-of-zone (example.net), these will live there instead. ; ---------------------------------------------------------------------- svc-a4k2f9 900 IN A 192.0.2.5 svc-a4k2f9 900 IN AAAA 2001:db8::5 web-gw 900 IN A 192.0.2.80 web-gw 900 IN AAAA 2001:db8::80 ```

How to use this zonefile Adjust TTLs for agility vs. cache efficiency. Use longer TTLs on indirection (aliases), shorter TTLs on volatile leaves and DCV. This aligns with DNS caching behavior and negative caching rules . Follow SVCB/HTTPS semantics. Clients must honor SvcPriority, AliasMode (priority 0), and ServiceMode parameters, including mandatory, alpn, port, and address hints per . DCV token flow. Issue a time‑bounded token at _bandaid-challenge.domain and require DNSSEC‑validated retrieval (pattern analogous to ACME’s DNS‑01 in ). Remove on success. Bind transport to DNS with DANE (optional). If your relying parties validate DNSSEC, publish TLSA to bind the endpoint’s cert/key, using the operational guidance in (TLSA record format in ). Sign the zone. This file is pre‑signing. Sign with DNSSEC (DNSKEY/DS/RRSIG, etc.) before deployment; validators must treat unsigned/bogus discovery data as a failure (per your earlier spec). See DNSSEC core specs , , and operational guidance.

Why these records SVCB/HTTPS concentrate connection metadata and allow aliasing at apex and service labels, reducing round trips and enabling policy‑gated params via mandatory. Per‑service, per‑agent leaves avoid oversized RRsets and allow parallel administration/sharding while keeping alias names stable. This follows performance guidance in SVCB and your BANDAID perf section. DCV via TXT mirrors a well‑understood, automated control‑proof pattern that fits BANDAID authorization workflows. DANE TLSA optionally removes reliance on external PKI anchors for endpoint auth where DNSSEC is deployed , with deployment rules in .

Conclusion The discovery of AI agents at Internet scale introduces requirements for autonomy, security, resilience, and interoperability that cannot be met by ad‑hoc or centralized mechanisms. Organizations must advertise capabilities in a manner that is globally unique, cryptographically verifiable, and operationally scalable, while preserving compliance with regulatory and sovereignty constraints. The solution space must account for dynamic lifecycles, selective disclosure, and the ability to integrate with existing infrastructure without introducing new trust anchors or governance choke points. This document defines BANDAID as a DNS‑based discovery framework that leverages the global DNS namespace, DNSSEC for integrity and authenticity, and SVCB/HTTPS records for structured capability advertisement. By building on widely deployed protocols and operational practices, BANDAID provides a predictable entry point for agent discovery, supports hierarchical delegation for organizational autonomy, and enables secure, low‑latency resolution at scale. Extensions such as custom SvcParams, DNS‑based domain control validation, and optional DANE bindings further strengthen trust and interoperability. Future work includes standardizing capability schemas, formalizing SvcParam registries for BANDAID metadata, and defining privacy‑preserving query mechanisms (like authoritative DOT/H/Q). By aligning with existing Internet standards and operational best practices, BANDAID offers a path to interoperable, secure, and resilient AI agent discovery without reinventing the foundational layers of the Internet.

Future Work & Unaddressed Portions Index versus agents publishing their updates, etc. Unresolved in the use case of it being better to have an index which is a list of all agents an org owns, or allow records within the zone to be the record of truth. For example, a company may only have a few external agents available for use, and if the IETF standardizes 'types' of AI agents, then perhaps _chat._ai.domain.com or _img2txt._ai.domain.com etc are all different SVCB records.

Security Considerations To add: Lookalikes, takedowns, misbehaving agents, compliance, privacy

IANA Considerations IANA are to consider registering an underscored attribute leaf as part of for BANDAID. IANA are to consider designating custom key-value pairs for SVCB parameters to facilitate agent-to-agent application discovery, potentially for cost optimization (token input counts, costs per token bundle, etc.)

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. Infoblox, Inc. Infoblox, Inc. Unaffiliated Deutsche Telekom With the deployment of AI agents comes a need for mechanisms to support agent-to-agent discovery. This document presents requirements and considerations for agent-to-agent discovery. Five9 Cisco AI Agents are software applications that utilize Large Language Models (LLM)s to interact with humans (or other AI Agents) for purposes of performing tasks. AI Agents can make use of resources - including APIs and documents - to perform those tasks, and are capable of reasoning about which resources to use. To facilitate AI agent operation, AI agents need to communicate with users, and then interact with other resources over the Internet, including APIs and other AI agents. This document describes a framework for AI Agent communications on the Internet, identifying the various protocols that come into play. It introduces use cases that motivate features and functions that need to be present in those protocols. It also provides a brief survey of existing work in standardizing AI agent protocols, including the Model Context Protocol (MCP), the Agent to Agent Protocol (A2A) and the Agntcy Framework, and describes how those works fit into this framework. The primary objective of this document is to set the stage for possible standards activity at the IETF in this space. Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server; those resolvers may have difficulty getting responses from the root servers, such as during a network attack. Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. In both cases, resolvers can greatly decrease the round-trip time and prevent observation of requests by serving a copy of the full root zone on the same server, such as on a loopback address or in the resolver software. This document shows how to start and maintain such a copy of the root zone that does not cause problems for other users of the DNS, at the cost of adding some operational fragility for the operator. This document obsoletes RFC 7706. 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. 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. 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] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD. Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK] This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience. It also contains guidance for implementers, operators, and protocol developers who want to use DANE records. This document specifies how to use the SHA-256 digest type in DNS Delegation Signer (DS) Resource Records (RRs). DS records, when stored in a parent zone, point to DNSKEYs in a child zone. [STANDARDS-TRACK] This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel. The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent. RFC 7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevates RFC 7344 from Informational to Standards Track. It also adds a method for initial trust setup and removal of a secure entry point. Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at a large scale. This document adds a method for in-band signaling of these DNSSEC status changes. This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records). It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key (KSK) plus Zone Signing Key (ZSK) rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record. The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of nonexistence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for DNSSEC. This document obsoletes RFC 6944. This document describes how to specify Elliptic Curve Digital Signature Algorithm (DSA) keys and signatures in DNS Security (DNSSEC). It lists curves of different sizes and uses the SHA-2 family of hashes for signatures. [STANDARDS-TRACK] This document describes how to specify Edwards-curve Digital Security Algorithm (EdDSA) keys and signatures in DNS Security (DNSSEC). It uses EdDSA with the choice of two curves: Ed25519 and Ed448. This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK] RFC1034 provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK] This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123. This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server. [STANDARDS-TRACK] This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data. [STANDARDS-TRACK] The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035. The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism. [STANDARDS-TRACK] This document describes a protocol and new DNS Resource Record that provides a cryptographic message digest over DNS zone data at rest. The ZONEMD Resource Record conveys the digest data in the zone itself. When used in combination with DNSSEC, ZONEMD allows recipients to verify the zone contents for data integrity and origin authenticity. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. When used without DNSSEC, ZONEMD functions as a checksum, guarding only against unintentional changes. ZONEMD does not replace DNSSEC: DNSSEC protects individual RRsets (DNS data with fine granularity), whereas ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications. As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and resources required for digest calculation. However, the ZONEMD record is extensible so that new digest schemes may be added in the future to support large, dynamic zones. DNS Cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification/ forgery or cache poisoning attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT (Network Address Translation - Protocol Translation), and anycast and can be incrementally deployed. (Since DNS Cookies are only returned to the IP address from which they were originally received, they cannot be used to generally track Internet users.) DNS Cookies, as specified in RFC 7873, are a lightweight DNS transaction security mechanism that provide limited protection to DNS servers and clients against a variety of denial-of-service amplification, forgery, or cache-poisoning attacks by off-path attackers. This document updates RFC 7873 with precise directions for creating Server Cookies so that an anycast server set including diverse implementations will interoperate with standard clients, with suggestions for constructing Client Cookies in a privacy-preserving fashion, and with suggestions on how to update a Server Secret. An IANA registry listing the methods and associated pseudorandom function suitable for creating DNS Server Cookies has been created with the method described in this document as the first and, as of the time of publication, only entry. This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK] This document describes the already registered DNS resource record (RR) type, called the Uniform Resource Identifier (URI) RR, that is used for publishing mappings from hostnames to URIs. The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource utilization on both authoritative and recursive servers, and increases privacy. Also, it may help increase resilience to certain DoS attacks in some circumstances. This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards. This document defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. One of the motivations for serve-stale is to make the DNS more resilient to DoS attacks and thereby make them less attractive as an attack vector. This document updates the definitions of TTL from RFCs 1034 and 1035 so that data can be kept in the cache beyond the TTL expiry; it also updates RFC 2181 by interpreting values with the high-order bit set as being positive, rather than 0, and suggests a cap of 7 days. This document defines Discovery of Designated Resolvers (DDR), a set of mechanisms for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An Encrypted DNS Resolver discovered in this manner is referred to as a "Designated Resolver". These mechanisms can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. These mechanisms are designed to be limited to cases where Unencrypted DNS Resolvers and their Designated Resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an Encrypted DNS Resolver is known. This document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS, and DNS over QUIC). Particularly, it allows a host to learn an Authentication Domain Name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers. 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. Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. 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.

Acknowledgments The authors thank Ross Gibson for his contributions, questions and comments.