Comparison
UHP vs DNS-AID
DNS-AID answers where an agent or agent index can be discovered and how DNS can authenticate that discovery. UHP answers how a product executes work through a complete agent harness. They occupy different layers and can be complementary, but no standardized binding currently connects them.
The one-sentence difference
Section titled “The one-sentence difference”DNS-AID is a DNS-based discovery and trust substrate for finding agent endpoints or an organization’s agent index before invocation; UHP is an HTTP execution contract for driving complete agent harnesses after a client has reached a UHP server.
That makes the two concepts complementary in architecture, not competing wire protocols.
Status first
Section titled “Status first”- UHP is the
2026-09-12Draft standard. It defines the client↔UHP-server contract for discovering harness capabilities and executing tasks, sessions, streams, files, artifacts and optional Harness Plugins. - DNS-AID is currently IETF Internet-Draft
draft-mozleywilliams-dnsop-dnsaid-02, published 27 May 2026 with intended status Standards Track and an expiry date of 28 November 2026. It is not an RFC. - The Linux Foundation announced DNS-AID as an open source project on 27 May 2026. The first-party
dns-aid/dns-aid-corerepository states that the IETF draft is authoritative for protocol behavior and the repository is the reference implementation/tooling surface. - The latest observed stable reference-implementation release is
v0.28.1, published 9 August 2026. Checkedmainisdbcaafde94e37eb0b22f7357a35c53a3afd11ceaat this research cutoff. - No reviewed primary source establishes a standardized DNS-AID↔UHP binding, a registered UHP DNS-AID protocol identifier, native HarnessRouter DNS-AID integration, or DNS-AID adoption by the UHP specification.
Architectural comparison
Section titled “Architectural comparison”| Dimension | UHP | DNS-AID |
|---|---|---|
| Layer | Harness execution/runtime control | Pre-invocation discovery and DNS trust |
| Main question | “How do I run work through this complete harness?” | “Where is this agent or this organization’s agent index, and what connection metadata was published?” |
| Primary substrate | HTTP API plus UHP object/lifecycle semantics | DNS, especially SVCB; optional TLSA/DNSSEC trust |
| Main object | Harness/task/session/file/artifact/plugin lifecycle | Agent SVCB record or organization-index pointer |
| Known-agent discovery | UHP server capability/harness discovery after reaching the server | Direct SVCB lookup for an agent’s owner name |
| Organization discovery | UHP does not define Internet-scale organization discovery | _index._agents.<domain> can point to an organization-specific index |
| Global capability search | Out of scope | Also out of scope in draft-02; directories can be built above the DNS substrate |
| Invocation semantics | Defined: submit, stream, continue, cancel, retrieve outputs | Out of scope; the discovered application protocol handles invocation |
| Trust boundary | UHP authentication, authorization and scoped runtime objects | DNSSEC/DANE and DNS publishing authority; downstream agent behavior remains out of scope |
| Maturity | Draft standard with runnable conformance suite | Standards-track Internet-Draft plus Linux Foundation reference implementation |
What DNS-AID standardizes
Section titled “What DNS-AID standardizes”The current Internet-Draft uses existing DNS mechanisms rather than inventing a new DNS message type. It introduces no new DNS resource-record type, opcode or response code. Its core discovery paths are:
- Known agent. When the requester knows the agent and origin domain, it queries the agent’s owner name for an SVCB RRset. Draft-02 says this direct form is what publishers SHOULD support and requesters MUST try first.
- Known organization. When the requester knows the organization but not the specific agent,
_index._agents.<domain>can return an SVCB pointer to an organization-specific agent index. The data format and protocol served by that index are deliberately outside DNS-AID’s scope. - Known capability, unknown organization. Internet-wide or cross-organization capability search is explicitly outside draft-02. A directory can aggregate organization indexes, but DNS-AID does not standardize that search service.
An agent SVCB record can carry connection and discovery metadata such as TargetName, address hints, application/transport protocol information, a well-known path and capability references. Draft-02 gives MCP and A2A as example application-layer protocol identifiers, but the requested ALPN identifiers are still placeholders pending confirmation with those protocol maintainers.
Trust: what DNS proves and what it does not
Section titled “Trust: what DNS proves and what it does not”DNS-AID’s security model is intentionally narrow. Draft-02 says its authenticity properties derive from DNSSEC: a validated chain of trust to signed SVCB/TLSA data gives cryptographic evidence that the records were published by an entity controlling the signing zone. DANE/TLSA can additionally bind the discovered TLS endpoint.
That does not prove the discovered agent is safe, benevolent, authorized for the caller’s task or semantically correct. Those remain application/runtime concerns. Draft-02 is deployable without DNSSEC, but its stronger authenticity guarantees depend on a validated DNSSEC path; consumers are advised not to weaken validation merely because an attacker-supplied record omits stronger parameters.
This distinction matters for UHP: discovering a hypothetical UHP endpoint securely would still leave UHP authentication, permissions, harness selection, task execution and artifact handling to the UHP server and client.
The reference implementation is broader than the draft
Section titled “The reference implementation is broader than the draft”The Linux Foundation dns-aid-core project is useful implementation evidence, but it must not be silently promoted into IETF normative behavior.
At the checked cutoff, the project provides a Python SDK, CLI and an MCP server for DNS-AID operations, multiple DNS-provider backends, discovery/invocation helpers and additional trust hardening. Stable v0.28.1 is the latest observed release. Current main includes a fail-closed correctness fix for Route 53 and NS1: backend lookup errors during unpublish no longer masquerade as “record absent,” preventing an operation from reporting success while a live record may still exist.
The same implementation also documents opt-in interoperability with Agentic Resource Discovery (ARD) ai-catalogs. Its catalog path can use DNS-AID SVCB pointers to locate an ARD catalog and then dereference protocol-specific cards. The project describes ARD as the search/index layer and DNS-AID as the authoritative discovery/identity substrate. That is first-party implementation behavior and architectural composition; it does not turn ARD into part of the DNS-AID IETF draft or create a UHP binding.
DNS-AID, ARD and DAWN are not the same thing
Section titled “DNS-AID, ARD and DAWN are not the same thing”The discovery ecosystem now contains several adjacent layers:
- DNS-AID standardizes DNS-based location and trust signals for agents and organization indexes.
- ARD defines a richer discovery-entry and registry/search model, including static publication and registry federation.
- IETF DAWN is a broader agent-discovery standardization effort whose proposed scope includes local and organizational discovery and considers DNS among candidate building blocks.
- MCP Server Cards / A2A Agent Cards describe protocol-specific endpoints and capabilities; DNS-AID can point toward such application-layer metadata without replacing it.
These can compose, but none should be collapsed into another. See UHP vs ARD for the registry/discovery comparison and UHP vs MCP / UHP vs A2A for the invocation-layer neighbors.
Where UHP could fit
Section titled “Where UHP could fit”A future system could use DNS-AID to discover a service and then speak UHP to that service if a UHP-specific discovery convention were standardized. Conceptually:
DNS / DNS-AID │ discover location + transport/trust metadata ▼UHP endpoint (hypothetical standardized binding) │ negotiate UHP server capabilities ▼Harness selection + task/session execution ▼Files, artifacts and resultsToday, the second arrow is hypothetical. UHP 2026-09-12 does not define DNS-AID publication/discovery records, and DNS-AID draft-02 does not define UHP as an application protocol identifier. A private deployment can of course publish custom metadata, but that is not interoperability until multiple implementations share a documented standard.
Practical boundary
Section titled “Practical boundary”Use DNS-AID when the problem is decentralized discovery anchored in an organization’s DNS namespace, especially when cacheability, operator control and DNSSEC/DANE trust are useful.
Use UHP when the endpoint is already known and the problem is portable execution across complete harness runtimes: task submission, streaming, continuation, cancellation, sessions, files, artifacts and harness/plugin configuration.
Use ARD or another directory/index layer when the caller does not know which organization hosts the needed capability and needs search/ranking across publishers. DNS-AID draft-02 explicitly leaves that global search problem outside its normative scope.