Project 16: mDNS/Bonjour Service Discovery

A tool that discovers local services advertised via mDNS and DNS-SD.

Quick Reference

Attribute	Value
Difficulty	Level 2: Intermediate
Time Estimate	Week
Main Programming Language	Python
Alternative Programming Languages	Go, Rust, C
Coolness Level	Level 3: Genuinely Clever
Business Potential	2. The “Micro-SaaS / Pro Tool”
Prerequisites	See concepts below
Key Topics	Naming and Configuration Services (DNS, DHCP, mDNS), Link Layer and LAN Behavior (Ethernet, Wi-Fi, ARP, Switching)

1. Learning Objectives

Build and validate: A tool that discovers local services advertised via mDNS and DNS-SD..
Explain protocol behavior and verify it with a capture or trace.
Handle edge cases and produce reproducible results.

2. All Theory Needed (Per-Concept Breakdown)

Naming and Configuration Services (DNS, DHCP, mDNS)

Fundamentals Before a connection happens, a device needs two things: an address configuration and a name-to-address mapping. DHCP provides configuration: IP address, subnet mask, default gateway, and DNS servers. DNS provides name resolution: it turns a human-friendly name into IP addresses. On small local networks without an authoritative DNS server, mDNS and DNS-SD allow devices to discover services on the local link. These services are essential because users do not type IP addresses and devices do not manually configure themselves in modern networks.

Deep Dive DNS is a hierarchical distributed database. When a client needs to resolve a name, it asks a recursive resolver (often provided by the ISP or a local router). The resolver performs iterative queries starting at the root, then the TLD, then the authoritative server for the zone. Responses are cached according to TTL values. This caching is why DNS queries can be fast, and also why changes can take time to propagate. DNS responses can arrive over UDP for small messages or TCP for larger responses or zone transfers. Understanding this distinction matters for debugging, since UDP truncation forces a TCP retry.

DHCP follows a discover-offer-request-acknowledge (DORA) exchange. A client with no address broadcasts a DHCPDISCOVER. A server replies with a DHCPOFFER. The client requests the offered address with DHCPREQUEST, and the server confirms with DHCPACK. Leases are time-limited and periodically renewed. This system allows dynamic reuse of addresses and centralized configuration. But it also introduces failure modes: multiple DHCP servers can fight, leases can expire if the server is unreachable, and clients can receive inconsistent options (like a wrong default gateway) that make the network appear partially broken.

mDNS and DNS-SD provide zero-configuration discovery. Instead of contacting a DNS server, devices send multicast queries to a well-known address on the local link. This allows discovery of printers, media devices, and local services without manual setup. The protocol reuses DNS message formats but changes the transport and scope. mDNS is powerful for home networks but can become noisy in larger environments. Understanding the scope and TTL settings for mDNS is essential when diagnosing why a device appears in a discovery list but is not reachable, or why service lists change frequently.

Naming and configuration services also intersect with security. DNS can be spoofed if you trust the wrong resolver or if a local attacker injects responses. DHCP can be abused by rogue servers. This is why managed networks often implement DHCP snooping and DNS security mechanisms. In home networks, the threat model is different, but the failure modes are similar. A misbehaving IoT device running a DHCP server can cause intermittent failures that look like random internet drops.

Finally, these services are the backbone of usability. When DNS or DHCP fails, users perceive that “the internet is down,” even if the physical link is fine. Your ability to build a DNS resolver or DHCP server from scratch is a demonstration that you truly understand how network configuration and naming work. It also makes you capable of implementing local overrides like DNS sinkholes, which are highly practical for security and ad-blocking.

How this fit on projects Projects 5-8, 10, and 16 are direct applications of DNS, DHCP, and mDNS.

Definitions & key terms

Resolver: The client-side DNS component that asks questions.
Recursive resolver: DNS server that walks the hierarchy on behalf of clients.
TTL: Time-to-live for cached DNS answers.
Lease: The time a DHCP address is valid.
mDNS: Multicast DNS on a local link.

Mental model diagram

Client -> Resolver -> Root -> TLD -> Authoritative
          ^ cache TTLs at each step

How it works

Client obtains an IP address and DNS server via DHCP.
Client asks resolver for a name.
Resolver walks the DNS hierarchy and caches answers.
Local devices use mDNS for link-local discovery. Invariants: DNS is cached and hierarchical. Failure modes: rogue DHCP, stale DNS cache, mDNS storms.

Minimal concrete example

DNS query/response (text):
Query: A example.com
Answer: example.com -> 93.184.216.34 (TTL 86400)

Common misconceptions

“DNS is always real-time.” It is cached by design.
“DHCP only gives IP addresses.” It also provides gateway and DNS servers.

Check-your-understanding questions

Why might a DNS change take hours to show up?
What happens if a DHCP lease expires and the server is down?

Check-your-understanding answers

Cached answers remain valid until TTL expires.
The client may lose connectivity or fall back to a self-assigned address.

Real-world applications

Local ad-blocking via DNS sinkholes.
Zero-configuration printer discovery.

Where you will apply it

Projects 5-8, 10, 16

References

RFC 1034/1035 (DNS), RFC 2131 (DHCP)
RFC 6762/6763 (mDNS, DNS-SD)

Key insights Naming and configuration are invisible until they fail, then everything fails.

Summary DNS and DHCP are the core control plane of a home network.

Homework/Exercises to practice the concept

Trace a DNS lookup from your device to the authoritative server.
Capture a DHCP DORA exchange and label each step.

Solutions to the homework/exercises

Use dig +trace and note each delegation.
Filter UDP ports 67 and 68 and identify discover, offer, request, ack.

Link Layer and LAN Behavior (Ethernet, Wi-Fi, ARP, Switching)

Fundamentals The link layer is the realm of MAC addresses, frames, and local delivery. It is responsible for getting data from one device to another device on the same local network segment. Ethernet and Wi-Fi are the most common link layers in home and office networks. Ethernet uses switches that learn where MAC addresses live and forward frames to the correct port. Wi-Fi is a shared medium where devices contend for airtime and associate with an access point, which then bridges traffic to the wired LAN. ARP (Address Resolution Protocol) is the bridge between IP and MAC addresses, allowing an IP address to be mapped to a link-layer destination. The link layer defines the boundaries of broadcast domains, which strongly influences performance and security.

Deep Dive The link layer is the place where “local” really means local. A switch builds a table of MAC address to port mappings by observing the source MAC of incoming frames. When it sees a destination MAC it does not know, it floods the frame out all ports (except the one it arrived on). Over time, this learning behavior makes forwarding efficient, but it also creates risks like MAC table overflow or broadcast storms if the network is poorly segmented. Unlike routers, switches do not understand IP addresses; they only see MACs and EtherType values. This is why ARP is necessary. When a host wants to send to an IP on the same subnet, it broadcasts an ARP request asking who owns that IP, and the owner replies with its MAC. That reply is cached for a limited time. If the cache is stale, ARP traffic increases and devices appear to “mysteriously” fail or slow down.

Wi-Fi adds complexity because the medium is shared and half-duplex. Devices must contend for airtime, and interference or poor signal quality can cause retransmissions that look like packet loss at higher layers. An access point is effectively a bridge between the Wi-Fi link and the wired Ethernet LAN. When you see a device “connected” but unable to reach the internet, the cause could be at the association layer (link) rather than at IP or DNS. Another subtlety is that Wi-Fi uses different frame formats and encryption (WPA2/WPA3) to protect frames on the air. This encryption is per-link, not end-to-end. Once a frame leaves the access point and enters the wired LAN, that Wi-Fi encryption no longer applies.

VLANs are a link-layer technique for segmentation. They allow multiple logical networks to share the same physical switch by tagging frames. In a home/office setting, VLANs are used to separate guest networks or IoT devices from trusted devices. This is a key security and performance tool, but it requires that all participating switches and access points handle VLAN tags correctly. Misconfigured VLAN tagging leads to symptoms like DHCP working on one SSID but not another, or devices that can access the router but not other devices.

Understanding link-layer behavior is essential for building scanners and sniffers. A packet sniffer on a wired switch port sees only the frames destined for that port unless you use port mirroring. On Wi-Fi, you might need monitor mode to see frames not destined for your device. This is a practical limitation that affects how you validate your tools. It is also why many network tools appear to “miss” traffic when run on the wrong interface or in the wrong capture mode.

Finally, link-layer security is not the same as network-layer security. ARP has no authentication, which is why ARP spoofing is possible. Wi-Fi encryption does not prevent a malicious device from joining the network if the passphrase is weak. If you understand the link layer, you can explain and detect these risks with concrete evidence, such as duplicate IP address warnings or sudden changes in ARP cache entries.

How this fit on projects Projects 1, 4, 12, 15, and 18 force you to understand ARP, frames, and capture limitations.

Definitions & key terms

MAC address: A link-layer identifier used for local delivery.
Frame: The unit of data at the link layer.
ARP: Protocol that maps IP addresses to MAC addresses on a LAN.
Broadcast domain: The scope of a link-layer broadcast.
VLAN: A logical segmentation of a link layer.

Mental model diagram

Device A        Switch          Device B
AA:AA           CAM Table       BB:BB
  |                |              |
  | ARP who-has?   | flood        |
  |--------------->|------------->|
  |                | ARP reply    |
  |<---------------|<-------------|
  | data frame     | unicast      |

How it works

Host wants to send to IP in same subnet.
Host broadcasts ARP request for target IP.
Target replies with its MAC address.
Host caches mapping and sends frames directly. Invariants: ARP traffic does not cross routers. Failure modes: ARP cache poisoning, switch flooding, weak Wi-Fi encryption.

Minimal concrete example

ARP exchange (text):
Request: Who has 192.168.1.50? Tell 192.168.1.10
Reply: 192.168.1.50 is at 00:11:22:33:44:55

Common misconceptions

“Switches block broadcasts.” Switches forward broadcasts to all ports.
“Wi-Fi is just wireless Ethernet.” The medium behavior and security differ.

Check-your-understanding questions

Why does ARP not work across subnets?
What does a switch do with an unknown destination MAC?

Check-your-understanding answers

ARP requests are link-local broadcasts; routers do not forward them.
It floods the frame out all ports except the ingress port.

Real-world applications

Diagnosing why a device is visible but not reachable.
Segmenting IoT devices with VLANs and guest Wi-Fi.

Where you will apply it

Projects 1, 4, 12, 15, 18

References

“TCP/IP Illustrated, Vol 1” by Stevens - Ch. 2, 4
RFC 826 (ARP)

Key insights The link layer is the truth of local delivery; everything else is built on it.

Summary Mastering ARP, MACs, and switching gives you real control over your LAN behavior.

Homework/Exercises to practice the concept

Map your own ARP cache and identify every device.
Draw your network and mark the broadcast domain boundaries.

Solutions to the homework/exercises

Use arp -a and compare with your router client list.
Each router boundary separates a broadcast domain.

3. Project Specification

3.1 What You Will Build

A tool that discovers local services advertised via mDNS and DNS-SD.

Included:

CLI tool with clear output
Validation steps and logging
Documentation of assumptions

Excluded:

Production-grade performance tuning
Full security hardening

3.2 Functional Requirements

Core function: Implement the primary behavior described in the project goal.
Observable output: Produce deterministic output comparable to the Real World Outcome.
Error handling: Handle timeouts, invalid inputs, and unreachable hosts gracefully.

3.3 Non-Functional Requirements

Performance: Complete typical tasks within a few seconds on a LAN.
Reliability: Fail safely and clearly on errors.
Usability: Provide concise CLI flags and helpful messages.

3.4 Example Usage / Output

$ ./mdns_discover
Service: _airplay._tcp.local  Host: livingroom.local  Port: 7000
Service: _printer._tcp.local  Host: office-printer.local  Port: 9100
Service: _ssh._tcp.local      Host: nas.local  Port: 22

3.5 Data Formats / Schemas / Protocols

Protocols: Naming and Configuration Services (DNS, DHCP, mDNS), Link Layer and LAN Behavior (Ethernet, Wi-Fi, ARP, Switching).

3.6 Edge Cases

Target unreachable or timing out
Malformed or unexpected responses
Multiple interfaces or subnets

3.7 Real World Outcome

$ ./mdns_discover
Service: _airplay._tcp.local  Host: livingroom.local  Port: 7000
Service: _printer._tcp.local  Host: office-printer.local  Port: 9100
Service: _ssh._tcp.local      Host: nas.local  Port: 22

3.7.1 How to Run (Copy/Paste)

Build: make (or create a virtual environment as needed)
Run: ./P16-mdns-service-discovery
Config: update any constants in a config file or flags
Working directory: project root

3.7.2 Golden Path Demo (Deterministic)

Run against a known local target and compare with the expected output.

3.7.3 If CLI: provide an exact terminal transcript

$ ./mdns_discover
Service: _airplay._tcp.local  Host: livingroom.local  Port: 7000
Service: _printer._tcp.local  Host: office-printer.local  Port: 9100
Service: _ssh._tcp.local      Host: nas.local  Port: 22

4. Solution Architecture

4.1 High-Level Design

CLI Input -> Core Engine -> Output/Logs

4.2 Key Components

Component	Responsibility	Key Decisions
CLI Parser	Parse flags and inputs	Keep interface minimal
Core Engine	Protocol logic and state	Keep deterministic timing
Output/Logs	Present results and errors	Use consistent formatting

4.4 Data Structures (No Full Code)

Request:
  - target
  - protocol fields
Response:
  - status
  - timing
State:
  - retries
  - cache entries

5. Implementation Guide

5.1 Development Environment Setup

Ensure required tools (tcpdump, dig, ip) are installed.
Use elevated privileges where raw sockets are required.

5.2 Project Structure

project/
  README.md
  docs/
  src/
  tests/
  data/

5.3 The Core Question You’re Answering

“How do devices find each other on a LAN without manual configuration?”

5.4 Concepts You Must Understand First

Multicast addresses
- How does multicast differ from broadcast?
- Book Reference: “Computer Networks” - Ch. 4
mDNS packet format
- How is it different from standard DNS?
- Book Reference: RFC 6762
Service discovery (DNS-SD)
- How are services described and announced?
- Book Reference: RFC 6763

5.5 Questions to Guide Your Design

Query strategy
- How often should you send queries without flooding?
Result caching
- How long do you keep service records?

5.6 Thinking Exercise

Service naming

Design a service record for a local file server.

Questions to answer:

What service type should you use?
What TXT records should be included?

5.7 The Interview Questions They’ll Ask

“What problem does mDNS solve?”
“Why does mDNS use multicast instead of unicast?”
“What is DNS-SD and how is it related to mDNS?”
“How can mDNS traffic become a problem at scale?”
“How does service caching work in mDNS?”

5.8 Hints in Layers

Hint 1: Start by listening only Observe existing services before sending queries.

Hint 2: Use known service types Start with _ssh._tcp or _http._tcp.

Hint 3: Pseudocode outline

- join mDNS multicast group
- send query for service type
- parse responses and print instances

Hint 4: Verification Compare results with dns-sd -B _ssh._tcp (macOS) or avahi-browse (Linux).

5.9 Books That Will Help

Topic	Book	Chapter
Multicast	“Computer Networks”	Ch. 4
mDNS	RFC 6762	Spec
DNS-SD	RFC 6763	Spec

5.10 Implementation Phases

Establish core protocol I/O and a minimal success path.
Add parsing, validation, and timeouts.
Add logging, metrics, and polish for output.

5.11 Key Implementation Decisions

Which interface and capture point provides visibility?
What timeout and retry strategy balances speed and accuracy?
How will results be validated against reference tools?

6. Testing Strategy

6.1 Test Categories

Unit: parsing and validation logic
Integration: protocol exchange with a real device
System: full run with reference tools

6.2 Critical Test Cases

Successful request/response path
Timeout and retry behavior
Invalid or unexpected input handling

6.3 Test Data

Local gateway IP and a known reachable host
A non-routable IP to trigger timeouts

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Problem 1: “No services found”

Why: Not joined to multicast group or wrong interface.
Fix: Verify multicast membership and interface selection.
Quick test: Use a known discovery tool and compare.

Problem 2: “Too much noise”

Why: Subnet has many mDNS speakers.
Fix: Filter by service type and suppress duplicates.
Quick test: Add a short deduplication window.

7.2 Debugging Strategies

Capture traffic with tcpdump or Wireshark.
Compare against a known-good tool.
Log timestamps and retry logic.

7.3 Performance Traps

Excessive retries causing long runtimes.
Inefficient parsing under high packet rates.

8. Extensions & Challenges

8.1 Beginner Extensions

Add basic configuration flags for interface and timeout.
Improve output formatting and sorting.

8.2 Intermediate Extensions

Add caching or state persistence.
Add CSV or JSON output export.

8.3 Advanced Extensions

Add concurrency with careful rate limiting.
Add visualization or integration with a dashboard.

9. Real-World Connections

9.1 Industry Applications

Network diagnostics and troubleshooting
Security monitoring and policy enforcement

tcpdump / Wireshark
nmap / dnsmasq / unbound (as applicable)

9.3 Interview Relevance

Explaining protocol behavior
Diagnosing failures by layer

10. Resources

10.1 Essential Reading

Topic	Book	Chapter
Multicast	“Computer Networks”	Ch. 4
mDNS	RFC 6762	Spec
DNS-SD	RFC 6763	Spec

10.2 Video Resources

Wireshark or tcpdump walkthroughs (search for recent tutorials)
Vendor or RFC explainers for the relevant protocol

10.3 Tools & Documentation

RFCs for the protocols used in this project
man tcpdump, man ip, man ss