Что такое mDNS?
Работает это так. Каждый сервис описывается именем вида _тип._транспорт.local. Например:
_http._tcp.local — HTTP-серверы_ipp._tcp.local — принтеры (Internet Printing Protocol)_airplay._tcp.local — устройства AirPlay_esphomelib._tcp.local — устройства ESPHome_googlecast._tcp.local — устройства Google Cast (Chromecast)_mqtt._tcp.local — MQTT-брокерыЧтобы найти все сервисы определённого типа, клиент отправляет мультикаст-запрос PTR-записи для нужного типа. В ответ приходит список конкретных экземпляров. Далее через SRV-запись можно узнать хост и порт сервиса, через TXT-запись — дополнительные метаданные (версия прошивки, MAC-адрес, поддерживаемые возможности), а через A/AAAA-запись — IP-адрес.
Есть даже специальный мета-запрос _services._dns-sd._udp.local, который возвращает список всех типов сервисов, доступных в сети. Одна команда — и вы видите полную картину.
mDNS — это стандарт, а конкретные реализации различаются в зависимости от платформы.
Apple Bonjour — первая и наиболее зрелая реализация. Apple начала поставлять mDNS в macOS ещё в 2002 году (Mac OS X 10.2), задолго до публикации RFC. Именно Apple — основной драйвер всей технологии. На macOS и iOS Bonjour работает из коробки и отвечает за обнаружение AirPrint-принтеров, AirPlay-устройств, AirDrop и многого другого. Для Windows существует Bonjour SDK, хотя его установка требуется всё реже.
Avahi — свободная реализация mDNS/DNS-SD под лицензией LGPL, ставшая стандартом де-факто в мире Linux. Входит в большинство дистрибутивов. Именно Avahi обычно отвечает за разрешение имён .local на Raspberry Pi, серверах Home Assistant, NAS-устройствах под Linux.
Windows 10/11 — начиная с версии 1703, Windows имеет встроенную поддержку mDNS (без установки Bonjour). Ранние версии использовали его ограниченно — только для обнаружения принтеров, экранов, беспроводных колонок. Более поздние редакции (с 1903) поддерживают полноценное разрешение хостнеймов. При этом на системах с systemd-resolved (современные Linux-дистрибутивы) разрешение mDNS может обрабатываться без Avahi — самим systemd.
ESP8266/ESP32 — микроконтроллеры Espressif, на которых строится огромная часть DIY-устройств для умного дома, имеют встроенную поддержку mDNS в своих SDK. ESPHome использует её по умолчанию.
В контексте домашней автоматизации mDNS — не просто удобство. Для многих систем это критически важный механизм.
Home Assistant использует mDNS (через интеграцию Zeroconf) для автоматического обнаружения устройств в сети. Когда вы прошиваете новый ESP32 через ESPHome, он при старте отправляет mDNS-анонс с типом сервиса _esphomelib._tcp.local. Home Assistant ловит этот анонс и предлагает добавить устройство — без ввода IP-адресов, без сканирования сети.
Если mDNS отключён или не работает (типичная ситуация при VLAN-сегментации), ESPHome-устройства перестают автоматически обнаруживаться. Связь с ними возможна только по статическому IP. Многие пользователи Home Assistant сталкивались с ситуацией, когда устройства показываются как «offline» в панели ESPHome, хотя прекрасно пингуются — это почти всегда проблема с mDNS.
Любой сетевой принтер с поддержкой AirPrint (а это практически все современные модели) использует mDNS/DNS-SD для анонсирования себя в сети. Когда вы открываете диалог печати на iPhone или MacBook и видите список доступных принтеров — это работает DNS-SD поверх mDNS.
Устройства Google Chromecast анонсируют себя через _googlecast._tcp.local. Приложения на телефоне обнаруживают их по mDNS и предлагают транслировать контент. AirPlay работает аналогично — через _airplay._tcp.local и _raop._tcp.local.
Homebridge — мост между устройствами, не поддерживающими Apple HomeKit, и экосистемой Apple — полностью полагается на mDNS для обнаружения. Без работающего mDNS приложение «Дом» на iPhone просто не увидит мост.
Если ваш MQTT-брокер (Mosquitto, EMQX) настроен на анонсирование через mDNS, клиенты могут находить его автоматически по _mqtt._tcp.local. Это упрощает конфигурацию IoT-устройств — не нужно хардкодить IP-адрес брокера.
При всей элегантности mDNS — протокол не без проблем. Вот основные.
Это, пожалуй, самое важное ограничение. mDNS использует link-local мультикаст — пакеты не маршрутизируются между подсетями. Если ваш Home Assistant в одном VLAN, а ESPHome-устройства в другом — они друг друга не найдут.
Решения есть: mDNS-рефлектор (например, в Avahi — опция enable-reflector=yes), mDNS-шлюз на уровне управляемого коммутатора или роутера (OpenWrt, Ubiquiti, pfSense), или отказ от автообнаружения в пользу статических IP. Каждый вариант имеет свои компромиссы. Рефлектор увеличивает мультикаст-трафик. Отказ от mDNS — убивает удобство.
Если вы сегментируете сеть на VLAN (IoT-устройства отдельно, основная сеть отдельно — это правильная практика), заранее продумайте, как mDNS будет работать между сегментами.
Если в вашей сети есть DNS-сервер, который обслуживает зону .local — будут проблемы. Часть запросов уйдёт на DNS-сервер, часть в мультикаст. Результат непредсказуем. Решение одно: не использовать .local для традиционного DNS. Это зарезервированный домен, и лучше его не трогать.
Практическая проблема, знакомая пользователям ESPHome: устройства на базе ESP32 иногда «выпадают» из mDNS — перестают отвечать на запросы, хотя работают и доступны по IP. Связано это с особенностями реализации mDNS-стека в ESP-IDF. ESP8266, как ни странно, ведёт себя стабильнее. Проблема известна, обсуждается в сообществе, но полностью не решена. Обходной путь — назначать статические IP (или статические DHCP-lease) и не полагаться исключительно на mDNS для связи.
mDNS не предусматривает аутентификации. Любое устройство в сети может объявить себя кем угодно. Злоумышленник, попавший в локальную сеть, может подменить mDNS-ответ (mDNS spoofing) и перенаправить трафик на себя. Инструменты для такой атаки существуют и хорошо документированы — Responder, bettercap с модулем zerogod.
Для домашней сети это не самая актуальная угроза (злоумышленнику нужно сначала попасть в вашу локалку), но в корпоративных средах mDNS-трафик обычно ограничивают или вовсе блокируют. В домашних условиях разумная мера — сегментация сети: IoT-устройства в отдельном VLAN, доступ между сегментами — только через файрвол.
Если что-то не работает (устройство не обнаруживается, имя не резолвится), полезно уметь заглянуть «под капот».
Просмотр всех сервисов в сети:
avahi-browse -aПоиск конкретного типа сервиса с разрешением адресов:
avahi-browse --resolve _esphomelib._tcpРазрешение имени:
avahi-resolve -n mydevice.localПросмотр всех сервисов:
dns-sd -B _services._dns-sd._udp local.Поиск конкретных сервисов:
dns-sd -B _ipp._tcp local.Разрешение имени:
dns-sd -G v4 mydevice.localДля базовой проверки достаточно пинга:
ping mydevice.localЕсли имя не резолвится, а устройство точно в сети — проблема с mDNS. Более детальная диагностика возможна с помощью Bonjour SDK (утилита dns-sd.exe) или Wireshark с фильтром mdns.
Фильтр для просмотра mDNS-трафика:
mdnsИли более детально:
udp.port == 5353Вы увидите все запросы и ответы в сети. Это самый надёжный способ понять, что происходит: кто спрашивает, кто отвечает, какие записи анонсируются.
В домашней сети параллельно работают несколько механизмов обнаружения. Их легко спутать.
mDNS/DNS-SD — разрешение имён и обнаружение сервисов. Работает через мультикаст-DNS на порту 5353/UDP. Используется Apple Bonjour, Avahi, ESPHome, Home Assistant, Chromecast, AirPlay, AirPrint.
UPnP/SSDP — обнаружение устройств и управление ими (включая проброс портов). Работает через HTTP/SOAP и SSDP на порту 1900/UDP. Используется DLNA, Windows для обнаружения медиаустройств, игровыми консолями.
NetBIOS / LLMNR — устаревшие протоколы обнаружения, оставшиеся от Windows. NetBIOS работает на порту 137/UDP, LLMNR — на 5355/UDP. Microsoft постепенно отказывается от них в пользу mDNS.
mDNS и UPnP/SSDP — не конкуренты, а скорее параллельные решения для разных задач. mDNS хорош для разрешения имён и обнаружения сервисов по типу. SSDP — для обнаружения сложных устройств с XML-описанием возможностей и управления ими через SOAP. В домашней сети они прекрасно сосуществуют.
Не отключайте mDNS без необходимости. Для большинства сценариев умного дома mDNS — основной механизм обнаружения. Без него ESPHome, Chromecast, AirPlay, принтеры и многое другое перестанут автоматически находиться.
Не используйте .local для своего DNS-сервера. Это зарезервированный домен. Для внутреннего DNS берите .lan, .home.arpa (рекомендация из RFC 8375) или поддомен реального домена.
При сегментации на VLAN — настройте mDNS-рефлектор. Без него устройства из разных VLAN не найдут друг друга. Avahi с опцией enable-reflector=yes — самый простой вариант. На OpenWrt, pfSense и Ubiquiti есть соответствующие настройки.
Для ESPHome-устройств — назначайте статические DHCP-lease. Это страховка на случай, если mDNS «заглючит». Home Assistant сможет подключиться к устройству по IP, даже если mDNS не работает.
Убедитесь, что порт 5353/UDP не блокируется файрволом. На роутерах с агрессивными правилами файрвола мультикаст-трафик может быть заблокирован. Проверьте, что мультикаст-группа 224.0.0.251 доступна для всех устройств в нужных сегментах.
Следите за мультикаст-трафиком. В большой сети с десятками IoT-устройств mDNS-трафик может стать заметным. Если устройства анонсируют себя слишком часто — это повод проверить их конфигурацию.
mDNS — один из тех протоколов, которые работают настолько незаметно, что о них вспоминают только когда они ломаются. А ломаются они чаще всего из-за VLAN-сегментации, проблем с мультикастом или конфликтов с доменом .local.
В контексте умного дома mDNS — фундаментальная вещь. Без него автообнаружение ESPHome-устройств, поиск Chromecast, печать через AirPrint и десятки других «оно просто работает»-сценариев превращаются в ручную конфигурацию с IP-адресами. Протокол простой, открытый, стандартизированный и поддерживается всеми основными платформами. Просто убедитесь, что он не заблокирован вашей сетевой инфраструктурой — и он будет тихо делать свою работу.
Материал носит информационно-образовательный характер и не является рекламой конкретных производителей или продуктов.