dnsop J. Mozley Internet-Draft N. Williams Intended status: Standards Track Infoblox, Inc. Expires: 19 April 2026 B. Sarikaya Unaffiliated R. Schott Deutsche Telecom 16 October 2025 Brokered Agent Network for DNS AI Discovery draft-mozleywilliams-dnsop-bandaid-00 Abstract 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._ About This Document This note is to be removed before publishing as an RFC. Mozley, et al. Expires 19 April 2026 [Page 1] Internet-Draft BANDAID October 2025 The latest revision of this draft can be found at https://example.com/LATEST. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mozleywilliams- dnsop-bandaid/. Discussion of this document takes place on the WG Working Group mailing list (mailto:WG@example.com), which is archived at https://example.com/WG. Source for this draft and an issue tracker can be found at https://github.com/USER/REPO. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 19 April 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 Mozley, et al. Expires 19 April 2026 [Page 2] Internet-Draft BANDAID October 2025 2.1. Challenges with Existing Proposed Mechanisms and Benefits of DNS . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Development . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Opportunity Cost . . . . . . . . . . . . . . . . . . 6 2.1.3. Governance . . . . . . . . . . . . . . . . . . . . . 7 2.1.4. Sovereignty . . . . . . . . . . . . . . . . . . . . . 8 2.1.5. Commerce . . . . . . . . . . . . . . . . . . . . . . 8 2.1.6. Application . . . . . . . . . . . . . . . . . . . . . 9 2.1.7. Granularity . . . . . . . . . . . . . . . . . . . . . 9 2.1.8. Performance . . . . . . . . . . . . . . . . . . . . . 10 2.1.9. Lifecycle / Management . . . . . . . . . . . . . . . 10 2.1.10. Trust . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1.11. Agent Properties . . . . . . . . . . . . . . . . . . 11 2.1.12. Control . . . . . . . . . . . . . . . . . . . . . . . 12 2.2. Mechanisms for Successful Agent Communication . . . . . . 13 2.2.1. Service Binding Records, aka SVCB . . . . . . . . . . 13 2.2.2. DNS Security Extensions, aka DNSSEC . . . . . . . . . 14 2.2.3. DNS Service Discovery, aka DNS-SD . . . . . . . . . . 15 2.2.4. DNS-Based Authentication of Named Entities, aka DANE . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2.5. Domain Control Validation, aka DCV . . . . . . . . . 16 2.2.6. Service Resilience . . . . . . . . . . . . . . . . . 17 2.2.7. Observability, Auditability . . . . . . . . . . . . . 17 2.2.8. Interoperability . . . . . . . . . . . . . . . . . . 18 2.2.9. Multitenancy, Federation . . . . . . . . . . . . . . 18 2.3. Architecture . . . . . . . . . . . . . . . . . . . . . . 18 2.3.1. Example Communication . . . . . . . . . . . . . . . . 18 2.3.2. Example Record . . . . . . . . . . . . . . . . . . . 18 2.3.3. Example Use Cases . . . . . . . . . . . . . . . . . . 19 3. BANDAID Overview . . . . . . . . . . . . . . . . . . . . . . 20 3.1. Zone and Other Requirements . . . . . . . . . . . . . . . 20 3.1.1. Delegation and Chain of Trust . . . . . . . . . . . . 20 3.1.2. Algorithms and Parameters . . . . . . . . . . . . . . 21 3.1.3. Authenticated Denial of Existence . . . . . . . . . . 21 3.1.4. Signature Validity . . . . . . . . . . . . . . . . . 21 3.1.5. Key Rollover . . . . . . . . . . . . . . . . . . . . 21 3.1.6. Transport and Message Size . . . . . . . . . . . . . 22 3.1.7. Transfer and Integrity . . . . . . . . . . . . . . . 22 3.1.8. Monitoring . . . . . . . . . . . . . . . . . . . . . 22 3.1.9. Abuse Resistance . . . . . . . . . . . . . . . . . . 22 3.1.10. BANDAID Records . . . . . . . . . . . . . . . . . . . 22 3.1.11. Performance Optimization(s) . . . . . . . . . . . . . 23 3.1.12. Customization(s) . . . . . . . . . . . . . . . . . . 24 4. Implementation Guidance . . . . . . . . . . . . . . . . . . . 25 4.1. AI Operators . . . . . . . . . . . . . . . . . . . . . . 25 4.1.1. Separation of Roles . . . . . . . . . . . . . . . . . 25 4.1.2. Local Root Zone Copy . . . . . . . . . . . . . . . . 25 4.1.3. Aggressive Caching and Prefetch . . . . . . . . . . . 25 Mozley, et al. Expires 19 April 2026 [Page 3] Internet-Draft BANDAID October 2025 4.1.4. EDNS(0) Transport Resilience . . . . . . . . . . . . 26 4.1.5. Load Distribution . . . . . . . . . . . . . . . . . . 26 4.1.6. Monitoring and Telemetry . . . . . . . . . . . . . . 26 4.1.7. Encrypted Resolver Steering (Informative) . . . . . . 27 4.2. AI Consumers . . . . . . . . . . . . . . . . . . . . . . 27 4.2.1. DNS-Based Service Discovery . . . . . . . . . . . . . 27 4.2.2. Communication Failure / Retry . . . . . . . . . . . . 27 4.2.3. Domain Control Validation . . . . . . . . . . . . . . 28 4.3. AI Developers . . . . . . . . . . . . . . . . . . . . . . 28 4.3.1. Publishing Schema . . . . . . . . . . . . . . . . . . 28 4.3.2. TTLs, Update Agility . . . . . . . . . . . . . . . . 28 4.3.3. Capability Retrieval . . . . . . . . . . . . . . . . 29 4.3.4. Example DCV Flow . . . . . . . . . . . . . . . . . . 29 4.3.5. Example Zonefile . . . . . . . . . . . . . . . . . . 29 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.1. Future Work & Unaddressed Portions . . . . . . . . . . . 32 6. Security Considerations . . . . . . . . . . . . . . . . . . . 33 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 8.1. Normative References . . . . . . . . . . . . . . . . . . 33 8.2. Informative References . . . . . . . . . . . . . . . . . 33 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. 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 Mozley, et al. Expires 19 April 2026 [Page 4] Internet-Draft BANDAID October 2025 $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 [I-D.draft-mozley-aidiscovery] and also relevant is [I-D.draft-rosenberg-ai-protocols] although this draft is related to the discovery of agents rather than protocols used directly in agent- to-agent communication. 2.1. 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. Mozley, et al. Expires 19 April 2026 [Page 5] Internet-Draft BANDAID October 2025 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. 2.1.1. 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. 2.1.2. 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 Mozley, et al. Expires 19 April 2026 [Page 6] Internet-Draft BANDAID October 2025 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. 2.1.3. 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 Mozley, et al. Expires 19 April 2026 [Page 7] Internet-Draft BANDAID October 2025 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. 2.1.4. 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. 2.1.5. 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. Mozley, et al. Expires 19 April 2026 [Page 8] Internet-Draft BANDAID October 2025 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. 2.1.6. 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. 2.1.7. 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 Mozley, et al. Expires 19 April 2026 [Page 9] Internet-Draft BANDAID October 2025 (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. 2.1.8. 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 [RFC8806], 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. 2.1.9. 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. Mozley, et al. Expires 19 April 2026 [Page 10] Internet-Draft BANDAID October 2025 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. 2.1.10. 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. 2.1.11. 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. Mozley, et al. Expires 19 April 2026 [Page 11] Internet-Draft BANDAID October 2025 Service Binding (SVCB) records, as defined in [RFC9460], 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. 2.1.12. 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 Mozley, et al. Expires 19 April 2026 [Page 12] Internet-Draft BANDAID October 2025 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. 2.2. Mechanisms for Successful Agent Communication The explicit goal of the DNS [RFC1035] 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. 2.2.1. Service Binding Records, aka SVCB The SVCB resource record as defined in [RFC9460], 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. Mozley, et al. Expires 19 April 2026 [Page 13] Internet-Draft BANDAID October 2025 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. 2.2.2. DNS Security Extensions, aka DNSSEC DNSSEC as defined in [RFC4033], [RFC4034], and [RFC4035], 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. Mozley, et al. Expires 19 April 2026 [Page 14] Internet-Draft BANDAID October 2025 2.2.3. DNS Service Discovery, aka DNS-SD DNS-SD as defined in [RFC6763], 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. 2.2.4. DNS-Based Authentication of Named Entities, aka DANE DANE as specified in [RFC6698] and [RFC7671], 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). Mozley, et al. Expires 19 April 2026 [Page 15] Internet-Draft BANDAID October 2025 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. 2.2.5. 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 Mozley, et al. Expires 19 April 2026 [Page 16] Internet-Draft BANDAID October 2025 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. 2.2.6. 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. 2.2.7. 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. Mozley, et al. Expires 19 April 2026 [Page 17] Internet-Draft BANDAID October 2025 2.2.8. 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. 2.2.9. 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. 2.3. Architecture 2.3.1. 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 │ │) │ └───────────────────────────────────────────────────────────────┘ 2.3.2. 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 ) Mozley, et al. Expires 19 April 2026 [Page 18] Internet-Draft BANDAID October 2025 _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. 2.3.3. 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. Mozley, et al. Expires 19 April 2026 [Page 19] Internet-Draft BANDAID October 2025 3. 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. 3.1. Zone and Other Requirements 3.1.1. Delegation and Chain of Trust An external authoritative zone used for the purposes of BANDAID MUST use DNSSEC [RFC4033]. 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 [RFC4509]; 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 [RFC7344] and operationalized per [RFC8078]. Mozley, et al. Expires 19 April 2026 [Page 20] Internet-Draft BANDAID October 2025 3.1.2. 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 [RFC8624]. Implementations SHOULD prefer elliptic-curve or EdDSA algorithms for efficiency and security, specifically ECDSA P-256 (Algorithm 13; [RFC6605]) or Ed25519 (Algorithm 15; [RFC8080]). 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 [RFC6781]. Private keys SHOULD be protected by appropriate controls (e.g., HSMs or equivalent) commensurate with organizational risk. 3.1.3. Authenticated Denial of Existence The BANDAID External Zone MUST provide authenticated denial of existence. NSEC3 [RFC5155] 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 [RFC6781]. Use of NSEC with White Lies is OPTIONAL where operationally justified. 3.1.4. 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 [RFC6781]. 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 [RFC2308]. 3.1.5. Key Rollover Zones MUST support planned key rollovers and emergency key replacement consistent with the procedures in [RFC6781]. 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 [RFC7344][RFC8078]. Post-compromise recovery procedures MUST be documented, including revocation, re-signing, and DS replacement Mozley, et al. Expires 19 April 2026 [Page 21] Internet-Draft BANDAID October 2025 timelines. 3.1.6. Transport and Message Size Because DNSSEC increases response sizes, authoritative servers for the BANDAID External Zone MUST implement EDNS(0) per [RFC6891] and MUST support TCP fallback for queries per [RFC7766]. 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. 3.1.7. Transfer and Integrity When secondary authoritative servers are used, zone transfers MUST be authenticated and protected with TSIG [RFC2845]. Use of DNS NOTIFY [RFC1996] and incremental transfer (IXFR; [RFC5936]) 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 [RFC8976]. 3.1.8. 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. 3.1.9. Abuse Resistance Authoritative servers for the BANDAID External Zone SHOULD implement DNS Cookies [RFC7873][RFC9018] 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. 3.1.10. BANDAID Records All BANDAID-specific discovery records (e.g., SRV [RFC2782], SVCB/ HTTPS [RFC9460], TXT/URI [RFC7553] 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 [RFC6698][RFC7671]. Resolver behavior consuming BANDAID data MUST treat DNSSEC-bogus responses as failures and MUST NOT act on unsigned or invalidly signed discovery Mozley, et al. Expires 19 April 2026 [Page 22] Internet-Draft BANDAID October 2025 data. 3.1.11. 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 [RFC9460]. 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) [RFC6891] and TCP fallback [RFC7766]. 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 [RFC2308]. 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 [RFC9460]. 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 Mozley, et al. Expires 19 April 2026 [Page 23] Internet-Draft BANDAID October 2025 ; Optional alias for a friendlier owner name billing._mcp._bandaid.example.org. 300 IN SVCB 0 a4k2f9._mcp._bandaid.example.org. ``` 3.1.12. Customization(s) BANDAID deployments MAY define additional SVCB parameters (SvcParamKeys) to convey agent-specific capability metadata, provided that interoperability safeguards in [RFC9460] 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 [RFC9460] 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. Mozley, et al. Expires 19 April 2026 [Page 24] Internet-Draft BANDAID October 2025 4. Implementation Guidance 4.1. AI Operators 4.1.1. 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. 4.1.2. Local Root Zone Copy Recursive resolvers serving BANDAID traffic SHOULD maintain a local copy of the root zone as specified in [RFC8806]. 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. 4.1.3. 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 [RFC8198]. 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 [RFC8767]. 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. [RFC8767] 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. Mozley, et al. Expires 19 April 2026 [Page 25] Internet-Draft BANDAID October 2025 Resolvers implementing serve-stale SHOULD follow the timer guidance in [RFC8767]: 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 [RFC2308] 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. 4.1.4. EDNS(0) Transport Resilience All servers MUST support EDNS(0) [RFC6891] and TCP fallback [RFC7766] 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.\ 4.1.5. 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. 4.1.6. 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 Mozley, et al. Expires 19 April 2026 [Page 26] Internet-Draft BANDAID October 2025 troubleshooting and compliance audits. 4.1.7. 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 [RFC9462], 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 [RFC9463] take precedence over unsolicited redirection unless local policy dictates otherwise. EDSR is currently an Internet-Draft and is referenced as an OPTIONAL extension. 4.2. AI Consumers 4.2.1. DNS-Based Service Discovery DNS-Based Service Discovery AI clients that consume BANDAID discovery data MUST implement DNS-based service discovery consistent with [RFC6763] and [RFC9460]. 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 [RFC2308]. 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. 4.2.2. 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. Mozley, et al. Expires 19 April 2026 [Page 27] Internet-Draft BANDAID October 2025 4.2.3. 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. 4.3. AI Developers 4.3.1. 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. [RFC9460] 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 [RFC9460] to ensure interop and correct fallback. 4.3.2. 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 [RFC2308], so publishers SHOULD avoid unnecessary NXDOMAIN flaps during deployments (e.g., prefer blue/green leaves over in-place deletions). Mozley, et al. Expires 19 April 2026 [Page 28] Internet-Draft BANDAID October 2025 4.3.3. 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 [RFC7671] [RFC8446] [RFC6698] 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 [RFC9460] for the ech parameter. 4.3.4. 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 4.3.5. 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). ; - Mozley, et al. Expires 19 April 2026 [Page 29] Internet-Draft BANDAID October 2025 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: _._tcp. ; 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 ) Mozley, et al. Expires 19 April 2026 [Page 30] Internet-Draft BANDAID October 2025 ; ------------------------------------------------------------------- --- ; (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 ``` 4.3.5.1. 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 [RFC2308]. * Follow SVCB/HTTPS semantics. Clients must honor SvcPriority, AliasMode (priority 0), and ServiceMode parameters, including mandatory, alpn, port, and address hints per [RFC9460]. * 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 [RFC8555]). 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 [RFC7671] (TLSA record format in [RFC6698]). * 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 [RFC4033], [RFC4034], [RFC4035] and operational guidance. 4.3.5.2. 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 [RFC8555] that fits BANDAID authorization workflows. Mozley, et al. Expires 19 April 2026 [Page 31] Internet-Draft BANDAID October 2025 * DANE TLSA optionally removes reliance on external PKI anchors for endpoint auth where DNSSEC is deployed [RFC6698], with deployment rules in [RFC7671]. 5. 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. 5.1. 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. Mozley, et al. Expires 19 April 2026 [Page 32] Internet-Draft BANDAID October 2025 6. Security Considerations To add: Lookalikes, takedowns, misbehaving agents, compliance, privacy 7. IANA Considerations IANA are to consider registering an underscored attribute leaf as part of [RFC8552] 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.) 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [I-D.draft-mozley-aidiscovery] Mozley, J., Williams, N., Sarikaya, B., and R. Schott, "AI Agent Discovery (AID) Problem Statement", Work in Progress, Internet-Draft, draft-mozley-aidiscovery-00, 15 October 2025, . [I-D.draft-rosenberg-ai-protocols] Rosenberg, J. and C. F. Jennings, "Framework, Use Cases and Requirements for AI Agent Protocols", Work in Progress, Internet-Draft, draft-rosenberg-ai-protocols-00, 5 May 2025, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . Mozley, et al. Expires 19 April 2026 [Page 33] Internet-Draft BANDAID October 2025 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, August 1996, . [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, . [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, . [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, DOI 10.17487/RFC4509, May 2006, . [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, . [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, . Mozley, et al. Expires 19 April 2026 [Page 34] Internet-Draft BANDAID October 2025 [RFC6605] Hoffman, P. and W.C.A. Wijngaards, "Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC", RFC 6605, DOI 10.17487/RFC6605, April 2012, . [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012, . [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 10.17487/RFC7344, September 2014, . [RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource Identifier (URI) DNS Resource Record", RFC 7553, DOI 10.17487/RFC7553, June 2015, . [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015, . [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, . [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, . Mozley, et al. Expires 19 April 2026 [Page 35] Internet-Draft BANDAID October 2025 [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from the Parent via CDS/CDNSKEY", RFC 8078, DOI 10.17487/RFC8078, March 2017, . [RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC", RFC 8080, DOI 10.17487/RFC8080, February 2017, . [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, July 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, . [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, . [RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation Requirements and Usage Guidance for DNSSEC", RFC 8624, DOI 10.17487/RFC8624, June 2019, . [RFC8767] Lawrence, D., Kumari, W., and P. Sood, "Serving Stale Data to Improve DNS Resiliency", RFC 8767, DOI 10.17487/RFC8767, March 2020, . [RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020, . [RFC8976] Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W. Hardaker, "Message Digest for DNS Zones", RFC 8976, DOI 10.17487/RFC8976, February 2021, . Mozley, et al. Expires 19 April 2026 [Page 36] Internet-Draft BANDAID October 2025 [RFC9018] Sury, O., Toorop, W., Eastlake 3rd, D., and M. Andrews, "Interoperable Domain Name System (DNS) Server Cookies", RFC 9018, DOI 10.17487/RFC9018, April 2021, . [RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, . [RFC9462] Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. Jensen, "Discovery of Designated Resolvers", RFC 9462, DOI 10.17487/RFC9462, November 2023, . [RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N., and T. Jensen, "DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)", RFC 9463, DOI 10.17487/RFC9463, November 2023, . Acknowledgments The authors thank Ross Gibson for his contributions, questions and comments. Authors' Addresses Jim Mozley Infoblox, Inc. Email: jmozley@infoblox.com Nic Williams Infoblox, Inc. Email: nic@infoblox.com Behcet Sarikaya Unaffiliated Email: sarikaya@ieee.org Roland Schott Deutsche Telecom Email: roland.schott@telekom.de Mozley, et al. Expires 19 April 2026 [Page 37]