A Framework for Agent Discovery in DAWN

1.1. Document Scope

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 additional functions include recipient-specific sharing, proactive or multi-hop dissemination, and trusted aggregated directory queries.. Discovery returns an endpoint, communication protocol, and any applicable reference needed to continue discovery.¶

1.2. Out of Scope

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.¶

1.3. Document Organization

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 identifies optional discovery functions beyond the DNS baseline and describes mixed-mode DNS bootstrap. Section 8 identifies existing security mechanisms and disclosure boundaries. Section 9 covers resilience, publication updates, and caching.¶

3.1. Functional Requirements

1. 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].¶

2. 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].¶

3. 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.¶

4. 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].¶

5. 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].¶

6. 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].¶

7. 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.¶

8. 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.¶

9. 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.¶

3.2. Non-Functional Requirements

1. 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.¶

2. NF-2: Fault Tolerance -- The architecture MUST tolerate individual gateway failures, network partitions, and transient connectivity loss without catastrophic loss of discovery capability.¶

3. 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.¶

4. 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].¶

5. 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 every site to maintain separate manual relationships with all other sites.¶

6. 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.¶

4.1. ACAP (Agent Capability Advertisement Protocol)

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.¶

4.2. Agent Directory

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.¶

4.3. AGNTCY Agent Directory Service (ADS)

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).¶

4.4. DNS-Based Naming Proposals (DNS-AID, DN-ANR)

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.¶

4.5. MDI (Minimum Discoverable Information)

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 description of one entity rather than a capability catalog. Its identifier is interpreted within the originating publisher's scope; reachability and communication protocol information are associated with the endpoint. Publication and caching lifetimes follow the applicable discovery mechanism. This framework does not define an FMR wire format or extension encoding; those details belong to the specifications for the mechanisms that carry the information.¶

5.1. Centralized Global Directory

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.¶

5.2. Link-Local Multicast Discovery (mDNS/DNS-SD)

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].¶

5.3. Gap Summary

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).¶

• Maintaining a separate manual relationship with every other site does not scale well as a federation grows (NF-5).¶

• Proactive or multi-hop dissemination can complicate NF-1 (security against forged advertisements) and F-6 (prompt lifecycle invalidation) when updates propagate through intermediaries.¶

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) using DNS publication and on-demand resolution as the cross-domain baseline, with optional additional functions where needed; and (4) exchanging only the minimum public discovery information in FMRs to reduce cross-domain data exposure.¶

6.1. Layer 1: Local Discovery Plane

The Local Discovery Plane identifies AI-agent resources available within an administrative domain and makes the resulting discovery information available to the Federation Gateway (FGW), subject to local policy.¶

Two complementary mechanisms may be used:¶

• locally advertised or discovered resources; and¶

• infrastructure-maintained resources in managed environments.¶

Both mechanisms can coexist within the same administrative domain. The Local Discovery Plane does not itself determine what information is exported to other domains; that is controlled by the FGW and its export policy.¶

6.2. Layer 2: Federation Plane

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. Optional functions beyond the DNS baseline are described in Section 7.¶

1. 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.¶

2. 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.¶

3. 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.¶

4. 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.¶

6.4. Functional Components

• 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): Uses the DNSSEC validation result for DNS-published discovery information and relies on the selected application protocol for response protection and endpoint authentication when DNS points to an application endpoint. It does not require separate FMR signing or signature verification.¶

• 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.¶

7.1. Recipient-Specific Sharing

Some deployments may need to distribute different discovery information to different authorized peers. Where this cannot be achieved through the deployed DNS publication model, an additional peer-to-peer mechanism may be used. A structured peering mechanism with route-policy-like export control is one possible realization. The specific protocol is outside the scope of this document.¶

A structured peering mechanism may support incremental exchange of discovery information, per-peer export policy, and delegation or referral between discovery domains. The specific synchronization procedures, peering topology, convergence behavior, and scaling characteristics are outside the scope of this document.¶

An originating FGW applies its Export Policy Engine to determine the discovery information permitted for each authorized peer. The selected peer-to-peer mechanism conveys that information and any subsequent updates or withdrawals to the receiving FGW, which validates the information and applies local import policy before making accepted records available for discovery. Procedures for peer establishment, synchronization, recovery, and reconciliation are properties of the selected mechanism and are outside the scope of this document.¶

7.2. Proactive or Multi-Hop Dissemination

Some deployments may require discovery information to be distributed proactively among participating domains or propagated through authorized intermediaries. This can be useful when participants change dynamically, when connectivity is intermittent, or when request-driven retrieval alone does not meet operational requirements¶

A dissemination mechanism may propagate policy-approved discovery information, including updates and withdrawals, across multiple participating sites. The originating administrative domain remains responsible for determining which information may be exported.¶

The specific dissemination protocol, peer-selection algorithm, propagation procedure, reconciliation method, convergence behavior, and scaling characteristics are outside the scope of this document.¶

7.3. Trusted Directory Publication

Some deployments may need to support application-level queries across discovery information contributed by multiple administrative domains. DNS and DNS-SD can resolve or browse information within known naming or discovery scopes, but they do not by themselves provide an aggregated query service across an authorized collection of resources from multiple domains.¶

A trusted directory may provide this function. Participating domains publish a policy-approved subset of their discovery information to the directory, which can index the information and answer queries on behalf of authorized requesters.¶

Each originating administrative domain remains responsible for determining what information may be exported to the directory. The directory does not become authoritative for the underlying resources; it provides an aggregated discovery view based on information supplied by participating domains.¶

The directory protocol, query language, indexing method, synchronization procedure, and internal storage model are outside the scope of this document.¶

7.4. Mixed-Mode Federation

DNS-based discovery and an additional federation mechanism may be used together.¶

For example, DNS may be used to discover the relevant federation endpoint, after which another mechanism provides a function not available through the DNS baseline, such as recipient-specific sharing, proactive dissemination, or an aggregated directory query.¶

Conceptually:¶

Conceptually:Requester / FGW
      |
      v
      DNS-based discovery or bootstrap
      |
      v
      Federation endpoint
      |
      +--> recipient-specific peer exchange
      |
      +--> proactive dissemination
      |
      +--> trusted directory query

The use of an additional mechanism does not replace authoritative DNS publication where DNS is used. Each administrative domain remains responsible for controlling the discovery information it exports, and received information remains subject to validation and local import policy.¶

The specific protocol interactions between DNS and the additional federation mechanism are outside the scope of this document.¶

8.1. Layer 1: Transport Security

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.¶

8.2. Layer 2: FMR Origin Authentication and Integrity

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.¶

8.3. Layer 3: Access Control on Discovery Information

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.¶

8.4. Layer 4: Federation Admission Control

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.¶

8.5. Denial-of-Service Considerations

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.¶

9.1. Network Partition Handling

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, the FGW can resolve the needed information again through DNS and validate the response before updating its cache. Any additional mechanism handles its own update or recovery procedures.¶

• 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.¶

9.2. Gateway Failure and Recovery

• 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.¶

9.3. Graceful Shutdown

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.¶

9.4. TTL-Based Stale Record Aging

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.¶

9.5. Version Evolution and Forward Compatibility

• The information model may evolve through extensions defined by the applicable discovery specifications. Each mechanism determines how extensions are encoded, recognized, and handled by recipients.¶

• 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.¶

9.6. Operational Monitoring

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.¶