# How does a USP Agent find its Controller? DHCP, DNS-SD and mDNS

Dodderware engineering team · Published 2026-10-28 · https://blog.dodderware.com/usp-discovery-dhcp-mdns/

[Leer en español](https://blog.dodderware.com/es/descubrimiento-usp-dhcp-mdns/)

> **Short answer:** A USP Agent needs its Controller’s Endpoint ID, credentials and Role, and enough to reach it, meaning an MTP, address, port and path. TR-369 lets that come from firmware, from an already-trusted Controller, from a bootstrap interface or from the network. DHCPv4 option 125 or DHCPv6 option 17 can deliver one Controller’s URL or FQDN and Endpoint ID, and DNS-SD over DNS or mDNS resolves the rest.

A USP Agent on a freshly installed gateway or ONT has two questions before it can do anything useful: which Controller
should it talk to, and how does it reach it? TR-369 calls the answer **discovery**, the process by which Endpoints learn
each other’s USP properties and MTP connection details, and its mirror image **advertisement**, the way Endpoints make
their presence known (§3).

## What does an Agent need to know about its Controller?

To work with a Controller, an Agent needs that Controller’s Endpoint ID, its credentials and its authorized Role. To
send anything, it also needs at least one MTP, an IP address, a port and, if the MTP requires one, a resource path. That
can arrive as a complete URL, as an FQDN that resolves to all of those through DNS-SD records, or through mDNS discovery
on the LAN (§3.1).

The specification lists example ways to configure it, which “include but are not limited to” (§3.1):

- Pre-configured in firmware.
- Configured by an already-known-and-trusted Controller.
- Configured through a separate bootstrap mechanism, such as a user interface or another management interface.
- DHCP, DNS or mDNS.

Whatever the source, an Agent that supports USP configuration of Controllers keeps them in the
`Device.LocalAgent.Controller` Object of the Device:2 data model (R-DIS.0). The other direction is simpler: a Controller
learns an Agent’s Endpoint ID, MTP details and credentials when the Agent first connects, although a Controller on the
LAN can also pick up an Agent’s MTP information through mDNS (§3.2).

1. **Controller details arrive** (Bootstrap): From firmware, a trusted Controller, a user interface, or DHCP options 125 and 17.
2. **DNS or mDNS** (Resolve): A and AAAA records for the name, plus PTR, SRV and TXT when the MTP or path is unknown.
3. **Over the MTP** (Connect): For example a WebSocket session, which the Agent normally opens itself.
4. **Authenticate and assign a Role** (Trust): Pre-configured certificates, trust on first use, or approval by a user.

*From a Controller address to a working USP relationship. Diagram by Dodderware, based on TR-369 §3.1, §3.3, §3.6, §4.3.2 and §8.*

## How does DHCP give an Agent its Controller?

The DHCPv4 Vendor-Identifying Vendor-Specific Information Option (code 125) and the DHCPv6 Vendor-specific Information
Option (code 17) can tell an Agent about a single Controller (§3.3). The Agent has to ask first. If it is configured to
request Controller information, it must include the DHCPv4 V-I Vendor Class Option (124) or the DHCPv6 Vendor Class
option (16) in its requests, with the Broadband Forum enterprise number, 3561 (`0x0DE9`), and the string “usp” in lower
case (R-DIS.1). The answer is a set of encapsulated sub-options (§3.3.1):

| Sub-option                      | DHCPv4 option 125 | DHCPv6 option 17 | Where it lands in the data model                                    |
| ------------------------------- | ----------------- | ---------------- | ------------------------------------------------------------------- |
| URL or FQDN of the Controller   | 25                | 25               | Depends on the MTP                                                  |
| Provisioning code               | 26                | 26               | `Device.LocalAgent.Controller.{i}.ProvisioningCode`                 |
| USP retry minimum wait interval | 27                | 27               | `Device.LocalAgent.Controller.{i}.USPNotifRetryMinimumWaitInterval` |
| USP retry interval multiplier   | 28                | 28               | `Device.LocalAgent.Controller.{i}.USPNotifRetryIntervalMultiplier`  |
| Endpoint ID of the Controller   | 29                | 29               | `Device.LocalAgent.Controller.{i}.EndpointID`                       |

The Role of a DHCP-discovered Controller is determined programmatically, through the rules of the authentication and
authorization section (§3.3).

DHCP “does not itself incorporate a security mechanism”, so the specification advises ISPs to use it for Controller
configuration only where the service provider can assure the security of the link between the DHCP server and the Agent,
and to establish trust through pre-configured certificates or other means (§3.3).

## Where do DNS and mDNS come in?

When sub-option 25 carries an FQDN rather than a URL, name resolution takes over. With DNS enabled, an Endpoint requests
A and AAAA records as usual (R-DIS.6). If the Agent is resolving a Controller’s FQDN and does not know the MTP or the
resource path, it must also request the DNS-SD records: PTR, SRV and TXT (R-DIS.7).

On the LAN, mDNS does the same job without a DNS server. An Endpoint that supports it implements both the client and the
server side of RFC 6762 (R-DIS.3) and resolves any name in the “.local.” domain through mDNS (R-DIS.5). The roles are
asymmetric. Agents are expected to advertise themselves so that Controllers can find them, while Controllers are
expected to discover Agents and answer their mDNS requests rather than advertise. An Agent uses mDNS to resolve a
Controller’s “.local.” name when it needs to send that Controller a Notification (§3.5).

Advertising comes with an obligation: an Endpoint that advertises an MTP over mDNS must listen on that MTP for other
Endpoints that want to start USP communication (R-DIS.4). And since mDNS stops at LAN segment boundaries, the
specification describes a Discovery Proxy that repeats what it discovers across segments (Appendix IV.2).

## What do USP DNS-SD records look like?

DNS-SD (RFC 6763) names and structures ordinary DNS records so that services can be discovered: SRV and TXT records
describe a service, and PTR records help locate them (§3.7). A Service Instance Name follows the pattern
`<Instance>.<Service>.<Domain>`, and in USP the instance is the Endpoint ID of the Endpoint (R-DIS.8). The service part
comes from the names the Broadband Forum registered with IANA (§3.7.1):

| MTP              | Agent service         | Controller service    |
| ---------------- | --------------------- | --------------------- |
| WebSocket        | `_usp-agt-ws._tcp`    | `_usp-ctr-ws._tcp`    |
| MQTT             | `_usp-agt-mqtt._tcp`  | `_usp-ctr-mqtt._tcp`  |
| STOMP            | `_usp-agt-stomp._tcp` | `_usp-ctr-stomp._tcp` |
| CoAP (obsoleted) | `_usp-agt-coap._udp`  | `_usp-ctr-coap._udp`  |

The TXT record adds details that are not searchable (§3.7):

- Agent records must include `path` and `name`, and `name` must match the `FriendlyName` Parameter if the Agent
  implements it (R-DIS.9, R-DIS.10).
- Controller records must include `path` (R-DIS.11).
- An `encrypt` attribute, which takes no value, means MTP encryption is required to connect (R-DIS.11a).

What `path` holds depends on the MTP: the resource path of the WebSocket URI (R-WS.3), the STOMP destination the
Endpoint subscribed to (R-STOMP.31), or, for an MQTT Agent, its “reply to” Topic (R-MQTT.36). For STOMP and MQTT, the A
and AAAA records point to the broker, not to the Endpoint (R-STOMP.32, R-MQTT.38).

Agents can also be grouped with subtype PTR records, such as `_gateway._sub._usp-agt-ws._tcp` (§3.7.1, §3.7.3).

> **Did you know?**
>
> The IANA list still holds `_usp-agt-coap._udp` and `_usp-ctr-coap._udp`, although the CoAP MTP was obsoleted in USP 1.3
> (§3.7.1, §4.2). UNIX Domain Socket, the MTP added in that same release, has no service name at all: it runs between
> processes inside one device, so there is “no need to advertise” it via mDNS (§4.6.1, Issue History).

## How do CWMP and USP devices on the same LAN recognize each other?

TR-369 reuses a CWMP mechanism in which a gateway and an end device swap identity information through the same
vendor-specific DHCP options, so that an ACS or a Controller can tell whether they share a LAN (§3.4). The Agent puts
its own details in its DHCP requests (R-DIS.2a), and an Agent that receives them answers with its own in the DHCP
response (R-DIS.2b):

| Field                 | Request, DHCPv4 125 | Request, DHCPv6 17 | Response, DHCPv4 125 | Response, DHCPv6 17 |
| --------------------- | ------------------- | ------------------ | -------------------- | ------------------- |
| DeviceManufacturerOUI | 1                   | 11                 | 4                    | 14                  |
| DeviceSerialNumber    | 2                   | 12                 | 5                    | 15                  |
| DeviceProductClass    | 3                   | 13                 | 6                    | 16                  |

The receiving Agent then fills `Device.GatewayInfo` with the ManufacturerOUI, ProductClass and SerialNumber, and sets
`ManagementProtocol` to “CWMP” (R-DIS.2c). If an mDNS PTR record matches the IP address of the DHCP response, the Agent
changes `ManagementProtocol` to “USP” and stores the Endpoint ID from that record (R-DIS.2d). More on how the two
protocols coexist in [TR-069 vs TR-369](https://blog.dodderware.com/tr-069-vs-tr-369/).

## What happens once the Agent has found a Controller?

Finding a Controller is not the same as trusting it. An Agent can be pre-configured with trusted root or Controller
certificates, but the specification also allows an Agent with no current Controller association to trust the first
Controller it discovers, or to let a user approve a discovered Controller through a UI (§3.1). An Agent that accepts
self-signed Controller certificates must give those Controllers an “untrusted” Role on first use (R-SEC.6), which then
has to be raised by another Controller, a challenge or a method outside USP (§8.9.3).

Policy can also start the conversation. An Agent sends an **OnBoardRequest** notification to begin on-boarding with a
Controller, for example when it first comes online and discovers one through DHCP (§3.8). It goes out with `send_resp`
set to true and is retried until the Controller confirms it with a Notify Response (R-NOT.6, R-NOT.6a).

The two roles are explained in [USP Agent vs Controller](https://blog.dodderware.com/usp-agent-vs-controller/), the transports in [USP transports
compared](https://blog.dodderware.com/usp-mtp-websocket-mqtt-stomp/), and the whole protocol in [what is TR-369](https://blog.dodderware.com/what-is-tr-369/).

> **Where DWS Support fits**
>
> Once an Agent has found its Controller, the work becomes day-to-day device management. DWS Support handles TR-069 and
> TR-369 devices from one console, choosing the protocol per device, and its native USP controller connects to Agents over
> WebSocket using USP Records.
>
> [See DWS Support](https://dodderware.com/products/dws-support/)

## Did you know?

- To ask for Controller details over DHCP, an Agent sends the Broadband Forum enterprise number, 3561, and the string “usp” in DHCPv4 option 124 or DHCPv6 option 16. (TR-369 §3.3)
- The same sub-option codes, 25 to 29, carry the Controller’s details in both DHCPv4 option 125 and DHCPv6 option 17. (TR-369 §3.3.1)
- DHCP discovery has delivered the Controller’s Endpoint ID to the Agent since USP 1.2. (TR-369 Issue History)
- In mDNS, Agents are expected to advertise themselves. Controllers are not, but they discover Agents and answer the Agents’ queries. (TR-369 §3.5)
- An Agent with no Controller yet may trust the first Controller it discovers. If it accepts a self-signed Controller certificate, that Controller starts with an “untrusted” Role. (TR-369 §3.1, §8.5)

## Questions people ask

### Which DHCP options does USP use for Controller discovery?

The Agent asks with the DHCPv4 V-I Vendor Class Option (124) or the DHCPv6 Vendor Class option (16), carrying the Broadband Forum enterprise number 3561 and the string “usp”. The answer comes in DHCPv4 option 125 or DHCPv6 option 17, with sub-options 25 to 29 for the Controller’s URL or FQDN, a provisioning code, two retry settings and the Controller’s Endpoint ID.

### What is the DNS-SD service name of a USP Controller?

It depends on the MTP. A Controller reached over WebSocket uses _usp-ctr-ws._tcp and an Agent uses _usp-agt-ws._tcp. MQTT and STOMP have their own names, such as _usp-ctr-mqtt._tcp and _usp-ctr-stomp._tcp. The instance name in front of the service is the Endpoint ID.

### Does a USP Agent have to use DHCP to find its Controller?

No. TR-369 lists DHCP, DNS and mDNS as examples alongside a Controller pre-configured in firmware, one configured by an already-known-and-trusted Controller, and a separate bootstrap mechanism such as a user interface. The list is explicitly not exhaustive.

### Is DHCP discovery of a USP Controller secure?

DHCP has no security mechanism of its own. The specification advises ISPs to use it for Controller configuration only where the service provider can assure the security of the link between the DHCP server and the Agent, and to establish trust with pre-configured certificates or other means.

### How does a Controller find its Agents?

A Controller learns an Agent’s Endpoint ID, MTP details and credentials when the Agent first connects to it, and a Controller on the LAN can also learn an Agent’s MTP information through mDNS. Each Controller keeps its own record of known Agents.

### What is an OnBoardRequest in USP?

A notification an Agent sends to start on-boarding with a Controller, for example when it first comes online and discovers that Controller through DHCP. It is sent with a response requested and retried until the Controller confirms it with a Notify Response.

## Sources

- Broadband Forum, TR-369 – The User Services Platform, Issue 1 Amendment 5 (USP 1.5), January 2026.
- Dodderware, DWS Support product and engineering documentation.
- §3: Discovery and advertisement
- §3.1, §3.2: Controller information on the Agent, Agent information on the Controller
- §3.3, §3.3.1: Use of DHCP for acquiring Controller information, DHCP sub-options
- §3.4: Use of DHCP for exchanging GatewayInfo with CWMP devices
- §3.5, §3.6: Using mDNS and DNS
- §3.7: DNS-SD records, IANA-registered USP service names and examples
- §3.8, §7.6.3.4: SendOnBoardRequest() and the OnBoardRequest notification
- §4.2, §4.3.1, §4.3.2, §4.4.4, §4.5.6, §4.6.1: Discovery requirements of each MTP, the obsoleted CoAP binding
- §8.5, §8.9.3: Self-signed certificates and assigning Controller Roles
- Appendix IV.2, Issue History: Discovery Proxy, discovery changes in USP 1.2 and 1.3

[Read the TR-369 specification](https://usp.technology/specification/index.htm)

TR-369 © The Broadband Forum. All rights reserved. Quoted briefly and paraphrased for commentary; the diagrams are Dodderware’s own.

---

**Manage TR-069 and TR-369 devices from one console.** DWS Support brings every ONT and home router into one web console, whichever protocol it speaks: TR-069 through GenieACS or a built-in ACS, TR-369 through a native USP controller. Self-hosted on your infrastructure. [Request a demo](https://dodderware.com/products/dws-support/#get-started)