| Internet-Draft | A Framework for Agent Discovery in DAWN | October 2026 |
| Zhang, et al. | Expires 22 April 2027 | [Page] |
This document describes a two-layer reference architecture for discovering the minimum public information needed to reach AI agents. The Local Discovery Plane obtains discovery information within an administrative domain through mDNS/DNS-SD or infrastructure-assisted discovery. The Federation Plane uses DNS as its baseline for cross-domain discovery: Federation Gateways apply export policy, publish permitted information in independently administered DNS zones, and retrieve, validate, and cache remote information on demand. The framework also provides non-DNS mechanisms and mixed-mode deployments on the Federation Plane which can complement the baseline with proactive distribution, recipient-specific sharing, and directory lookup.¶
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 22 April 2027.¶
Copyright (c) 2026 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.¶
The IETF DAWN working group [I-D.akhavain-moussa-dawn-problem-statement] is chartered to enable a client to discover the minimum public discovery information about AI resources before interacting with them, covering the local network, an organization, and cooperating parties with trust relationships over the public Internet. Its problem statement identifies that no single existing mechanism satisfies all discovery scenarios, particularly when crossing trust and administrative boundaries [I-D.moussa-dawn-gap-analysis]. DAWN requirements [I-D.king-dawn-requirements] and use cases [I-D.kay-dawn-use-cases] scope discovery to obtaining the minimum public discovery information needed to reach and communicate with a resource: type, reachability information, communication protocol, and services.¶
A growing number of individual submissions propose concrete mechanisms within this space: DNS-based naming extensions (DNS-AID [I-D.mozleywilliams-dnsop-dnsaid], DN-ANR [I-D.cui-dns-native-agent-naming-resolution]); DNS-like hierarchical architectures (Agent Root, Agent Registry, Agent Resolver [I-D.yao-dawn-agent-discovery-architect]); mDNS/DNS-SD-based two-phase discovery [I-D.jakab-dawn-agent-discovery-mdns]; host-level self-description (A2A Agent Cards, ACAP [I-D.zahed-acap], ANP agent-descriptions, api-catalog [RFC9727]); and registry protocols (Agent Directory [I-D.jimenez-agent-directory], AGNTCY ADS [I-D.mp-agntcy-ads]). A survey by Jimenez et al. [I-D.jimenez-dawn-discovery-landscape] compares these mechanisms and identifies gaps, including the lack of interoperable federation across administrative boundaries.¶
Cui [I-D.cui-dawn-mdi-model] proposes an encoding-neutral information model for Minimum Discoverable Information (MDI) -- a common header that any discovery response may carry, independent of transport or format. MDI defines three mandatory elements (Entity Identifier, Entity Type, Endpoint) and a short set of recommended elements (Capability Summary, Authentication Hint, Trust Reference, Freshness).¶
This document complements the above work by defining a two-layer reference architecture for initial discovery across administrative boundaries. The Federation Gateway (FGW) connects local discovery to DNS publication and resolution. Its Export Policy Engine selects the minimum information that may leave the site. A Federation Metadata Record (FMR) represents that information, while the Federated Agent Directory (FAD) caches accepted results on demand. Discovery may continue through a referral to another discovery endpoint.¶
DNS and mDNS provide the baseline discovery mechanisms. Each site publishes permitted information in its authoritative DNS zone; remote sites resolve, validate, and cache the information when needed. This document reuses existing IETF protocols for publication, communication, and security. Non-DNS mechanisms and mixed-mode deployments may complement the DNS baseline by supporting proactive distribution, recipient-specific sharing, and directory lookup.¶
This document defines a two-layer reference architecture for discovering the minimum public information needed to reach AI resources within a local network, an organization, or cooperating administrative domains. DNS and mDNS provide the baseline mechanisms. Non-DNS mechanisms and mixed-mode deployments may complement the baseline by supporting proactive distribution, recipient-specific sharing, and directory lookup. Discovery returns an endpoint, communication protocol, and any applicable reference needed to continue discovery.¶
The following items are explicitly out of scope for this informational document, consistent with the DAWN charter:¶
Normative protocol message formats, encodings, or state machines. These are addressed in separate protocol specifications that may be developed based on this architecture.¶
Mandatory cryptographic algorithms or cipher suites. The architecture requires transport security and metadata integrity, but specific algorithm selection is deferred to protocol documents.¶
A global root trust authority or certificate hierarchy. The architecture supports federation-local trust models, consistent with DAWN's initial scope [CSA-DAWN-Note].¶
Exchange of capability information beyond the minimum public discovery information; in particular, catalogs of capabilities are out of scope. The FMR carries only the minimum public discovery information (type, reachability, communication protocol, services).¶
All communication beyond the initial discovery process, including any interaction, invocation, or selection that follows discovery.¶
Open-ended search, semantic matchmaking, ranking, or the selection of an AI resource based on capabilities or user intent.¶
Identity management of AI agents, tools, and skills.¶
Trust management and trust evaluation methods beyond secure content exchange between DAWN parties. The architecture provides integrity for exchanged discovery information but does not define a general trust framework.¶
Agent runtime execution, task scheduling, or inter-agent communication protocols beyond discovery.¶
Business-level service level agreements or commercial federation governance rules.¶
Open-Internet-scale agent indexing -- the "AI resource indexing across the wider Internet" case excluded by the DAWN charter -- is out of scope. Trusted directory publication (Section 7.2.3) is limited to publication to trusted or semi-public directories under explicit operator policy, and does not constitute open-Internet indexing.¶
Section 2 defines terminology, aligned with DAWN [I-D.farrel-dawn-terminology]. Section 3 states architectural requirements and maps them to DAWN requirements. Section 4 positions this architecture relative to existing DAWN family protocols. Section 5 provides a state-of-the-art review and gap analysis. Section 6 presents the two-layer reference architecture, federation workflow, and functional components. Section 7 describes DNS-based deployment and compares additional mechanisms. Section 8 identifies existing security mechanisms and disclosure boundaries. Section 9 covers resilience, publication updates, and caching.¶
This document uses terms defined in [I-D.farrel-dawn-terminology], including Entity, Discovery, Discovery Information, Discoverable Object, Minimum Discoverable Information (MDI), Capability Card, and Trust Indicator. The following additional terms are defined for the purpose of this architecture:¶
Agent: An autonomous network-resident entity that can execute tasks, expose service interfaces, and advertise capability metadata. Aligns with the DAWN definition of Entity when the entity type is "agent".¶
Administrative Domain: A network or set of networks under a single organizational authority, with its own security and operational policies. Equivalent to the DAWN scope concept.¶
Federation Metadata Record (FMR): A lightweight, sanitized descriptive record of an AI resource, exchanged among Federation Gateways in the Federation Plane. An FMR carries the minimum public discovery information for cross-domain transport, including Entity Identifier, Entity Type, reachability/locator, communication protocol, services, status, and time-to-live. This information MAY be represented using the DAWN Minimum Discoverable Information (MDI) model [I-D.cui-dawn-mdi-model] or derived from resource information supplied through the Resource Publication Hook [I-D.dunbar-dawn-infra-assisted-discovery].¶
Capability Card: A fuller description of an agent's capabilities. Exchange of capability information beyond the minimum public discovery information is out of scope for DAWN's initial phase (see Section 1.2); this architecture does not distribute or retrieve Capability Cards as part of discovery. ACAP's Agent Capability Document (ACD) [I-D.zahed-acap] and A2A Agent Cards are examples of such fuller descriptions.¶
Site / Local Domain: An independent administrative area, typically one local-area network or a single tenant namespace, where agents run.¶
Federation Gateway (FGW): A functional component that obtains local agent discovery information, applies export policy, and arranges publication of permitted information in the domain's authoritative DNS service. For cross-domain requests, it obtains remote discovery information through DNS resolution, validates the results, and caches accepted information. DNS publication and resolution services MAY operate separately from the FGW.¶
Federation: A trust group formed by multiple federation gateways from different administrative domains, for exchanging agent discovery metadata.¶
Federation Peer: The DNS-based baseline for the Federation Plane. Each domain publishes permitted discovery information in its authoritative DNS zone. A requesting FGW resolves and validates that information when no valid matching FAD entry exists, then caches accepted results for their remaining permitted lifetime. This model does not require persistent FGW-to-FGW sessions or complete replication of remote records. Deployment considerations are described in Section 7.1.¶
Non-DNS Synchronization Mode: The alternative realization of the Federation Plane when the DNS delegation model does not meet operational requirements. This mode offers three synchronization mechanisms, selected according to the number and scale of participating organizations and the deployment scenario: BGP-like structured peering, gossip-based epidemic dissemination, and trusted directory publication.¶
Minimum Public Discovery Information: The set of public properties a client needs before interacting with an AI resource: its type, reachability information, communication protocol, and services. This information MAY be represented using the DAWN MDI model [I-D.cui-dawn-mdi-model] and MAY be obtained through agent advertisement or the Resource Publication Hook [I-D.dunbar-dawn-infra-assisted-discovery]. An FMR carries this information together with the identifier, status, and time-to-live described in its definition; capability information beyond this minimum remains out of scope.¶
Iterative Discovery / Referral: A discovery process in which a returned record refers the client to a catalog or to another discovery endpoint (referral, delegation, or indirection), continuing until the client obtains the minimum public discovery information it needs.¶
Federated Agent Directory (FAD): The discovery-information store maintained by an FGW. Remote discovery information is obtained on demand and cached after validation. Cached information is retained only for its remaining permitted lifetime. Locally originated discovery information MAY be maintained within the same store or separately.¶
Export Policy Engine: A functional module on the FGW that filters, redacts, and controls which agent metadata may be shared with which federation peers. This is the core mechanism for data sovereignty.¶
Local Discovery Plane: The first architectural layer, operating within a single site, responsible for collecting and maintaining lightweight agent discovery information. It supports two complementary modes: LAN-Based Discovery and Infrastructure-Assisted Discovery (IAD). The modes MAY coexist within the same administrative domain, and the architecture does not mandate a specific local discovery protocol.¶
LAN-Based Discovery: A local discovery mode in which an agent or an authorized entity advertises lightweight agent discovery information through a site-local mechanism, such as link-local multicast mDNS/DNS-SD. Local peers and discovery components obtain the advertised information through that mechanism.¶
Infrastructure-Assisted Discovery (IAD): An infrastructure-assisted approach to discovery described in [I-D.dunbar-dawn-infra-assisted-discovery]. In this architecture, IAD provides deployment-maintained agent discovery information to the FGW, primarily for organization-level discovery in managed environments.¶
Local Infrastructure Gateway: An authorized orchestration, placement, hosting, or management system that collects and maintains discovery information on behalf of agents deployed within a managed organizational environment. It MAY be implemented separately from, or integrated with, the FGW. When implemented separately, it advertises the collected agent discovery information to the FGW and provides updates as deployment state changes. When integrated, the FGW primarily obtains agent discovery information from registration records maintained within the managed infrastructure. Its local discovery role does not itself imply participation in cross-domain federation.¶
Resource Publication Hook: The infrastructure-assisted mechanism described in [I-D.dunbar-dawn-infra-assisted-discovery] through which deployment infrastructure supplies resource discovery information for local registration and maintenance. In this architecture, the FGW MAY use the supplied information to construct FMRs after applying export policy.¶
Attachment Context Hook: An infrastructure integration point through which trusted network infrastructure provides the requester's current Attachment Scope to the discovery mechanism, as described in [I-D.dunbar-dawn-infra-assisted-discovery]. This context complements published resource information when identifying applicable discovery domains and reachable agent endpoints. Its detailed realization is outside the scope of this document.¶
Federation Plane: The second architectural layer, operating across administrative domains, responsible for FMR exchange among FGWs.¶
This section defines high-level architectural requirements for the two-layer agent-discovery architecture. These requirements are derived from the DAWN working group's problem statement [I-D.akhavain-moussa-dawn-problem-statement], requirements [I-D.king-dawn-requirements], and use cases [I-D.kay-dawn-use-cases]. They are non-normative for this informational document.¶
F-1: Cross-Domain Discovery -- The architecture MUST enable discovery of the minimum public discovery information about resources that reside in administrative domains different from the requester's domain, i.e., between cooperating parties with trust relationships over the public Internet. Satisfies DAWN use case "Administrative Scope Extensions" [I-D.kay-dawn-use-cases].¶
F-2: Zero-Configuration Local Discovery -- Agents MUST be capable of advertising themselves on the local network without pre-provisioned discovery server addresses. Satisfies DAWN requirements for local-context discovery [I-D.king-dawn-requirements].¶
F-3: Data Sovereignty -- Each site administrator MUST retain full control over which agent metadata records can be shared outside its local domain, including per-record filtering, field redaction, and per-peer access policy. Addresses the gap identified in [I-D.moussa-dawn-gap-analysis] regarding lack of interoperable federation with per-domain policy control.¶
F-4: Decentralized Federation -- The architecture MUST NOT require a mandatory global centralized directory. Federation participants MUST be able to operate without submitting data to a third-party central authority. Aligns with DAWN's emphasis on avoiding single points of failure [I-D.king-dawn-requirements].¶
F-5: Minimum Public Discovery Information Only -- The architecture MUST exchange only the minimum public discovery information (type, reachability, communication protocol, services) in the federation plane, and MUST NOT distribute or retrieve capability information beyond this minimum. This instantiates the DAWN MDI principle of a thin, encoding-neutral record [I-D.cui-dawn-mdi-model].¶
F-6: Dynamic Agent Lifecycle -- The architecture MUST support changes in agent availability, deployment state, reachable endpoints, and export permission. After detecting a relevant change, the responsible publisher MUST promptly update or remove the affected authoritative DNS records. Previously cached copies remain subject to their established validity limits. These procedures support dynamic updates and freshness [I-D.king-dawn-requirements].¶
F-7: DNS-Based Federation -- The architecture MUST support independently administered DNS publication and request-driven retrieval. A requesting FGW checks for a valid matching cached result before resolving remote discovery information. Accepted results retain their provenance, applicable disclosure conditions, and remaining permitted lifetime.¶
F-8: Iterative Discovery and Referral -- The architecture MUST support iterative discovery in which a returned record may refer the client to a catalog or to another discovery endpoint (referral, delegation, or indirection). The AI resource to be discovered may itself be a catalog or service that furthers the discovery process.¶
F-9: Integrity of Discovery Information -- The architecture MUST provide integrity for all discovery information exchanged between DAWN parties, allowing a recipient to detect alteration of, or unauthorized injection into, the exchanged records.¶
NF-1: Security Against Forged Advertisements -- The architecture MUST provide a mechanism to verify the origin and integrity of FMRs, preventing malicious federation participants from injecting forged agent advertisements.¶
NF-2: Fault Tolerance -- The architecture MUST tolerate individual gateway failures, network partitions, and transient connectivity loss without catastrophic loss of discovery capability.¶
NF-3: Interoperability -- The architecture reuses existing DNS/mDNS procedures and the information models and bindings defined by the applicable discovery specifications. Additional mechanisms follow their own existing specifications and preserve the publication, validation, and validity conditions of the information they handle. Interoperability does not require a new common federation wire format or gateway session protocol.¶
NF-4: Privacy Protection -- The architecture MUST prevent leakage of internal network topology, private IP addresses, and sensitive agent details to unauthorized external parties. Satisfies DAWN privacy considerations [I-D.king-dawn-requirements].¶
NF-5: Scalability -- The architecture MUST scale from small federations of a few sites to large federations of hundreds or thousands of sites, without requiring per-site full-mesh manual configuration.¶
NF-6: Operational Simplicity -- The architecture MUST minimize operational overhead for site administrators, particularly for local-site deployment where zero-configuration is a primary goal.¶
This architecture is designed to complement, not replace, existing protocols being discussed in the DAWN community and adjacent efforts. The following positioning statements clarify the relationship.¶
ACAP [I-D.zahed-acap] defines a well-known URI scheme, a rich Agent Capability Document (ACD) format, and HTTP/3 operations (GET, PUT, POST) for retrieval, registration, and search within a site. ACAP operates primarily at the Description Plane: it specifies how a host publishes its capabilities and how a domain-level query endpoint answers discovery queries.¶
This architecture treats ACAP as a valid implementation of the Description Plane within a site. An FGW may collect ACDs via ACAP PUT/GET from local agents, extract the minimum public discovery information (type, reachability, communication protocol, services) into an FMR, and distribute the FMR in the Federation Plane; the richer capability content of the ACD is not carried in the FMR, consistent with the charter. Cross-domain discovery queries may be answered from valid FAD entries. In DNS-based discovery, a cache miss triggers a DNS query for the remote domain, followed by validation and caching of the result. A global ACAP query endpoint is not required. Thus, ACAP and this architecture are composable: ACAP handles intra-domain description, while this architecture handles inter-domain federation and export policy.¶
The Agent Directory [I-D.jimenez-agent-directory] adapts the CoRE Resource Directory [RFC9176] to software agents, providing an HTTP/JSON service for registration and lookup with soft-state lifetimes. It defines a well-known URI (/.well-known/ad) and supports capability filtering.¶
This architecture is complementary: the Agent Directory may serve as the Local Discovery Plane mechanism within a site, collecting agent registrations and answering local queries. The FGW may subscribe to the local Agent Directory, extract MDI-compliant records, apply export policy, and generate FMRs for federation. The FAD maintained by the FGW is conceptually a distributed extension of the Agent Directory across administrative boundaries. Federation across multiple Agent Directory instances is acknowledged but not specified in [I-D.jimenez-agent-directory]; this architecture provides one possible federation model.¶
AGNTCY ADS [I-D.mp-agntcy-ads] is a distributed directory using libp2p Kad-DHT for content routing and a hierarchical skill taxonomy. It supports open, Internet-scale discovery, which is outside DAWN's initial scope.¶
This architecture differs in approach: ADS is a global or wide-area distributed hash table, while this architecture is a federated gateway model with explicit per-peer trust and policy control. ADS targets open, Internet-scale discovery, which is excluded by the DAWN charter; this architecture targets closed or semi-closed federations where data sovereignty and per-peer export policy are paramount. A hybrid deployment is possible: an FGW may publish a subset of its FMRs to a trusted directory such as AGNTCY ADS for broader discoverability, while retaining sensitive records for private federation peers only (see trusted directory publication, Section 7.2.3).¶
DNS-AID [I-D.mozleywilliams-dnsop-dnsaid] and DN-ANR [I-D.cui-dns-native-agent-naming-resolution] propose DNS-based mechanisms for agent naming and location resolution. These operate at the DAWN Naming Plane, providing decentralized name-to-location mapping.¶
This architecture treats DNS-based discovery as one valid mechanism for the Local Discovery Plane (e.g., resolving a known partner's domain to locate its FGW or agents). The FGW may itself be advertised via DNS records, and FMRs may contain DNS-based locators. The two approaches are orthogonal and composable.¶
The MDI information model [I-D.cui-dawn-mdi-model] defines an abstract, encoding-neutral common header for discovery responses. This architecture directly adopts MDI as the basis for FMRs: an FMR is a concrete, protocol-specific binding of MDI elements (Entity Identifier, Entity Type, Endpoint, Capability Summary, Freshness, Provenance) for the purpose of cross-gateway exchange. By grounding FMRs in MDI, this architecture ensures that federated metadata can be translated to and from other DAWN discovery formats (ACAP ACDs, Agent Directory records, A2A Agent Cards) without loss of the minimal necessary information.¶
The FMR is a thin, cacheable index by design: Entity Summary and Operational Hint stay with the Capability Card and the Record-Flag/TTL mechanism respectively, and Extension is realized by reserved and unknown TLV types, which recipients MUST ignore. Two FMR fields (Origin-GW-ID, Record-Flag) are binding-level mechanism fields and are not MDI elements. The FMR binding does not relax any MDI constraint: one FMR describes exactly one entity; Entity Identifiers are compared within the publisher scope established by Origin-GW-ID; protocols attach to the Endpoint; and recipients MUST ignore unrecognized extensions. The concrete TLV encoding of the FMR is left to the synchronization protocol specifications that may be developed based on this architecture.¶
This section reviews existing approaches to cross-domain service and agent discovery, and identifies gaps that motivate the proposed two-layer architecture. It extends the gap analysis in [I-D.moussa-dawn-gap-analysis] and [I-D.jimenez-dawn-discovery-landscape].¶
One approach is to deploy a hierarchical, DNS-like or WebFinger-like global registration system. Sites register their agent metadata with regional or global directory servers; requesters query the directory to discover agents.¶
Strengths: Familiar operational model; query latency is controllable; well-understood caching and delegation mechanisms.¶
Gaps: (1) Data sovereignty -- sites must submit agent metadata to a third-party directory, which many organizations resist for industrial and enterprise deployments. (2) Trust and governance -- operating a global root directory requires a governance body that all participants accept. (3) Single-point-of-failure and scaling concerns at the root level. (4) Granular per-peer access control is difficult in a public query model. These gaps are noted in [I-D.moussa-dawn-gap-analysis] as "no interoperable federation" across administrative boundaries.¶
mDNS/DNS-SD [RFC6762] [RFC6763] provides excellent zero-configuration discovery within a single broadcast domain.¶
Strengths: Zero configuration; widely deployed; no infrastructure required; excellent for local-area networks.¶
Gaps: (1) Link-local multicast does not cross IP routers, so discovery is confined to a single LAN. (2) No built-in mechanism for cross-domain metadata exchange. (3) Large LANs can experience multicast storm issues without a proxy or gateway. This satisfies only the "local context" use case [I-D.kay-dawn-use-cases].¶
In this approach, every gateway establishes direct peering sessions with every other gateway in the federation, exchanging metadata via incremental updates (similar to BGP [RFC4271]).¶
Strengths: Fast convergence; fine-grained per-peer policy control; clear data sovereignty; well-understood operational model from routing protocols.¶
Gaps: (1) Full-mesh configuration becomes operationally expensive at large scale (N-squared peering). (2) Every site must manually configure and maintain peer relationships. (3) Not ideal for loosely-managed, open federations with high member churn.¶
Gossip-based protocols propagate metadata probabilistically among a small set of neighbors, achieving eventual consistency across the federation.¶
Strengths: Excellent horizontal scalability; robust against partial failures; low per-node connection count; self-organizing topology.¶
Gaps: (1) Eventual consistency means convergence delay is unavoidable. (2) Precise per-record distribution policies are difficult to enforce. (3) Malicious participants can rapidly spread forged metadata across the overlay. (4) Security and trust management are more complex than in static peering models.¶
No single existing approach satisfies all requirements simultaneously:¶
Centralized directories fail F-3 (data sovereignty) and F-4 (decentralized federation).¶
Link-local multicast fails F-1 (cross-domain discovery).¶
Full-mesh peering fails NF-5 (scalability) at large federation sizes.¶
Gossip dissemination fails NF-1 (security against forged advertisements) and F-6 (prompt lifecycle invalidation) due to convergence delay.¶
The two-layer federated architecture addresses these gaps by: (1) keeping local discovery zero-configuration and decentralized, without mandating a specific local protocol; (2) introducing a federation gateway layer that enforces data sovereignty via export policy; (3) supporting two top-level federation modes -- with DNS delegation between authoritative zones as the preferred realization for inter-organizational interaction, and non-DNS synchronization (BGP-like peering, gossip-based dissemination, and trusted directory publication) as alternatives selected according to scale and scenario -- so that deployments can select the mode matching their scale and trust model; and (4) exchanging only the minimum public discovery information in FMRs to reduce cross-domain data exposure.¶
As illustrated in the following figure, the architecture consists of the Local Discovery Plane (Layer 1) and the Federation Plane (Layer 2). The FGW connects local discovery information to policy-controlled DNS publication and request-driven resolution. Existing DNS publication and resolver functions may be deployed separately. Agent communication is independent of the discovery metadata path.¶
Domain A Domain B
+----------------------+ +----------------------+
| Agents / AI resources| | Agents / AI resources|
+----------------------+ +----------------------+
| | | |
v v v v
+---------+ +----------+ +---------+ +----------+
|LAN-based| |Infra- | |LAN-based| |Infra- |
|discovery| |assisted | |discovery| |assisted |
| | |discovery | | | |discovery |
+---------+ +----------+ +---------+ +----------+
| | | |
+-----+-----+ +-----+-----+
| |
v v
+----------------------+ +----------------------+
| Federation Gateway A | | Federation Gateway B |
| | | |
| Export Policy Engine | | Export Policy Engine |
| | | | | |
| v | | v |
| Construct local FMRs | | Construct local FMRs |
| | | |
| FAD | | FAD |
| On-demand DNS cache | | On-demand DNS cache |
| Validated results | | Validated results |
+----------------------+ +----------------------+
| |
| Layer 1: Local Discovery Plane |
-----------|--------------------------------|------------
| Layer 2: Federation Plane |
v v
+--------------------------------------------------------+
| DNS baseline: authoritative publication |
| Request -> cache miss -> DNS query -> validate -> cache|
| |
| DNS service may be separate from the FGW |
| Remote FADs populate after discovery requests |
+--------------------------------------------------------+
Local discovery modes may coexist.
DNS services may be separate from FGWs.
Agent data traffic uses the discovered endpoints.
FGWs need not forward agent data traffic.
The first layer runs inside each independent local site (LAN, tenant namespace, or edge cluster). Its responsibilities are agent advertisement, local metadata collection, and export policy enforcement.¶
When an agent becomes available, its lightweight discovery information MAY be collected and maintained through two complementary modes within the Local Discovery Plane:¶
LAN-Based Discovery: In a local network, an agent MAY advertise its lightweight discovery information after startup through a site-local discovery mechanism, such as link-local multicast mDNS/DNS-SD (e.g., service type "_agent._tcp.local"). An authorized entity, such as an agent orchestration system or local gateway, MAY advertise this information on the agent's behalf. Other agents and local discovery components can obtain the advertised information through the same mechanism without requiring a preconfigured discovery server. Alternative mechanisms MAY also be used, including local API registration with an Agent Directory [I-D.jimenez-agent-directory], edge-platform-driven discovery (e.g., Kubernetes service discovery), or registration through ACAP [I-D.zahed-acap]. The architecture supports advertisement by either the agent or an authorized entity and does not mandate a specific local discovery protocol.¶
Infrastructure-Assisted Discovery: In managed organizational environments, the FGW MAY obtain agent discovery information from deployment infrastructure through the Resource Publication Hook described in [I-D.dunbar-dawn-infra-assisted-discovery]. The FGW uses this information to maintain its local discovery view and construct policy-filtered FMRs for DNS publication. Infrastructure-provided changes support updates or removal of the corresponding published information. This approach MAY coexist with LAN-based discovery.¶
Both modes provide lightweight discovery information to the Local Discovery Plane and MAY coexist within the same administrative domain. An infrastructure gateway performs local collection and registration functions and MAY be implemented separately from, or integrated with, the Federation Gateway (FGW). When implemented separately, the local infrastructure gateway advertises the collected agent discovery information to the FGW through a discovery mechanism and provides updates as deployment state changes. When integrated, the FGW obtains this information internally. In either deployment, the FGW obtains the locally collected discovery information and applies export policies before making it available through the Federation Plane. The architecture does not mandate either mode or a specific local discovery protocol.¶
Advertised records carry the minimum public discovery information (Entity Identifier, Entity Type, reachability/locator, communication protocol, services). No capability information beyond this minimum is transmitted via multicast or local broadcast packets.¶
Local peers (other agents) may discover and communicate directly within the site. The FGW is NOT required to forward agent data traffic; it only collects discovery metadata.¶
The FGW collects agent discovery information through LAN-based discovery, infrastructure-assisted discovery, or both. In LAN-based discovery, the FGW MAY listen to local mDNS/DNS-SD advertisements, subscribe to an Agent Directory, or retrieve information through ACAP. In infrastructure-assisted discovery, primarily used for organization-level agent discovery, the FGW receives agent discovery information advertised by a separate local infrastructure gateway or, when integrated with that gateway, primarily obtains the information from registration records maintained within the managed infrastructure. Advertisements and registration records are updated or withdrawn as deployment state changes.¶
The Export Policy Engine on the FGW applies local sharing policy: it filters which agents may be advertised externally, redacts sensitive fields, and generates federation-ready FMRs before exporting them to remote federation peers. Different peers may receive different subsets of FMRs.¶
Federation Gateways from separate administrative domains support cross-domain discovery. DNS publication and resolution form the baseline: each domain publishes permitted discovery information in its authoritative zone, and remote FGWs resolve and validate the records when needed. Publication does not populate remote FADs or require persistent FGW-to-FGW sessions. The additional features of non-DNS proposals are compared in Section 7.¶
Each FGW publishes only the sanitized discovery information permitted by its export policy. Publication makes records available in the originating domain's authoritative zone and does not push them into remote FADs.¶
When an agent's discovery information changes, its FGW or an authorized DNS controller updates or removes the corresponding authoritative records. Remote FADs are not proactively synchronized. A later request obtains information through DNS resolution when no valid matching cached result remains.¶
An FGW does not maintain a complete local copy of remote agent metadata by default. Its FAD contains accepted records previously retrieved in response to discovery requests and retained within their permitted cache lifetimes.¶
When a client requests cross-domain agent information, the local FGW first checks for a valid matching FAD cache entry. On a miss, it uses a validating resolver to query the remote domain, using a discovery name or a known domain and service type supplied or obtained by the application. It validates the response, applies import policy, caches accepted information, and returns the result. Later requests may reuse a valid entry. An explicit application-level referral may continue discovery at another endpoint.¶
Federation connects independently administered discovery domains while each domain controls the information it publishes. The originating FGW applies export policy and makes permitted FMRs available; the requesting FGW retrieves or receives eligible records according to the selected mode and applies validation and import policy. Publication in one domain does not by itself create a record in another domain's FAD.¶
In DNS-based discovery, the originating domain's authoritative DNS service holds the published agent discovery information. Remote records are not synchronized into other FGWs' FADs by default. The FAD serves as a request-driven cache rather than a replica of remote DNS zones.¶
The originating domain is responsible for the discovery information describing its local agents. Its FGW obtains that information through LAN-based or infrastructure-assisted discovery and applies export policy before constructing FMRs for external publication. The federation process operates on these FMRs independently of the local collection mechanism.¶
The receiving domain decides which external sources and records it accepts. Its FGW validates obtained FMRs and applies local import policy before making them available through its FAD. A federation relationship therefore combines the originating domain's permission to disclose information with the receiving domain's permission to accept and use that information.¶
Participating domains use existing DNS validation and deployment security policies. Discovering an endpoint does not authorize access to restricted metadata or the agent itself.¶
The Federation Plane uses DNS publication and on-demand resolution as its baseline. Each administrative domain controls its authoritative discovery information. Publication makes that information available for queries without pre-populating remote FADs or requiring persistent FGW-to-FGW sessions. The workflow consists of the following steps:¶
Identify the discovery domain: The requester supplies a discovery name or obtains the relevant domain through configuration, an existing discovery mechanism, or a referral. DNS delegation locates the authoritative source. DNS-SD [RFC6763] can browse service instances of a known type within a known domain.¶
Construct and publish an export view: The originating FGW applies its Export Policy Engine to local discovery information and selects the resources and fields permitted for disclosure. It publishes the corresponding FMR information through the domain's authoritative DNS service using the applicable discovery binding. Public DNS contains only information approved for public disclosure. The authoritative DNS service may operate separately from the FGW.¶
Receive a request and check the FAD: When a user requests cross-domain agent information, the local FGW checks its FAD for a valid matching entry. If that entry satisfies the request and applicable policy, the FGW may answer directly. Otherwise, the request triggers DNS resolution for the relevant discovery name or domain.¶
Resolve, validate, and cache: The requesting FGW uses a validating resolver to obtain the remote discovery records, applies DNSSEC validation [RFC4035] and local import policy, and caches accepted information in its FAD. The cache lifetime does not exceed the remaining DNS TTL or any shorter applicable validity limit. A recursive resolver may supply a previously cached response with its remaining TTL.¶
Return the discovery result: The FGW returns the accepted discovery information to the requester. The result provides an endpoint or an explicit referral for further discovery. Subsequent requests may reuse a valid matching FAD entry, but cache hits do not restart its lifetime. Agent access and communication use the discovered service's existing protocols and policies.¶
Maintain authoritative publication: Changes in agent availability, endpoints, communication protocols, or export policy cause the responsible publisher to update or remove the affected DNS records. An integrated FGW obtains infrastructure changes from existing registration records; a separate infrastructure gateway supplies the changes to the FGW. Publication uses existing mechanisms such as DNS UPDATE [RFC2136] with the applicable update security [RFC3007], or an authorized DNS management interface.¶
Authoritative updates do not immediately invalidate copies already cached by recursive resolvers or remote FADs. Those copies remain subject to their established expiration times. An expired FAD entry is no longer eligible for discovery responses, and a subsequent request triggers another lookup. DNS TTL limits cached copies rather than authoritative record lifetime; the publisher reconciles authoritative records with current deployment state to remove obsolete information.¶
Where detailed discovery information requires a different disclosure policy, DNS may publish only a pointer to an existing access-controlled discovery endpoint. The requester then uses that endpoint's established retrieval and security mechanisms. DNSSEC validation of the pointer does not validate the subsequently retrieved information or authorize access to the agent.¶
Each FAD represents the discovery information currently available and acceptable to its local domain, rather than a complete replica of all agent information in the federation. Its contents depend on local storage choices, export and import policies, the selected federation mechanisms, previous discovery requests, and record validity.¶
When a cross-domain request has no valid matching cached entry, the FGW retrieves the relevant information through DNS resolution, validates it, and caches the accepted result. The cache lifetime does not exceed the remaining DNS TTL or any shorter applicable validity limit. Cache hits do not restart that lifetime, and expired entries are no longer eligible for discovery responses.¶
Locally originated FMRs may be maintained within the FAD or in a separate store. A deployment may use additional directory or distribution sources. Cached entries retain their provenance, validity, and applicable disclosure conditions.¶
Once discovery provides a suitable agent endpoint, the requester communicates with that agent using the indicated communication protocol and the agent's access-control requirements. The FGWs support discovery and metadata federation; they are not required to forward agent business data traffic.¶
The FGW MAY use resource discovery information supplied through the Resource Publication Hook [I-D.dunbar-dawn-infra-assisted-discovery] to maintain its local discovery view and construct or update FMRs after applying export policy.¶
The FGW MAY use requester attachment context supplied through the Attachment Context Hook [I-D.dunbar-dawn-infra-assisted-discovery] to identify applicable discovery domains or reachable agent endpoints. Context-dependent cached results are reused only for requests satisfying the same applicability conditions.¶
Local Agent Discovery Module (on FGW): Captures local agent advertisements via passive mDNS listening, Agent Directory subscription, or other local mechanisms; maintains the site-local agent table.¶
Export Policy Engine (on FGW): Executes data filtering, privacy redaction, and per-peer export access policy. This is the core data sovereignty mechanism.¶
DNS Publication Service (on FGW): Arranges publication, updates, and removal of permitted discovery information in the domain's authoritative DNS service.¶
DNS Resolution and Validation Service (on FGW): Uses a validating resolver to obtain remote discovery information, applies DNSSEC validation and local import policy, and supplies accepted results to the FAD.¶
Discovery and Referral Response Service (on FGW): Checks for valid matching FAD entries, triggers DNS retrieval when necessary, and returns accepted discovery information or referrals.¶
Metadata Integrity Module (on FGW): Signs outgoing FMRs and verifies signatures on incoming FMRs, providing origin authentication and integrity protection.¶
FAD Aging Module (on FGW): Expires records according to their applicable validity rules. The cache lifetime does not exceed the remaining DNS TTL or any shorter applicable validity limit. Cache hits do not restart that lifetime; an expired entry requires fresh retrieval on a subsequent request.¶
DNS publication and on-demand resolution provide the baseline federation mechanism. The alternatives in this section address deployment requirements that are not directly provided by this baseline: recipient-specific exchange with explicit peer relationships, multi-hop dissemination and reconciliation among changing participants, or application-level queries across an aggregated collection of resources from multiple domains. These functions do not make DNS discovery obsolete; they complement it where authoritative publication and request-driven resolution alone do not meet operational or disclosure requirements. DNS extensions, including DNS Push Notifications [RFC8765], can provide change notifications and should be considered before introducing a separate synchronization mechanism.¶
Consider an industrial consortium in which several known operators share agent endpoints, but each partner is permitted to receive a different subset of records. Partners require an authenticated exchange relationship, an initial partner-specific view, and explicit incremental updates or withdrawals as resources or sharing permissions change. Publication in an authoritative DNS zone and request-driven resolution do not, by themselves, establish persistent partner relationships or deliver separately authorized export views to each recipient. DNS Push Notifications [RFC8765] can notify subscribers of record changes, but do not replace the partner-specific exchange and reconciliation policy required in this scenario. BGP-like structured peering is therefore an optional fit for tightly managed federations, such as industrial compute consortiums, multi-site enterprises, and operator-managed edge-agent networks, where participating organizations are known and membership changes infrequently.¶
Recommended synchronization: Structured peer-to-peer incremental unicast synchronization (full-mesh or partial-mesh peering), with delegation or referral between discovery domains where needed.¶
Rationale: Persistent, low-latency peering with fine-grained per-peer sharing policy and fast convergence; the mesh operational overhead is acceptable for medium-scale federations.¶
Scale range: Approximately 2 to 200 sites.¶
The discovery workflow proceeds as follows:¶
Establish an exchange relationship: An FGW obtains a peer endpoint through configuration or an existing discovery mechanism and establishes a connection using the selected exchange protocol and its existing security mechanisms.¶
Supply the initial export view: The originating FGW applies its Export Policy Engine and supplies the records permitted for that peer. The receiving FGW verifies their origin, integrity, and validity, applies import policy, and stores accepted records in its FAD.¶
Distribute incremental changes: Changes in local agent availability, endpoints, or export policy cause the originating FGW to send updates or withdrawals to the affected peers. Each receiving FGW replaces superseded records or removes withdrawn records according to the selected protocol.¶
Answer discovery requests: The receiving FGW uses eligible FAD records to answer local requests. A request for information not held locally may use DNS discovery or another authorized discovery source.¶
Recover after interruption: On reconnection, peers reconcile their permitted record sets using the selected protocol's snapshot or incremental recovery procedures. Connection failure alone does not establish that the advertised agents have stopped; retained records remain subject to their validity limits and local policy.¶
Consider a federation of cooperating edge sites in which participating sites frequently join, disconnect, or change their available agents. The deployment requires approved discovery records to propagate through a changing set of authorized intermediaries, including when individual participants cannot reliably query every originating domain. DNS publication and on-demand resolution can locate records when the authoritative path is reachable, but do not themselves provide a bounded-neighbor, multi-hop dissemination overlay with periodic reconciliation of permitted record sets. Gossip-based epidemic dissemination can provide that behavior without requiring every site to maintain a session with every other site. It is appropriate only where eventual consistency, delayed withdrawal propagation, and the additional relay-policy and integrity risks are acceptable; it is not a substitute for DNS when ordinary resolution is sufficient.¶
Recommended synchronization: Gossip-based epidemic dissemination, with a bounded neighbor set and periodic anti-entropy synchronization.¶
Rationale: Excellent horizontal scalability, robust against partial failures, and self-organizing topology that minimizes per-node configuration. Convergence delay is acceptable for use cases that do not require instant global consistency.¶
Scale range: Hundreds to thousands of sites.¶
The discovery workflow proceeds as follows:¶
Select dissemination neighbors: Each FGW maintains a bounded set of authorized neighbors using the selected protocol's configuration or neighbor-discovery mechanisms.¶
Originate permitted records: The originating FGW constructs an export view containing records approved for dissemination to the participating group. Export policy accounts for onward relay, rather than only disclosure to the immediate neighbor.¶
Exchange record summaries and changes: Neighboring FGWs periodically exchange summaries of the records eligible for sharing, followed by missing or newer records. A receiving FGW verifies publisher provenance, integrity, validity, and relay permissions before accepting information into its FAD.¶
Relay and reconcile: Accepted records may be relayed to other authorized neighbors. Repeated reconciliation exchanges propagate changes and reduce differences between participants. The selected protocol's version and withdrawal mechanisms prevent superseded or withdrawn information from being reintroduced as current.¶
Answer requests and expire records: Each FGW answers requests using eligible local FAD records. Updates and withdrawals propagate over time, while validity limits bound continued use of records that have not yet been reconciled. Relaying a record does not restart its validity period.¶
Consider a set of cooperating organizations that authorizes a shared directory to expose selected agent resources to an agreed audience. A requester knows the required service or resource type but does not know which participating domain publishes a matching resource. DNS and DNS-SD can resolve or browse records within known naming and service-discovery scopes; the baseline in this document does not define an application-level query over an aggregated, policy-approved collection spanning multiple independently administered domains. Trusted directory publication supplies that aggregation and query function. The directory is limited to authorized participants and permitted records; it does not imply open-Internet agent indexing, which is outside the DAWN charter.¶
Recommended approach: Hybrid deployment. The FGW participates in a peer federation for trusted partners, AND optionally publishes a subset of sanitized FMRs to a trusted or semi-public directory service (e.g., AGNTCY ADS [I-D.mp-agntcy-ads]) or to a DNS-based registration/aggregation system, operated under explicit trust relationships. In the preferred DNS realization, the FGW publishes the subset in its own authoritative zone, or registers it with a trusted aggregator that mirrors the records.¶
Rationale: Combines the data sovereignty and trust benefits of peer federation with the broad discoverability of public directories. The Export Policy Engine controls which records are published to the public directory versus retained for federation peers only.¶
The discovery workflow proceeds as follows:¶
Publish an approved view: The originating FGW selects the discovery information permitted for the directory's audience and supplies it through the directory's existing publication interface. The directory maintains the accepted information according to its publication policy.¶
Locate and query the directory: A requesting FGW obtains the directory endpoint through configuration, DNS discovery, or a referral and submits a query using the directory's supported lookup interface.¶
Validate and return results: The requesting FGW evaluates the response using the selected protocol's security mechanisms, publisher provenance, and local import policy. It returns accepted discovery information and MAY cache it in its FAD within the applicable validity and disclosure conditions.¶
Maintain publication: The originating FGW updates or withdraws directory entries as agent state or export permission changes. Where the directory uses publication leases, the publisher renews them according to that interface. Publication leases and requester cache lifetimes are managed according to their respective rules.¶
Consider a federation in which the requesting domain can discover a partner's service endpoint through DNS, but the partner cannot publish all permitted discovery records in publicly queryable DNS because different requesters have different disclosure permissions. The requester may also need an application-level directory query or an ongoing authorized exchange rather than a lookup of a known DNS name. DNS can securely locate the relevant discovery endpoint, while the endpoint's own protocol applies access control and provides the required query or synchronization behavior. Mixed-mode federation combines DNS-based bootstrap with these non-DNS functions; it does not require duplicating detailed restricted records in public DNS.¶
Phase 1 -- Discover the endpoint through DNS: The originating domain publishes a pointer to an FGW discovery endpoint, directory, or supported exchange service using the applicable DNS service-discovery binding. The requesting FGW resolves and validates the pointer and obtains the endpoint and supported protocol information. Detailed records intended for retrieval through that endpoint need not be published in public DNS.¶
Phase 2 -- Metadata exchange: The requesting FGW uses the discovered endpoint's supported protocol. Depending on the deployment, it retrieves information on demand, queries a directory, or establishes a peering or dissemination relationship. The endpoint applies its existing access-control mechanisms, and the receiving FGW validates the returned information before using or storing it.¶
Phase 2 supports the following patterns:¶
Proactive distribution: The discovered endpoint supports an exchange protocol through which participating FGWs obtain an initial export view and subsequent changes. Accepted records may therefore enter the FAD before an individual discovery request arrives. Peering or gossip follows the corresponding workflow described above.¶
Directory lookup: DNS identifies a directory endpoint, and the requesting FGW submits an application-level query over the directory's published resource collection. The directory may aggregate information from several independently administered domains.¶
This two-phase pattern keeps detailed discovery records under the originating site's access control while still using DNS for the initial context that DAWN requires. Deployments that prefer maximum interoperability and public discoverability may instead use DNS Mode in its full form, publishing FMRs directly as resource records; the choice between the two is an operator decision driven by the required level of access control and data sovereignty.¶
The architecture also permits different subsets of an overall federation to adopt different mechanisms concurrently - for example, a core group of trusted operators using BGP-like structured peering among themselves while peripheral participants use gossip. In all cases the FMR metadata format is shared across modes, ensuring that records are interoperable regardless of how they are transported.¶
Cross-domain discovery needs integrity, privacy, and appropriate disclosure boundaries. The following subsections identify relevant existing mechanisms and deployment responsibilities. They do not define identities, credentials, authentication exchanges, trust evaluation, or admission procedures.¶
Discovery uses the security mechanisms of the underlying protocols. DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484] can protect resolver transport where applicable. Existing HTTPS endpoints use TLS [RFC8446] and their established application security. Transport protection does not by itself validate the original DNS data or grant permission to use an agent.¶
In the DNS baseline, DNSSEC [RFC4035] provides origin authentication and integrity for signed discovery records under the applicable validation policy. The FGW does not accept a bogus DNSSEC result as validated information. This framework does not require a separate FMR signature envelope or define key management.¶
Where DNS advertises an application endpoint, DNSSEC protects the pointer, not information subsequently obtained from that endpoint. The application protocol supplies the appropriate response protection and endpoint authentication. DANE [RFC6698] may support endpoint authentication where applicable; its procedures are not redefined here.¶
The Export Policy Engine determines which discovery information may leave the domain and for which audience. Records explicitly approved for public disclosure may be published in public DNS. Restricted information uses an appropriately controlled discovery domain or an existing access-controlled endpoint located through DNS.¶
Public DNS caching does not provide arbitrary per-user disclosure control. Restricted cached results are reused only under compatible audience and applicability conditions. Identity provisioning and authorization exchanges use the selected existing mechanisms and remain outside this document. Agent invocation authorization is separate from discovery.¶
The DNS baseline does not introduce a federation membership or admission protocol. Operators use existing domain administration, DNS validation policy, and any access-control arrangements required by an external endpoint. Establishing agent identities, evaluating participant trust, and defining admission procedures are outside scope.¶
Existing DNS and endpoint operational protections apply. Implementations can bound cache storage and request processing according to local policy. This framework does not introduce additional peer keepalives, hold timers, connection admission messages, or a federation-wide security state machine.¶
When a network partition occurs, FGWs on each side lose connectivity to peers on the other side. The architecture handles this as follows:¶
Previously accepted remote FMRs remain eligible in the local FAD only until their permitted validity expires. This prevents transient partitions from causing mass agent disappearance.¶
When connectivity is restored, a full resynchronization (in peering protocols) or anti-entropy exchange (in gossip protocols) reconciles the two sides.¶
Operators SHOULD set TTL values that balance prompt stale-record removal against tolerance for transient partitions. A TTL of 300 seconds (5 minutes) is RECOMMENDED as a default.¶
An agent or FGW may stop unexpectedly without completing graceful withdrawal. The architecture distinguishes resource failure, discovery-component failure, and temporary loss of connectivity; none of these conditions is inferred solely from a failed federation session or an unexpired discovery record.¶
Unexpected agent failure: Authorized deployment or management infrastructure detects the change and updates or withdraws the agent's registration and corresponding published information. Previously cached DNS results may remain usable until expiration even after authoritative records are removed. A requester may therefore encounter an unreachable endpoint during this interval.¶
FGW failure with independent DNS service: Published DNS records may remain retrievable while the originating FGW is unavailable. Remote FGWs can continue request-driven DNS retrieval if the authoritative service remains reachable and the records remain valid. An authorized controller or replacement FGW is needed to maintain publication accuracy as agent state changes; DNS availability alone does not establish that the published agent information is current.¶
Failure of the authoritative DNS service: A requesting FGW MAY answer from a valid matching FAD entry within its permitted lifetime. When no such entry exists, it cannot complete discovery through that DNS source and reports a temporary discovery failure or uses another authorized discovery path. Failure to retrieve a record does not by itself prove that the agent has stopped.¶
Failure of a separate local infrastructure gateway: The FGW may stop receiving deployment updates while previously collected information remains present. An authorized monitoring or reconciliation mechanism determines whether that information can still be treated as current and updates or withdraws publications when necessary.¶
Recovery: A recovered or replacement FGW reconciles local discovery and infrastructure registration state with actual deployments before restoring publication. It repairs authoritative DNS records without requiring unsolicited population of remote FADs; remote FGWs obtain the current records through subsequent request-driven lookups.¶
Planned shutdown distinguishes withdrawal of an agent from shutdown of an FGW. Agent withdrawal changes the availability of a discoverable resource. FGW shutdown affects discovery publication or federation functions but does not necessarily make the agents represented by that FGW unavailable.¶
Before an agent is shut down, the responsible agent management or deployment infrastructure SHOULD notify the local discovery component and withdraw or update the agent's registration. A separate local infrastructure gateway communicates the corresponding change to the FGW; an integrated FGW obtains it from the infrastructure's registration records. The FGW then updates the affected FMRs and their publication state.¶
The FGW or an authorized publication controller removes or updates the affected authoritative DNS records. This action prevents subsequent authoritative queries from returning the withdrawn information, but it does not immediately invalidate copies already held by recursive resolvers or remote FADs. Those copies remain subject to their previously established expiration times. Lowering the authoritative TTL at shutdown does not shorten the lifetime of copies already cached.¶
For a planned agent shutdown, an operator MAY lower the TTL sufficiently far in advance, allow the previous larger cache lifetimes to elapse, withdraw the affected records, and allow the remaining cache lifetimes to expire before stopping the agent. Where supported, the service MAY drain existing interactions separately from discovery withdrawal. The detailed shutdown and draining procedures are deployment-specific.¶
Before an FGW is shut down, its publication and federation responsibilities SHOULD be transferred to a replacement component or explicitly discontinued. If agents remain available and their authoritative DNS records remain accurate and are maintained by another authorized component, those records need not be withdrawn solely because the FGW stops. Records advertising an FGW-hosted discovery endpoint that will become unavailable SHOULD be updated or removed.¶
The FAD maintains expiration information for accepted remote records according to the mechanism through which they were obtained. Expiration limits the use of cached or synchronized information; it does not by itself establish whether an agent is currently reachable.¶
Remote discovery information is not pre-populated in the FAD by default. When a cross-domain request has no valid matching cache entry, the FGW retrieves the relevant DNS records, validates them, and caches the accepted information. Its expiration time is bounded by the remaining TTL supplied by the DNS resolution process and any shorter applicable record or validation lifetime. A response obtained from an intermediate resolver does not receive a new full authoritative TTL merely because it is copied into the FAD.¶
A cache hit does not restart the entry's lifetime. Once an entry expires, it is no longer eligible to answer discovery requests. A subsequent request triggers fresh DNS retrieval and validation. The FGW does not extend an expired entry merely because the authoritative service is temporarily unreachable. Background cleanup MAY remove expired entries later, provided that request processing excludes them immediately upon expiration.¶
A fresh validated DNS response MAY establish a new cache lifetime according to its remaining TTL and applicable validity limits. DNS-based discovery relies on request-driven retrieval rather than periodic refreshes pushed to remote FADs. Retrieving an unchanged record does not require a new FMR version.¶
DNS TTL bounds the lifetime of a cached copy, not the lifetime of a record in the authoritative zone. If an obsolete record remains published, subsequent queries can retrieve and cache it again. Deployments therefore need an authorized mechanism to reconcile published DNS records with current agent state and to remove obsolete publications independently of cache aging.¶
Where discovery results depend on Attachment Scope, cached information is reused only for requests satisfying the same applicability conditions. A change in attachment context may require a new lookup before the record's TTL expires.¶
The FMR format uses self-describing TLV (Type-Length-Value) encoding, allowing new optional fields to be added without breaking backward compatibility. Recipients MUST ignore unknown TLV types.¶
DNS-based discovery is the baseline. Where DNS-based mechanisms and existing DNS extensions do not meet a deployment's discovery requirements, additional mechanisms may complement them. An FGW may support multiple discovery mechanisms concurrently, while applying consistent publication, validation, and caching policies. Each mechanism follows its own existing specification for versioning and capability negotiation; this framework defines no new negotiation procedure.¶
Major architectural changes that break compatibility require a new version of this framework document and SHOULD be discussed in the DAWN working group before deployment.¶
Operators of federation gateways SHOULD monitor the following metrics:¶
Number of active federation peers and peer session uptime.¶
FAD size and growth rate, per origin gateway.¶
FMR update rate and withdrawal rate.¶
Signature verification failure rate (indicator of potential attacks or misconfiguration).¶
FAD cache-hit and cache-miss rates, entry expiration and eviction rates, and DNS lookup latency. Cache expiration is normal and does not by itself indicate publication failure.¶
DNS resolution failures, DNSSEC validation failures, authoritative publication update failures, and discrepancies detected during publication reconciliation.¶
Discovery query request rate and authorization failure rate.¶
This informational document does not request any new IANA registrations. The architecture itself does not define protocol numbers, ports, or message types.¶
Future normative protocol specifications derived from this architecture MAY request IANA allocations, including but not limited to: well-known TCP/UDP ports for federation control protocols, message type registries, and FMR TLV type registries. DNS-based realizations may additionally request allocation of DNS service names/types (e.g., under the DNS-SD service-type registry) or of new DNS resource record types for agent discovery. Such requests are the responsibility of the respective protocol documents.¶
A shared FMR TLV type registry MAY be established to ensure interoperability across different federation protocols. If established, it SHOULD be managed under the "Specification Required" policy [RFC8126].¶
The author thanks the DAWN working group participants for their foundational work on agent discovery terminology, requirements, and gap analysis. This architecture builds directly on the DAWN problem statement, requirements, use cases, and the discovery mechanism survey by Jimenez et al.¶