



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



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,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

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, <https://datatracker.ietf.org/doc/html/
              draft-mozley-aidiscovery-00>.

   [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, <https://datatracker.ietf.org/doc/html/draft-
              rosenberg-ai-protocols-00>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.




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, <https://www.rfc-editor.org/rfc/rfc1996>.

   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
              NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
              <https://www.rfc-editor.org/rfc/rfc2308>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc2782>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc2845>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <https://www.rfc-editor.org/rfc/rfc4033>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc4034>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc4035>.

   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
              (DS) Resource Records (RRs)", RFC 4509,
              DOI 10.17487/RFC4509, May 2006,
              <https://www.rfc-editor.org/rfc/rfc4509>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc5155>.

   [RFC5936]  Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
              (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
              <https://www.rfc-editor.org/rfc/rfc5936>.





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,
              <https://www.rfc-editor.org/rfc/rfc6605>.

   [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, <https://www.rfc-editor.org/rfc/rfc6698>.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <https://www.rfc-editor.org/rfc/rfc6763>.

   [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
              Operational Practices, Version 2", RFC 6781,
              DOI 10.17487/RFC6781, December 2012,
              <https://www.rfc-editor.org/rfc/rfc6781>.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891,
              DOI 10.17487/RFC6891, April 2013,
              <https://www.rfc-editor.org/rfc/rfc6891>.

   [RFC7344]  Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
              DNSSEC Delegation Trust Maintenance", RFC 7344,
              DOI 10.17487/RFC7344, September 2014,
              <https://www.rfc-editor.org/rfc/rfc7344>.

   [RFC7553]  Faltstrom, P. and O. Kolkman, "The Uniform Resource
              Identifier (URI) DNS Resource Record", RFC 7553,
              DOI 10.17487/RFC7553, June 2015,
              <https://www.rfc-editor.org/rfc/rfc7553>.

   [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, <https://www.rfc-editor.org/rfc/rfc7671>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc7766>.

   [RFC7873]  Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
              Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
              <https://www.rfc-editor.org/rfc/rfc7873>.




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,
              <https://www.rfc-editor.org/rfc/rfc8078>.

   [RFC8080]  Sury, O. and R. Edmonds, "Edwards-Curve Digital Security
              Algorithm (EdDSA) for DNSSEC", RFC 8080,
              DOI 10.17487/RFC8080, February 2017,
              <https://www.rfc-editor.org/rfc/rfc8080>.

   [RFC8198]  Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
              DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
              July 2017, <https://www.rfc-editor.org/rfc/rfc8198>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/rfc/rfc8446>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc8552>.

   [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
              Kasten, "Automatic Certificate Management Environment
              (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
              <https://www.rfc-editor.org/rfc/rfc8555>.

   [RFC8624]  Wouters, P. and O. Sury, "Algorithm Implementation
              Requirements and Usage Guidance for DNSSEC", RFC 8624,
              DOI 10.17487/RFC8624, June 2019,
              <https://www.rfc-editor.org/rfc/rfc8624>.

   [RFC8767]  Lawrence, D., Kumari, W., and P. Sood, "Serving Stale Data
              to Improve DNS Resiliency", RFC 8767,
              DOI 10.17487/RFC8767, March 2020,
              <https://www.rfc-editor.org/rfc/rfc8767>.

   [RFC8806]  Kumari, W. and P. Hoffman, "Running a Root Server Local to
              a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020,
              <https://www.rfc-editor.org/rfc/rfc8806>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc8976>.





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,
              <https://www.rfc-editor.org/rfc/rfc9018>.

   [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
              and Parameter Specification via the DNS (SVCB and HTTPS
              Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
              November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc9462>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc9463>.

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]
