Discovery and addressing

Device discovery, address assignment and identity verification are separate steps. Validate the advertised service information before using it to establish a connection.

Sources and scopeSource record 25 August 2026

Technical source record: 25 August 2026. Check the linked documentation for current product requirements.

Protocol level guidance; concrete DHCP/DNS schemas, vendor discovery extensions, and inventory authority are deployment specific.

Verification and testing

On this page

Overview#

Discovery answers “what claims to be present?” Addressing answers “where can it be reached?” Neither answers “is this the approved device?” Promote a candidate into inventory only after matching an authenticated product identity, certificate or commissioned secret, expected topology, and asset owner record.

Protocol roles#

Protocol	Purpose	Trust warning
DHCP / DHCPv6	lease addresses and configuration	unauthenticated offers/options can redirect traffic; protect server path
DNS	resolve scoped names to records	use controlled zones and validated update paths; a record is not device authorisation
mDNS / DNS SD	link local name resolution and service advertisement	advertisements are local untrusted input and may reveal capabilities
WS Discovery	SOAP based probe/resolve and announcements, often multicast in ad hoc mode	metadata and endpoint references require validation
LLDP	adjacent link device/port information	useful topology evidence, not authenticated asset identity by default

DHCP for IPv4 is defined by RFC 2131 and DHCPv6 by RFC 8415.¹² DNS architecture and messages are defined by RFCs 1034 and 1035. mDNS and DNS SD are RFCs 6762 and 6763. OASIS WS Discovery 1.1 supports ad hoc multicast discovery and managed discovery through a proxy.³

Inventory binding#

Keep separate fields for asset ID, manufacturer/product/firmware, hardware identifier, certificate/application identity, protocol device ID, DNS name, IP/MAC, switch port/LLDP neighbour, physical location, owner, first/last seen, and evidence source. Addresses and switch ports change; certificate identities can be replaced; product serials can be cloned or misreported. Reconciliation should surface conflict rather than silently overwrite.

Canonicalize names and URIs before comparison but preserve the original value for audit. Bound TXT records, SOAP/XML size/depth, endpoint list size, string length, and response count. Treat metadata as display only unless it passes the exact protocol/schema validator. Don't interpolate discovered strings into shell commands, URLs, paths, logs, or HTML unsafely.

Operational patterns#

Prefer an approved DHCP reservation/IPAM/DNS workflow to hard coded spreadsheets or self assigned defaults.
Restrict dynamic DNS updates to authenticated principals and the intended records.
Constrain multicast scope and discovery VLANs; don't route all discovery traffic enterprise wide.
Add randomized query timing and strict response/rate limits. A broad probe can create a response storm.
Alert when an approved identity changes address unexpectedly, two identities claim one address/name, an unknown service appears, or a device moves switch port.
Preserve last known inventory separately from live discovery state; absence isn't proof of decommissioning.

Validate discovery rate limits, DHCP/DNS conflict handling, multicast scope, LLDP trust boundaries, stale records, and recovery against an authorised target network.

Primary sources#

Section overview · Wiki home