Boas práticas e limitações do mDNS no ESP32
O mDNS é extremamente útil, mas precisa ser usado com consciência. Ele resolve muito bem o problema de descoberta local, especialmente em redes simples, mas não deve ser tratado como solução universal para todos os cenários de comunicação. Em sistemas embarcados, cada recurso adicionado ao firmware deve ser justificado, porque memória, processamento, energia, estabilidade e previsibilidade continuam sendo fatores importantes.
A primeira boa prática é definir nomes claros e previsíveis. Um hostname como:
esp32-sensor.local
é melhor do que algo genérico como:
esp32.local
Em uma bancada com vários dispositivos, nomes genéricos rapidamente causam confusão. O ideal é usar um padrão que indique função, local ou número lógico do equipamento:
esp32-temp-01.local
esp32-gateway-lab.local
esp32-rele-sala01.local
esp32-vib-motor02.local
A segunda boa prática é evitar conflitos de nome. Se dois dispositivos tentarem usar o mesmo hostname na mesma rede, o comportamento pode se tornar confuso para o usuário e para aplicações clientes. Em produtos comerciais, uma solução comum é incluir parte do endereço MAC no hostname, como:
esp32-sensor-a1b2c3.local
Isso melhora a unicidade sem exigir configuração manual. Porém, para a interface do usuário, podemos manter um nome amigável separado usando mdns_instance_name_set(), por exemplo:
Sensor de Temperatura da Sala
Assim, o nome técnico pode ser único, enquanto o nome exibido ao usuário pode ser mais legível.
A terceira boa prática é anunciar apenas serviços realmente ativos. Se o ESP32 anuncia _http._tcp na porta 80, o servidor HTTP deve estar em execução. Se o firmware anuncia _sensor._tcp na porta 8080, a API do sensor deve responder corretamente. Anunciar serviços indisponíveis cria uma falsa expectativa para os clientes da rede. Por isso, em uma aplicação mais rigorosa, a ordem recomendada é iniciar primeiro o serviço real e depois registrá-lo no mDNS.
A quarta boa prática é usar registros TXT com moderação. Eles são úteis para indicar versão do firmware, tipo do dispositivo, rota base da API e capacidades gerais, mas não devem virar um banco de dados. Também não devem conter informações sensíveis. O mDNS foi projetado para descoberta local, não para segredo. Portanto, não publique senhas, tokens, chaves privadas, credenciais de API ou dados pessoais em registros TXT.
Um conjunto TXT aceitável seria:
static const mdns_txt_item_t service_txt_data[] = {
{"device_type", "sensor"},
{"fw_version", "1.0.0"},
{"api", "/api/v1"},
{"cap", "temperature"}
};
Um conjunto inadequado seria:
static const mdns_txt_item_t service_txt_data[] = {
{"wifi_password", "minha_senha"},
{"admin_token", "123456"},
{"private_key", "conteudo_secreto"}
};
Mesmo em uma rede local, esse tipo de dado não deve ser anunciado. Segurança precisa ser tratada em outra camada, com autenticação, autorização, pareamento, chaves conhecidas, TLS quando for viável e validação no protocolo da aplicação.
Outra limitação importante é que o mDNS depende de multicast local. Em redes domésticas simples, normalmente funciona bem. Em redes corporativas, escolas, universidades, hotéis, ambientes industriais ou redes com VLANs, o tráfego multicast pode ser filtrado. Alguns roteadores também possuem isolamento entre clientes Wi-Fi, impedindo que um dispositivo sem fio veja outro. Nesse caso, o ESP32 pode estar funcionando perfeitamente, mas esp32-sensor.local não resolverá no computador ou no celular.
Esse ponto é importante para suporte técnico. Quando o usuário diz “não consigo acessar .local”, o problema nem sempre está no firmware. Pode estar na rede. Um teste simples é verificar se o computador e o ESP32 estão na mesma rede, se conseguem se comunicar por IP e se o roteador permite multicast entre os clientes.
Também é importante lembrar que o sufixo .local pertence ao contexto de resolução local. O endereço:
esp32-sensor.local
não é um domínio público da internet. Ele não deve ser usado como se fosse um domínio registrado. O mDNS foi pensado para redes locais, e não para descoberta remota pela internet.
Do ponto de vista de desempenho, o mDNS adiciona algum consumo de memória e processamento, embora normalmente seja aceitável no ESP32 para aplicações comuns. O impacto depende do restante do firmware. Se o projeto já usa Wi-Fi, HTTP, MQTT, TLS, OTA, filas FreeRTOS e buffers grandes, cada componente adicional precisa ser avaliado com cuidado. Essa preocupação é coerente com o desenvolvimento embarcado: sistemas embarcados costumam ter restrições severas de recursos, e o projeto precisa equilibrar funcionalidade, custo, desempenho e robustez.
Em aplicações alimentadas por bateria, também é preciso pensar no modo de operação. Um dispositivo que entra em deep sleep frequentemente não ficará anunciando mDNS o tempo todo. Ele só poderá responder enquanto estiver acordado, conectado ao Wi-Fi e com a pilha de rede ativa. Para sensores de baixíssimo consumo que acordam apenas para medir e enviar dados, talvez o mDNS não seja a melhor estratégia principal de descoberta contínua.
Nesses casos, o mDNS pode ser útil apenas durante provisionamento ou manutenção. Por exemplo, o ESP32 acorda em modo configuração, anuncia esp32-config.local, permite que o usuário configure Wi-Fi ou parâmetros do sistema, e depois entra em operação normal com baixo consumo. Esse uso é muito comum e prático.
Há também situações em que o mDNS não é a melhor escolha. Se o sistema precisa ser acessado pela internet, o mDNS não resolve. Se os dispositivos estão em redes diferentes, o mDNS pode não atravessar roteadores. Se a rede é altamente controlada, talvez seja melhor usar um servidor DNS interno, IP fixo, DHCP reservation, MQTT broker, CoAP resource directory ou algum serviço central de registro.
Podemos resumir a decisão assim: use mDNS quando o problema for descoberta simples dentro da rede local. Evite depender exclusivamente dele quando o sistema exigir descoberta entre redes, acesso remoto, segurança forte ou operação contínua em ambientes corporativos restritivos.
A boa arquitetura é tratar o mDNS como uma camada auxiliar. Ele ajuda a encontrar o dispositivo, mas não deve ser o único mecanismo de controle, autenticação ou gerenciamento. Depois que o cliente descobre o ESP32, a aplicação deve validar quem ele é, qual API oferece, qual versão executa e se está autorizado a participar do sistema.
