When a printer, development board, speaker, or test service “exists on the LAN” but its app cannot find it, guessing IP addresses wastes time. Start at the discovery layer: prove that mDNS packets reach your interface, identify the advertised DNS-SD type, then resolve the instance to a host and port.

  • mDNS carries DNS-shaped queries and answers over link-local multicast: IPv4 224.0.0.251, IPv6 ff02::fb, UDP port 5353.

  • DNS-SD defines how PTR, SRV, TXT, A, and AAAA records describe discoverable service instances.

  • A PTR browse finds instances/types; SRV supplies target host and port; TXT carries service metadata; A/AAAA resolves the host address.

  • The .local. domain and multicast scope normally stay on one link. Routers do not forward them like ordinary unicast traffic unless an explicit reflector/discovery proxy is deployed.

Install the Ubuntu tools

Terminalbash
sudo apt update
sudo apt install mdns-scan avahi-utils

What this changes

  • apt update refreshes package metadata; it does not upgrade installed packages.

  • apt install adds the small scanner plus Avahi command-line clients from configured Ubuntu repositories.

  • sudo is needed for package management, not for ordinary mdns-scan browsing—UDP 5353 is not a privileged port.

  • avahi-utils provides richer browsing/resolution than the intentionally minimal scanner.

List advertised DNS-SD service types

Terminalbash
mdns-scan
+ _ipp._tcp.local
+ _ssh._tcp.local
+ _http._tcp.local

Read this output correctly

  • The scanner queries the special PTR name _services._dns-sd._udp.local and prints service types, not a complete device inventory.

  • A leading + means a PTR record appeared; observed names depend entirely on your LAN.

  • _ipp._tcp.local identifies a service protocol/type. It does not reveal the printer name, IP, or port by itself.

  • The process scans continuously and does not exit on its own; press Ctrl+C. The sample output is illustrative.

Resolve service instances with Avahi

Terminalbash
avahi-browse --all --resolve --terminate

Why Avahi is usually the useful second step

  • --all browses all service types, --resolve requests host/address/port details, and --terminate exits after the initial complete pass.

  • Resolved records connect the DNS-SD chain: instance PTR → SRV/TXT → target A/AAAA.

  • TXT values are service-defined metadata, not trusted shell input. Never execute or interpolate discovered values blindly.

  • If mdns-scan sees a type but Avahi cannot resolve an instance, inspect responder health, packet loss, address-family behavior, and firewall rules.

Browse one service type without noise

Terminalbash
avahi-browse --resolve --terminate _ssh._tcp

What the filter means

  • _ssh is the registered/application service label and _tcp describes the service transport convention.

  • Filtering reduces unrelated printer, casting, workstation, and IoT advertisements on busy networks.

  • Discovery proves an advertisement exists; it does not authenticate the server or authorize an SSH connection. Verify host keys normally.

Observe mDNS packets on the wire

Terminalbash
sudo tcpdump -ni any udp port 5353

Risk level: caution. Review the command before running it.

How packet capture narrows the fault

  • -n prevents name lookups, -i any observes all Linux capture interfaces, and the filter limits traffic to UDP 5353.

  • Queries without replies suggest no responder, filtering, client isolation, or the wrong link; replies visible here but absent in the app point higher in the resolver/application stack.

  • Capture output can expose device names, services, addresses, and TXT metadata. Store and share it as sensitive network inventory.

  • Ctrl+C stops capture; this command does not modify firewall or network state.

Why no services appear

  • Wrong interface: Ethernet, Wi-Fi, VPN, bridge, and container interfaces may sit on different links.

  • Guest/client isolation: access points often prevent wireless peers from exchanging multicast.

  • VLAN boundary: link-local multicast does not cross routers automatically; deploy a deliberately scoped reflector or RFC 8766 discovery proxy when policy permits.

  • Firewall: allow required inbound/outbound UDP 5353 multicast on the intended trusted interface, not indiscriminately on every zone.

  • Responder absent: the target service may not advertise, may be asleep, or may publish only after configuration.

  • Container/VM networking: NAT and virtual switches commonly suppress multicast; test on the host and inspect network mode.

  • Duplicate names: mDNS responders may rename conflicting hosts or instances. Match SRV/TXT/address data, not only display names.

Security and privacy boundaries

  • Service discovery is an inventory mechanism, not authentication.

  • Advertisements can reveal personal device names, models, capabilities, and internal services to every participant on the link.

  • A malicious peer can advertise deceptive service records; clients must authenticate the actual protocol endpoint.

  • Reflecting mDNS between VLANs expands the trust boundary and multicast load. Allow only justified service types and directions where the implementation supports policy.

  • Do not publish administrative interfaces merely because discovery is convenient.

Primary references

  • RFC 6762 defines Multicast DNS addressing, UDP 5353, link scope, and query/response behavior.

  • RFC 6763 defines DNS-SD instance browsing and PTR/SRV/TXT record relationships.

  • Ubuntu’s mdns-scan man page documents the command, continuous scan, limitations, and debugging-only intent.

  • RFC 8882 describes DNS-SD privacy and security requirements.