DNS and IoT

The internet of things has a DNS problem. Or more precisely, it has several DNS problems: devices that bypass your resolver, devices that make DNS queries without any concept of network security, devices that become attack infrastructure because they were connected to a public resolver, and the fundamental tension between "plug-and-play convenience" and "controlled, observable network behavior."

Understanding IoT DNS starts with understanding that most IoT devices weren't designed by people who thought carefully about DNS.

mDNS and DNS-SD: local discovery without a server

Before getting to the security problems, it's worth understanding why IoT devices use a different DNS mechanism in the first place.

Traditional DNS requires a server. In a home or small office network, you don't necessarily have a DNS server running — you have a router that forwards queries upstream. mDNS (Multicast DNS, RFC 6762) solves local device discovery without any central server.

How it works: when a device wants to find a local service, it sends a multicast UDP query to 224.0.0.251:5353. Other devices on the same subnet that provide that service respond directly. No server needed.

mDNS uses .local as the pseudo-TLD. Your printer might advertise itself as hp-laserjet.local. Your Mac's AirDrop and Bonjour use this.

DNS-SD (DNS-based Service Discovery, RFC 6763) builds on top of mDNS. It lets devices advertise and discover services using DNS record types — PTR, SRV, and TXT records:

# PTR: service discovery index
_http._tcp.local.  PTR  mydevice._http._tcp.local.

# SRV: where to connect
mydevice._http._tcp.local.  SRV  0 0 80 mydevice.local.

# TXT: metadata
mydevice._http._tcp.local.  TXT  "path=/" "version=2.1"

You can query mDNS manually:

# List services on the local network
dns-sd -B _http._tcp local
avahi-browse -a  # Linux alternative

# Look up a specific host
dns-sd -G v4v6 mydevice.local

The scope problem

mDNS is strictly link-local. It doesn't cross routers. This is by design — it limits the blast radius. But it also means that in a segmented network (office floors, VLANs, etc.), devices on different segments can't discover each other via mDNS.

Apple's implementation (Bonjour) adds a bridge daemon called mDNSResponder that can proxy mDNS across subnets. Avahi does something similar on Linux. These are reasonable solutions for specific use cases, but they start introducing the complexity that mDNS was designed to avoid.

The security reality of IoT DNS

IoT devices make DNS queries. They query for cloud service endpoints (firmware update servers, telemetry collection endpoints, MQTT brokers). They often use whatever resolver the DHCP server provides. Many of them hardcode fallback resolvers — 8.8.8.8, 1.1.1.1 — to ensure they work even when the local resolver is broken or filtered.

That hardcoded fallback is a real problem for enterprise and security-conscious networks. If you're running split DNS to serve internal hostnames, and a device ignores your resolver in favor of a hardcoded public one, it will fail to resolve internal names. Worse, it bypasses any DNS filtering you've put in place.

Mirai and open resolvers

The 2016 Mirai botnet attack is the most visible example of what happens when IoT security fails at scale. Mirai infected hundreds of thousands of IoT devices — primarily IP cameras, DVRs, and routers — using default factory credentials.

The largest Mirai DDoS attacks targeted DNS infrastructure directly. The October 2016 attack on Dyn took down DNS resolution for major services (Twitter, Reddit, Netflix, GitHub) for most of a day. The attack traffic hit approximately 1.2 Tbps — not from servers, from DVRs and webcams.

The DNS angle: many of those devices were configured to query open resolvers, and the malware weaponized their DNS query capability for amplification attacks. DNS amplification works because a small query can generate a large response. A 40-byte query for a zone with a large ANY response can return 3,000+ bytes — a 75x amplification factor.

Open resolvers — DNS servers that accept queries from any source IP — are the enabler. Properly configured resolvers only accept queries from authorized networks. But factory-default IoT device firmware often assumes an open resolver is available.

The practical upshot: if you operate any DNS infrastructure, make sure your resolvers are not open to the internet. This isn't new advice, but IoT made the consequences much more severe.

Split DNS for IoT networks

The standard approach for IoT security at the network level is segmentation: put IoT devices on a separate VLAN with their own DNS resolver.

That IoT resolver can:

Block DNS queries to known malicious domains (via RPZ or DNS blocklists)
Block DNS queries to known C2 infrastructure
Forward legitimate queries upstream while logging all query traffic
Prevent devices from reaching hardcoded public resolvers (firewall rules blocking port 53 to anything except your resolver)

A common setup:

IoT VLAN (192.168.10.0/24)
  └── IoT resolver: 192.168.10.1
       ├── Blocks: malware domains, known IoT C2 lists
       ├── Allows: required cloud endpoints (device vendor APIs)
       └── Logs: all queries to SIEM

Corporate VLAN (192.168.1.0/24)
  └── Corporate resolver: 192.168.1.1
       ├── Internal zones
       └── Split DNS for internal services

The firewall rule that matters:

# Block IoT devices from using any resolver other than yours
iptables -I FORWARD -s 192.168.10.0/24 -p udp --dport 53 ! -d 192.168.10.1 -j DROP
iptables -I FORWARD -s 192.168.10.0/24 -p tcp --dport 53 ! -d 192.168.10.1 -j DROP

What smart home DNS looks like under the hood

A modern smart home with 30-50 devices is querying DNS constantly. A thermostat checks in with its cloud service every few minutes. Smart bulbs ping their bridge. TVs make DNS queries for streaming service endpoints and telemetry on every startup and channel change.

If you run a Pi-hole or AdGuard Home on your home network, you can see this. The query volume is surprising. Some devices make hundreds of queries per hour. Many of those go to first-party analytics and telemetry endpoints.

The mDNS traffic adds another layer. Apple devices are particularly chatty — mDNS queries for AirDrop discovery, AirPlay targets, HomeKit accessories. This is all link-local and doesn't traverse your router, but it's visible at the network interface level.

For engineers running home labs: the combination of Pi-hole for upstream DNS filtering plus a dedicated IoT VLAN with firewall rules is the practical setup. It's not enterprise-grade, but it gives you visibility and control that the default router-as-resolver setup doesn't.

Key takeaways

mDNS enables local discovery without a server; it's strictly link-local and uses .local as the TLD
IoT devices often hardcode public resolver IPs as fallback, bypassing your DNS filtering
Mirai demonstrated that insecure IoT devices at scale can take down DNS infrastructure
Network segmentation with a dedicated IoT resolver is the standard defense
Log all DNS queries from IoT segments — the query pattern often reveals compromise before other indicators

Up next

Lesson 03: Blockchain and Decentralized DNS — What Handshake, ENS, and Unstoppable Domains are actually trying to solve, and where they fall short.