Docs menu
SRP and DNS-SD.
How the Service Registration Protocol extends DNS-Based Service Discovery so devices register themselves into a DNS zone over unicast, and why that matters on constrained wireless networks.
Unicast DNS Update as a registration mechanism.
SRP (RFC 9665) extends DNS-SD by using unicast DNS Update messages, letting a device dynamically register its services and host name in a DNS zone. It replaces the multicast flooding that classic zero-configuration networking depends on.
- A device sends a DNS Update to a designated SRP registrar rather than broadcasting to a multicast group
- Registrations use standard DNS record types — PTR for service instances, SRV for host and port, TXT for metadata
- Registrations carry a lease and are refreshed, so stale entries expire rather than lingering
- Registration is authenticated with SIG(0); the transport is secured with DTLS
- Resolution afterwards is ordinary DNS, so any standard resolver can find the service
Multicast is expensive on wireless networks.
mDNS and broadcast-based discovery assume cheap, always-on network capacity. On IEEE 802.11 and IEEE 802.15.4 that assumption fails: multicast frames are transmitted at low rates, every node must wake to receive them, and battery-powered devices pay for traffic that is not addressed to them.
- Unicast registration consumes far less radio airtime than multicast advertisement
- Sleepy end devices are not forced awake by discovery traffic intended for others
- Discovery scales with the DNS hierarchy rather than with broadcast-domain size
- Registration works across routed networks without requiring a flat Layer 2 segment
This is what makes SRP suitable for constrained IoT environments such as Thread networks, where mDNS is markedly less efficient.
SRP against mDNS and BACnet Who-Is / I-Am.
| Mechanism | How discovery happens | Practical consequence |
|---|---|---|
| SRP | Unicast DNS Update to a registrar | Scales across routed networks; low radio cost |
| mDNS / DNS-SD | Multicast query and response on the local link | Simple, but link-local and airtime-expensive |
| BACnet Who-Is / I-Am | UDP broadcast on port 47808, local subnet | Effective on wired segments; broadcast-limited at scale |
| Modbus | No discovery mechanism at all | Every address and register map configured by hand |
Where SRP is supported today.
- Thread and OpenThread support SRP natively as the field-layer registration path
- DNS-SD resolution is broadly supported across Android, Windows, Linux, and Apple platforms
- A registrar must exist in the network for registration to have a destination
- Border routers commonly provide the registrar role on Thread deployments
In a building portfolio the practical pattern is that Thread sensors register over SRP, and a gateway republishes those discoveries into the control layer — commonly as BACnet device objects — so the existing BMS sees ordinary points.
Naming is not governance.
SRP establishes that a service exists and how to reach it. It carries no notion of who may consume it, what the data means in operational terms, or what happened when it was changed.
- No access scoping — a DNS record does not know about tenants, owners, or vendors
- No semantic model — a resolvable host name says nothing about what a reading means
- No change record — registration and expiry are not an audit trail
- No composition — two discovered systems still need something to broker their interaction