Kristian Glass - Do I Smell Burning?

Mostly technical things

Handling .local hostnames - multicast DNS

DNS is great. Having to remember IP addresses sucks.

Being able to plug in a device to my home network, give it a name, then be able to reach it as $name.local? That’s great. (One day I’ll set up local authoritative DNS but realistically that’s unlikely to happen soon)

How does that work though? And what do you do when it doesn’t?

Multicast DNS!

There are numerous introductions to “regular” DNS, like this one from DigitalOcean.

Roughly, to look up something conventional like foo.bar.example.com., your computer will ask its local DNS server (which might be your home router, your ISP’s DNS server, or something like Google Public DNS at 8.8.8.8), which might ask some other upstream DNS server, which might continue until something eventually contacts authoritative DNS servers, and eventually you get a response. Each node along the way will cache results in an attempt to reduce the number of underlying requests needed.

For domains ending in .local, it’s slightly different:

Any DNS query for a name ending with ".local." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB)

The exact semantics are laid out fully in RFC 6762 but what you’re most likely to encounter on a home network is this: you send out a query for $name.local to a local-network-only multicast IP, everything else on the network is (ideally) listening, if that includes $name, then it responds with its IP.

With Linux, there’s a reasonable chance you’ll be running Avahi (the avahi-daemon package on Debian), so e.g. you can find a vanilla Raspbian install at raspberrypi.local. With macOS and iOS you’re probably running Bonjour. On Windows, you may have a tougher time…

Comments