]> Tsinghua University

cuiyong@tsinghua.edu.cn

Internet Discovery of Agents With Names LLM API DNS-SD mDNS local discovery Large Language Model (LLM) API services can be hosted on workstations, local servers, and other devices in a local network. AI applications commonly access these services through manually configured API base URLs and interface settings. When an application joins a different network or a service address changes, these settings may need to be updated even when a suitable local service is already available. This document specifies a DNS-Based Service Discovery (DNS-SD) profile for discovering LLM API services on a local link. An advertiser publishes the service location and a small set of API connection parameters. A discovery client resolves these records and offers the resulting connection information to an AI application or its configuration adapter. Subsequent LLM API requests are sent directly to the discovered service, not through the advertiser or discovery client. Discovery does not establish trust, distribute credentials, select models, or define an application's configuration file format. About This Document Status information for this document may be found at . Discussion of this document takes place on the dawn Working Group mailing list (), which is archived at . Subscribe at .

Introduction An LLM API running on a workstation or an enterprise server may be reachable over a local network, yet an AI application cannot use it without knowing its API address and interface conventions. Today these settings are often entered manually. For example, a developer may need to edit an AI coding tool's base URL when moving from an office network to a home network, even though both networks offer accessible LLM services. Multicast DNS (mDNS) and DNS-SD already provide a way to discover network services without prior knowledge of their addresses. This document does not define another discovery transport. It defines how an LLM API service is advertised through DNS-SD, how a client obtains the minimum API connection information, and how that information may be passed to an AI tool after local approval. The advertised endpoint is the actual LLM API service. The component that publishes DNS-SD records may be a separate process and does not need to receive or forward model inference requests.

Problem Statement A locally deployed LLM service is typically configured in an AI application by supplying a base URL, an API interface type, and, when applicable, authentication and model settings. These settings are specific to a deployment rather than to the network service-discovery mechanisms already available to the operating system. This creates a recurring configuration problem. A laptop can move between an enterprise network, a home network, and a temporary development network, each with its own LLM API services. A service can also move to another host or port without changing its function. A client with a previously configured static endpoint does not automatically learn that a different local service is now available. The problem is initial discovery and configuration of an accessible API endpoint, not discovery of GPU hardware or selection of the best model. A common DNS-SD service profile is needed so that an advertiser and an independently implemented discovery client agree on (1) which local services are LLM APIs, (2) where their API endpoints are located, and (3) which API interface the client must support. The discovery result can then be supplied to an AI application without requiring the user to re-enter the endpoint manually.

Scope and Terminology This document specifies discovery on a single local link using mDNS and DNS-SD. It covers directly hosted LLM API services as well as LLM APIs hosted behind a local proxy; the discovery procedure does not depend on the server's internal deployment architecture. It defines the service advertisement, minimum fields, discovery and resolution behavior, and the handoff of a candidate configuration. It does not define LLM inference messages, credential issuance, API key discovery, model selection, model catalogs, GPU resource discovery, or the configuration format of a particular AI application. Discovery across subnets, VLANs, or the public Internet is outside scope. This initial revision defines an API Profile binding for Open Responses. Additional LLM API interfaces can be supported through separately specified bindings. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

• LLM API Service: The HTTP-based endpoint that receives LLM API requests. It may be hosted directly by a model server or exposed by a proxy.
• Discovery Advertiser: A component configured by the service operator to publish DNS-SD records for an LLM API Service. It may run in the service process or separately.
• Discovery Client: A component that browses DNS-SD services, resolves and checks their records, and constructs candidate API connection information.
• AI Application: An AI coding tool, assistant, or other application that uses an LLM API. A local adapter or plugin may pass discovery results into the application's settings.
• API Profile: An identifier for the application-layer API convention expected at a discovered endpoint. It is distinct from a model name.
• Candidate Configuration: A discovered API address and profile that has not yet been approved or authenticated for use.

Use Cases and Architecture The principal use case is a laptop running an AI application that moves between networks. On the office network, an authorized local LLM service is advertised by the enterprise. On the home network, a workstation exposes a different LLM API. In either location, the discovery client can locate an available API and present a candidate configuration. The application can use that configuration only after the applicable approval and security checks. The following diagram illustrates the discovery and configuration handoff process. Subsequent LLM API communication is not shown. | Discovery | | (Actual Server) | | Advertiser | +------------------+ +-------------+ Service Info mDNS / DNS-SD | v +-----------------+ +-----------------+ | Discovery |--->| AI Tool | | Client / Plugin | | (Configuration) | +-----------------+ +-----------------+ API Connection Info ]]> The advertiser MUST obtain its service information from the operator or another authorized local configuration source. This document does not define the advertiser-to-server configuration interface. The discovery client may be implemented as a plugin within an AI application or as a local helper. How it writes or updates application-specific settings is outside the wire protocol.

LLM API Service Advertisement

Service Type and DNS-SD Records This document proposes _llm-api._tcp as the DNS-SD service type for LLM API endpoints. On the local link, the corresponding browse name is _llm-api._tcp.local.. The service name is proposed for registration and is not assumed to be already assigned. The advertiser MUST publish the DNS-SD information needed to browse and resolve a service instance:

• PTR: Identifies an advertised LLM API service instance.
• SRV: Identifies the service host and listening port.
• TXT: Carries the minimum API connection parameters specified below.
• A/AAAA: Resolves the SRV target to an address reachable in the intended local-link context.

One instance describes one API Profile at one API base path on one listener. A listener that supports multiple distinct API Profiles MAY publish a separate service instance for each. A service offering several models through the same API Profile does not need one discovery instance per model. A Discovery Advertiser MUST NOT place credentials, prompts, complete model catalogs, or GPU resource details in TXT records. SRV already carries the host and port, which MUST NOT be duplicated in TXT .

TXT Parameters This version proposes the following TXT keys. All keys and values follow the DNS-SD TXT encoding rules in . The table defines the discovery interface, not a model invocation API.

Key	Requirement	Meaning	Example
txtvers	REQUIRED	Version of this TXT record format	txtvers=1
api	REQUIRED	Identifier of the advertised API Profile	api=openresponses
protovers	Conditional	Version of the API Profile, when required by its binding	protovers=2026-04-24
scheme	REQUIRED	URL scheme, http or https	scheme=https
base	REQUIRED	Path component of the API base URL	base=/v1
auth	OPTIONAL	Authentication hint: required or none	auth=required

The txtvers, api, scheme, and base parameters MUST be present and nonempty. The advertiser SHOULD place txtvers first in the TXT record, as recommended by . A Discovery Client MUST NOT interpret an unsupported TXT format version using version 1 rules. Unknown TXT keys MUST be ignored in accordance with . The protovers parameter MUST be present when required by the selected API Profile binding. An unknown API Profile MUST NOT be treated as supported. An absent auth parameter indicates that the authentication requirement is unknown; auth=none does not constitute authorization. The base value MUST be either / or an absolute URI path beginning with / and not ending with /. It MUST NOT contain a scheme, authority, query, fragment, or userinfo, and MUST NOT contain . or .. path segments. The Discovery Client MUST reject malformed values rather than silently repairing them. The API base URL is constructed using the advertised scheme, the SRV target host, the SRV port, and the base path, following . Operation-specific paths are appended according to the selected API Profile binding without introducing duplicate slashes or additional version prefixes. For example, an SRV target llm-node.local., port 8443, scheme=https, and base=/v1 produce the candidate API base URL https://llm-node.local:8443/v1. No fixed port or universal /v1 prefix is required: the path is taken from the actual service advertisement.

API Profile Binding The api parameter identifies the API Profile exposed by the discovered service. An API Profile defines the interface convention and the rules for interpreting the advertised API base URL. A Discovery Client MUST NOT assume that different API Profiles are interchangeable. This document defines an initial binding for api=openresponses, using protovers=2026-04-24 to identify the Open Responses specification . For this binding, the response creation operation uses HTTP POST at the relative path responses. For example, a base path of /v1 yields /v1/responses. An advertiser using this binding MUST set auth=required. Other interfaces, including Chat Completions-style APIs, may be supported through additional API Profile bindings. Each binding needs to specify its identifier, applicable protocol version, and endpoint construction rules. The existence of an API Profile identifier does not by itself establish compatibility between different server implementations.

Discovery Procedure and Application Handoff The following diagram illustrates the logical flow of LLM API discovery, from service advertisement to the delivery of candidate connection information to an AI tool. The diagram covers discovery and configuration handoff only; subsequent API communication is outside the discovery process. | | | | | | | | | | | Publish DNS-SD | | | | | service records| | | | | | | | | |<--- Browse -----| | | | |---- PTR ------->| | | | | | | | | |<--- Resolve ----| | | | |---- SRV/TXT --->| | | | | A/AAAA | | | | | | | | | | Validate records | | | | Construct API Base URL | | | | | | | | | |-- Candidate ->| | | | |<-- Decision --| | | | | | | | | |-- Approved Configuration ->| | | | | | ]]>

1. Service preparation. The LLM API Service is already running. Its operator supplies the endpoint and API Profile to the advertiser; this may be an internal process configuration, not a network exchange.
2. Advertisement. The advertiser publishes the DNS-SD service instance on the authorized local interface, following mDNS procedures in .
3. Discovery. The client browses _llm-api._tcp.local., resolves the chosen instance, and obtains the SRV and TXT information.
4. Resolution. The client validates the parameters and constructs the candidate API base URL and API Profile. It does not make an inference request to verify discovery.
5. Approval. The Discovery Client presents the candidate connection information to the user or an independently established local authorization policy. Approval MUST NOT rely solely on the advertised service name.
6. Configuration handoff. After approval, the Discovery Client or its adapter MAY provide the API base URL and API Profile to the AI application's configuration mechanism. Application-specific configuration formats are outside the scope of this document. Any required model identifier or credential is obtained separately.
7. API use. The AI application communicates directly with the LLM API Service. The service identity MUST be verified before transmitting credentials or sensitive application data. The Discovery Advertiser and Discovery Client do not forward inference requests.

On an attachment change, the Discovery Client MUST stop offering candidates from the previous attachment for new connections and rediscover on the current one. It MUST respect DNS-SD record lifetimes and withdrawals. A prior approval or API credential MUST NOT be carried to a newly discovered service merely because the instance name or API Profile matches. Automatic replacement of an active model connection is outside scope.

Example The following illustrative DNS-SD records describe an LLM API Server whose API base URL is https://llm-node.local:8443/v1. The discovery client can pass the following candidate values to an application adapter: This example does not supply a model identifier, issue a credential, or make a trust decision. The client must be able to authenticate and authorize the intended local endpoint before sending sensitive prompts or credentials.

Security Considerations mDNS and DNS-SD advertisements on a local network are not inherently trustworthy. A malicious device may forge a service instance, replace the advertised address or API base path, or impersonate a familiar display name. A Discovery Client MUST treat discovery records as untrusted input and MUST NOT transmit credentials or prompts merely because a valid-looking service has been discovered. Clients MUST validate advertised URL components and apply local destination restrictions. For HTTPS endpoints, TLS server identity verification MUST follow . TLS verification of a name learned only from unauthenticated DNS-SD is not, by itself, sufficient authorization to release existing application credentials or private information; trusted service identity and allowed endpoint scope need an independent policy or trust arrangement. Plain HTTP is permitted as an advertised endpoint for deployments that explicitly allow it, but it MUST NOT be treated as confidentiality- or integrity-protected, and clients MUST NOT send sensitive data or credentials over it. Advertisers SHOULD publish only on intended interfaces and SHOULD avoid disclosing sensitive project or model details. A local network may not be private merely because it uses mDNS. An application MUST NOT reuse a cloud-provider API key for a newly discovered local service without separate authorization. Redirects to a different destination require fresh validation and authorization. This document does not define cryptographic integrity protection for the DNS-SD advertisement. Consequently, discovery records MUST be treated as untrusted information until the intended service and destination have been independently authorized. Authentication of the subsequent HTTPS connection does not, by itself, authenticate the original DNS-SD records. An interoperable mechanism for protecting discovery information and binding it to an authorized service identity remains to be specified or referenced in a future revision.

IANA Considerations This document requests registration of the service name llm-api for TCP in the Service Name and Transport Protocol Port Number Registry, following , with the description "LLM API service discovery" and this document as the reference. The registration is for the service name only; no fixed port number is requested. For an assignment resulting from an IETF-stream RFC, the assignee and contact follow the defaults in . The registered service name is used in DNS-SD as _llm-api._tcp. No new DNS resource record type or port number is requested. This text is a proposed IANA action, not a statement that the service name has already been registered.

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry. This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered. This memo documents an Internet Best Current Practice. Open Responses

Acknowledgements The author would like to thank Chenguang Du and Yihan Chao for their valuable discussions and contributions to the development of this document.