Resumo

  • Em 18 de agosto, o Datatracker registrou a aprovação de draft-ietf-dnssd-uld-00 como documento do grupo DNSSD. A versão substitui o rascunho individual, mas não altera seu corpo técnico.
  • O ULD reúne registro SRP, DNS autoritativo e proxies em um servidor preferencial do enlace. A proposta tenta reduzir o custo de mDNS no Wi-Fi, embora a seção de segurança ainda esteja vazia.

Uma mudança de nome pode ser uma notícia institucional sem ser uma revisão de protocolo. Esse é o caso do Unicast Local Discovery.

O histórico da nova versão registra no mesmo instante — 16h22min50s UTC de 18 de agosto — a aprovação do -00, a publicação do arquivo e a indicação de que ele substitui draft-tlmk-infra-dnssd. Depois de remover identificação, datas, prazo, endereço do repositório e cabeçalhos repetidos, os textos têm o mesmo hash. O fato novo é que o DNSSD assumiu a responsabilidade pelo desenvolvimento, não que o mecanismo tenha mudado naquele dia.

O caminho até essa decisão também está documentado. Segundo o histórico do antecessor, uma adoção foi inicialmente lançada após uma demonstração de mãos na sessão da IETF 126. O presidente depois reverteu o passo, reconhecendo que deveria ter feito antes uma chamada na lista de discussão. A chamada foi aberta em 21 de julho e o estado “Adopted by a WG” chegou em 6 de agosto. A correção torna a decisão auditável; não transforma a adoção em aprovação do texto final.

O rascunho de 17 páginas começa com um problema operacional específico. No mDNS, cada dispositivo que anuncia um serviço escuta e responde a multicast. Em Wi-Fi, esses quadros não recebem confirmação nem retransmissão na camada MAC, não são guardados pelo ponto de acesso para estações adormecidas e usam uma taxa obrigatória baixa. Um aparelho a bateria precisa acordar repetidamente ou aceitar a perda de consultas, e o multicast ocupa mais tempo de rádio que o unicast equivalente.

O ULD coloca um serviço intermediário no enlace. Um servidor combina registrador SRP, DNS autoritativo, Discovery Proxy e Advertising Proxy. O cliente compatível registra seus serviços nesse ponto e envia consultas .local por unicast. Quando o servidor está disponível, o cliente deixa de participar rotineiramente do mDNS naquele enlace, enquanto os proxies mantêm comunicação com equipamentos legados.

A proposta empacota componentes já definidos. O RFC 9665 especifica o Service Registration Protocol, incluindo atualizações e concessões de registro. O RFC 8766 especifica o Discovery Proxy, que responde consultas DNS unicast a partir de informações coletadas em enlaces mDNS. O ULD acrescenta descoberta, preferência e migração para que o conjunto funcione como um único serviço local.

Isso não remove o RFC 6762, base do Multicast DNS. O rascunho diz que o atualizaria se fosse aprovado, mas continua usando mDNS para anunciar servidores, alcançar dispositivos sem ULD e oferecer fallback quando nenhum servidor funciona. A proposta pretende retirar o cliente compatível do fluxo multicast cotidiano, não desativar a compatibilidade instalada.

O papel preferencial precisa de governança de rede. Em ambiente administrado, o operador configura explicitamente qual equipamento é o servidor de infraestrutura, e no máximo um deve anunciar a opção ULD em Router Advertisements no mesmo enlace. Servidores improvisados podem existir com prioridade menor. Clientes continuam procurando uma escolha melhor, detectam falhas persistentes e registram novamente todos os serviços após a troca.

Há um motivo para convergir em um único ponto. Dois servidores independentes podem aceitar o mesmo nome para dispositivos diferentes, deixando o conflito aparecer apenas depois na camada multicast e sem uma resposta útil para quem registrou. O desenho evita exigir replicação entre todos os servidores e escolhe uma regra determinística de preferência. Ele substitui uma disputa distribuída por dependências explícitas de seleção, disponibilidade e transferência de estado.

O sinal de autoridade muda entre pilhas. Em IPv6, o servidor de infraestrutura também usa uma opção de RA; o cliente deve descobri-lo ou verificar por essa opção uma alegação recebida por DNS-SD, permitindo proteção com RA Guard. Um cliente apenas IPv4 encontra todos os servidores por mDNS. Ao receber uma consulta .local em IPv4, o servidor precisa verificar se a origem pertence a uma sub-rede conectada diretamente.

Ainda faltam respostas essenciais. A seção Security Considerations contém somente TODO. A parte sobre roteadores SNAC também não foi escrita, e a solicitação à IANA mantém um nome de serviço provisório. Não existe no material publicado um relatório de implementação independente, teste de interoperabilidade, medição de bateria, ocupação de rádio, taxa de perda ou tempo de recuperação. É uma Internet-Draft, não um RFC.

O mandato do DNSSD explica a tensão de fundo: mDNS é amplamente usado, mas sua limitação ao enlace não atende sozinho redes roteadas e com múltiplos enlaces; ampliar a descoberta cria preocupações de segurança e privacidade. O ULD começa no enlace local, porém o servidor escolhido pode influenciar a visão de serviços de cada cliente. A análise de confiança é, portanto, parte do mecanismo.

A adoção inaugura uma etapa pública e estável de trabalho. Não confirma um RFC, uma implantação ou um ganho. A afirmação responsável é menor: a IETF decidiu desenvolver uma alternativa unicast para parte da descoberta local, e agora precisa provar que o ponto preferencial economiza recursos sem tornar falhas ou autoridade menos visíveis.

Fontes