Guia LivSmart
Protocolo

mDNS

5353/UDP, 224.0.0.251 e FF02::FB caracterizam o mDNS definido pela RFC 6762. Ele resolve nomes `.local.` e publica registros no enlace sem servidor DNS central. Em casa inteligente, trabalha com DNS-SD da RFC 6763 para descobrir HomeKit, Matter, impressoras e serviços locais. A implantação exige multicast funcional na mesma sub-rede ou proxy específico entre VLANs. A limitação é exposição de nomes e serviços, além de baixo alcance: roteadores não encaminham esse multicast por padrão.

📖Definição aprofundada

mDNS é uma adaptação do formato e da semântica do DNS para resolução e anúncio de nomes em uma rede local sem servidor DNS convencional. Em vez de enviar uma consulta unicast a um resolvedor, o host envia mensagens para o grupo multicast IPv4 224.0.0.251 ou IPv6 FF02::FB, na porta UDP 5353. Os participantes no mesmo enlace escutam e respondem. Nomes terminados em `.local.` são o caso mais conhecido. Um computador pode anunciar `homeassistant.local.`, uma impressora `printer.local.` e um dispositivo Matter registros associados ao serviço. A RFC 6762, publicada em fevereiro de 2013, define o protocolo. DNS-SD, RFC 6763, define como usar registros PTR, SRV, TXT e A/AAAA para descobrir instâncias de serviço. As tecnologias são complementares: mDNS transporta consultas DNS por multicast; DNS-SD organiza a descoberta. Bonjour, da Apple, é uma implementação e ecossistema, não outro protocolo. Avahi é uma implementação comum em Linux. O responder precisa realizar probing antes de assumir um nome, detectar conflitos e renomear quando necessário. Isso evita que dois dispositivos usem o mesmo host name. Anúncios e respostas podem ser enviados de forma espontânea para atualizar caches. TTLs e cache reduzem tráfego. O campo cache-flush ajuda substituir registros exclusivos. Consultas podem ser one-shot ou contínuas, permitindo acompanhar entrada e saída de serviços. Em casa inteligente, mDNS é usado por HomeKit, AirPlay, Chromecast em partes de descoberta, Matter, impressoras e aplicações locais. Um controlador procura `_hap._tcp.local.`, `_matter._tcp.local.` ou outro tipo e recebe instâncias. O registro SRV fornece host e porta. TXT contém atributos. A conexão real pode ser TCP, UDP, HTTP, QUIC ou protocolo específico. Encontrar não autentica. O cliente ainda deve parear, verificar certificado ou token. A principal limitação operacional é o escopo de enlace. VLANs e sub-redes separam o multicast. Uma rede IoT segmentada pode impedir Home Assistant de descobrir dispositivos. Um mDNS reflector, repeater ou Discovery Proxy pode encaminhar seletivamente. Abrir multicast indiscriminadamente reduz isolamento. RFC 8766 define Discovery Proxy para DNS-SD em redes roteadas. RFC 9665 define Service Registration Protocol, útil em Thread e redes onde multicast é ineficiente. A privacidade é um problema. RFC 8882 descreve como DNS-SD sobre mDNS expõe identidades e serviços. Nomes podem revelar pessoas, modelos e cômodos. Redes de convidados não devem receber anúncios internos. Wi‑Fi transmite multicast em taxa básica e pode consumir airtime. Access points usam multicast-to-unicast, IGMP/MLD snooping ou otimizações. Configurações que bloqueiam multicast quebram descoberta. O diagnóstico usa `dns-sd`, `avahi-browse`, `mdns-scan`, Wireshark e `tcpdump udp port 5353`. O firewall deve permitir apenas nas interfaces necessárias. mDNS não substitui DNS corporativo, DHCP, roteamento ou segurança. É uma ferramenta zero-configuration de alcance local.

Arquitetura e Funcionamento
Endereços, porta e escopo
Todo nó mDNS usa UDP 5353. Em IPv4, envia para 224.0.0.251; em IPv6, para FF02::FB. O escopo é link-local. O TTL IP deve ajudar a impedir encaminhamento indevido. Um pacote recebido de outra rede pode ser descartado conforme regras. Isso limita o domínio de falha e tráfego. Em VLANs, cada interface possui grupo separado. Um reflector recebe numa interface e retransmite noutra, mas precisa evitar loops e filtrar. A consequência prática é que mover o Home Assistant para uma VLAN de servidores pode fazer dispositivos “sumirem” da descoberta embora continuem acessíveis por IP. Configurar rota não basta; multicast precisa de proxy ou registro DNS-SD unicast.
Probing, conflitos e nomes `.local.`
Antes de anunciar um nome único, o host envia probes para verificar se já existe. Se houver conflito, aplica desempate ou escolhe outro nome. Por isso dois dispositivos `camera.local` podem virar `camera-2.local`. Aplicações não devem depender de nome humano fixo sem armazenamento do identificador. Registros exclusivos usam cache-flush para substituir versões antigas. Um dispositivo que muda IP anuncia. Ao sair de forma limpa, pode enviar goodbye com TTL zero. Queda abrupta depende da expiração de cache. Nomes `.local.` devem ser consultados por mDNS, não enviados ao DNS público. VPNs e resolvers corporativos podem ter conflitos de namespace. O sistema operacional define precedência. Diagnóstico precisa observar interface e sufixo.
DNS-SD e registros de serviço
DNS-SD usa PTR para enumerar instâncias de um tipo, SRV para apontar host e porta, TXT para metadados e A/AAAA para endereços. `_http._tcp.local.` anuncia servidores HTTP. Uma instância pode chamar `Home Assistant._home-assistant._tcp.local.`. O cliente não deve confiar em todo TXT; valida tamanho e conteúdo. Dados sensíveis não devem ser publicados. O registro informa capacidade e endpoint, mas não autorização. Matter usa descoberta para commissioning e operação em fases definidas. HomeKit usa `_hap._tcp`. Serviços podem possuir subtipos. A descoberta contínua atualiza. Quando existem centenas de dispositivos, multicast cresce. Discovery Proxy e SRP ajudam escalar. O tipo de serviço deve ser registrado e consistente para interoperabilidade.
Segurança, privacidade e segmentação
Qualquer nó no enlace pode observar consultas e anúncios. Isso revela nomes de host, serviços, modelos e às vezes identificadores. Um atacante pode anunciar serviço falso. O cliente precisa autenticar no protocolo posterior. Não usar mDNS como prova de identidade. VLAN de convidados deve ser isolada. Um reflector deve permitir apenas tipos necessários, como `_hap._tcp` ou `_matter._tcp`, e apenas entre interfaces autorizadas. Bloquear anúncios de impressora ou AirPlay quando não necessários. Firewalls não expõem UDP 5353 na WAN. Atualizar Avahi, Bonjour e firmware. Rate limiting e limites de registros evitam abuso. Em redes públicas, desativar compartilhamento. Para privacidade, nomes genéricos são melhores que nomes de pessoas e endereços. O cache também pode reter. Reiniciar serviço limpa, mas não corrige arquitetura.
Análise Técnica
✓ Vantagens
  • Elimina a necessidade de configurar servidor DNS para nomes e serviços locais, acelerando instalação de dispositivos e controladores.
  • Usa formato e registros DNS padronizados, permitindo interoperabilidade entre Apple Bonjour, Avahi, Matter, HomeKit e outras implementações.
  • Detecta conflitos de nome automaticamente e atualiza caches quando endereços ou serviços mudam.
  • Funciona sobre IPv4 e IPv6 e pode descobrir endpoints TCP ou UDP sem depender do transporte usado pela aplicação.
  • É simples para redes pequenas e oferece experiência plug-and-play, reduzindo suporte e configuração manual.
✗ Desvantagens
  • Fica restrito ao enlace; VLANs e sub-redes exigem reflector, proxy ou DNS-SD unicast, aumentando complexidade.
  • Expõe nomes, tipos de serviço e metadados a todos os participantes do segmento, criando riscos de privacidade e enumeração.
  • Multicast pode consumir airtime em Wi‑Fi e escalar mal com muitos dispositivos ou anúncios frequentes.
  • Não autentica dispositivos nem serviços; anúncios falsos são possíveis e a segurança precisa ocorrer no protocolo posterior.
  • Implementações, firewalls, VPNs e otimizações de access point podem bloquear ou alterar multicast, causando falhas intermitentes.
💡 Cenário Prático: mDNS entre VLAN IoT e Home Assistant
O Home Assistant fica numa VLAN de servidores e os dispositivos numa VLAN IoT. O firewall permite conexões de controle somente do servidor para a IoT. Para descoberta, um mDNS reflector ou Avahi com interfaces explícitas retransmite os tipos necessários. Não se habilita reflexão para convidados. Regras evitam loops. O access point mantém multicast funcional e usa otimização quando disponível. O controlador armazena identificadores dos dispositivos depois do pareamento; não depende para sempre de nomes `.local`. Serviços Matter e HomeKit são descobertos, mas a sessão é autenticada pelo protocolo. O DNS interno contém nomes estáveis para servidores. Logs e captura em UDP 5353 verificam anúncios. Nomes não incluem sobrenome do morador nem endereço. Se a rede cresce, um Discovery Proxy ou SRP é preferido a refletir tudo. A porta 5353 nunca é encaminhada para a Internet. Um dispositivo não descoberto pode ser adicionado por IP apenas quando o protocolo permite, mas o problema de multicast deve ser corrigido para commissioning e atualização de serviços.