Summary

  • Changshan Su’s individual IETF draft proposes a local DNS-SD record for finding AI gateways and describing their routes and advertised capabilities.
  • The draft calls a discovered service a “candidate endpoint”; trust confirmation must come before requests or credentials.

A laptop can discover a printer without convening a constitutional convention. An AI client that discovers a gateway has a more expensive question: who is allowed to receive the key that pays for the next request?

On 26 October 2026, Changshan Su submitted version 00 of “DNS-Based Service Discovery for AI Gateways” as an individual Internet-Draft. The Datatracker lists it as an individual proposal, with no RFC stream or intended RFC status. Its service name, _ai-gateway._tcp, is proposed; the draft says it has no existing IANA assignment.

The plumbing is familiar. DNS-Based Service Discovery uses a PTR record to list a service instance, an SRV record for its target host and TCP port, and a TXT record for short service-specific data; A or AAAA records supply the address. Su’s proposal adds a compact vocabulary for a gateway’s mount path, transport security, authentication requirement and supported protocol types. A client could see, for example, that a service advertises a particular route or a text-generation capability, without baking one address into its configuration.

The space is deliberately small: the draft expects a default TXT payload below 200 bytes and caps the full record at 400. A network announcer gets a name, port, path and a handful of claims. It does not get room to carry a constitution, and the proposal does not pretend the extra bytes would help.

Then comes the most consequential noun in the document: “candidate endpoint.” The client has parsed a service record; it has not yet trusted the machine or approved it to receive credentials. The draft’s sequence is browse, resolve, validate, connect, confirm trust, then send a request. A model-catalog query is optional. Credentials do not belong in the TXT record.

That order matters because a local network is a place where machines can advertise, not a court that has ruled on their authority. The draft’s security section says a participant on the same segment can forge an mDNS announcement, claim auth=0, or direct the SRV record to a host it controls. The advertised id is not an identity receipt. The proposed client must instead rely on user confirmation, a configured trust rule, or a verified TLS server identity. A reusable API key must not travel over plaintext HTTP or WebSocket unless the user or operator has explicitly approved that trusted local arrangement.

A fresh plaintext announcement must not downgrade a gateway already trusted over HTTPS or WSS.

RFC 6763 gives DNS-SD a clean job: help a client discover named instances of a service. RFC 6762 describes mDNS on the local link and says its name-conflict process assumes cooperative participants. Neither job assigns the discovered machine the right to spend someone else’s credentials. A doorbell can say “gateway here.” The key owner still decides whether to open the door.

That is the useful design split. Discovery is a locator. TLS identity can help establish which server answered. The client’s trust rule decides whether this server may receive a credential. Collapsing those into one green “found” light would turn a directory entry into a permission slip. The draft instead makes the extra decision visible, where the user or administrator can set it.

The evidence today is a specification, not a field report: the Datatracker shows one individual -00 draft. The source package contains no implementation comparison, interoperability result or deployment count; a primary test report would change any claim about adoption. For now, the interesting work is the interface between the three decisions. If a client asks for approval, it should show the exact host, port, path, TLS state and authentication claim that the user is approving. “AI gateway found” is a search result. “This endpoint may use my key” is an authorization decision.

Sources