Resumo

  • Em 3 de setembro de 2026, o IESG abriu a revisão comunitária de uma proposta de recharter para o DNSSD, com comentários até 13 de setembro. O próprio aviso informa que nenhuma decisão foi tomada.
  • O escopo proposto inclui publicar nomes registrados por SRP em mDNS e resolver atualizações concorrentes para o mesmo nome. O rascunho TSR, previsto para WGLC em novembro, ajuda a reconhecer uma cópia obsoleta mantida por outro proxy. Ele não torna mDNS seguro, privado ou capaz de provar que o endpoint funciona.

Considere dois caminhos de publicação para um único serviço. No primeiro, o dispositivo envia um SRP Update a um registrador que também anuncia os registros em mDNS. Depois de uma partição ou mudança de anycast, a atualização seguinte chega a outro registrador. O endereço mudou. O proxy original ainda anuncia a versão anterior.

O algoritmo local vê dois conjuntos incompatíveis para o mesmo nome. A regra usual favorece o anúncio mais antigo. Isso é sensato quando duas máquinas falam em nome próprio: quem chega depois não deve substituir silenciosamente um serviço já presente. Com proxies, porém, o anúncio antigo pode ser apenas uma fotografia vencida da mesma fonte.

O aviso do IESG abriu em 3 de setembro a análise de um novo charter para o DNSSD. A proposta trata de descoberta escalável em um ou vários links, publicação de registros SRP por mDNS e conflitos entre atualizações do mesmo nome. O prazo de comentários é 13 de setembro, e o IESG diz expressamente que ainda não decidiu.

Essa frase não é formalidade. Recharter em consulta não é recharter aprovado. O marco de WGLC em novembro não significa consenso alcançado. O Datatracker do TSR lista a revisão 03 como Internet-Draft ativo em Standards Track, não como RFC. O pedido futuro de um código EDNS não é uma alocação já feita pela IANA.

A arquitetura começa com RFC 6762. O mDNS resolve nomes no link sem um servidor de autoridade único, ao contrário da delegação do DNS tradicional em RFC 1034. O protocolo sonda, detecta colisões e protege anúncios existentes. RFC 6763 usa registros DNS para oferecer descoberta de serviços.

Em seguida surgem pontes. RFC 8766 define um Discovery Proxy capaz de levar serviços aprendidos via mDNS ao DNS unicast. RFC 9665 define o SRP, com atualizações vinculadas à chave do solicitante. O Advertising Proxy em elaboração permite que o registrador publique os registros SRP de volta no link mDNS.

O intermediário muda a semântica da presença. O dispositivo é a origem dos dados; o registrador os aceita; o proxy os projeta. Se a projeção antiga permanece depois que a origem escolheu outro registrador, sua duração no link não lhe concede maior autoridade.

O texto da revisão 03 propõe uma opção EDNS Time Since Received para cada owner name. Ela referencia o conjunto de registros, inclui um checksum relacionado à chave pública do solicitante e transporta o tempo transcorrido desde o recebimento. Cada nó reconstrói uma base local para comparar as gerações.

O checksum ajuda a separar fontes; o tempo ajuda a ordenar versões da mesma fonte. Assim, a informação recebida pelo segundo registrador pode prevalecer sem parecer uma apropriação do nome. O mecanismo também busca evitar probes e respostas duplicadas, renomeações artificiais e goodbyes capazes de retirar uma cópia que ainda é válida por outro caminho.

Há casos difíceis. Proxies redundantes podem indicar papéis primário e secundário para controlar respostas. Um dispositivo multihomed pode anunciar diretamente em uma rede e via SRP em outra. Latência, reinício e descontinuidade de relógio interferem no cálculo. A implementação precisa guardar a época e a associação de origem, não apenas exibir “mais recente”.

RFC 6891 dá a estrutura extensível do EDNS. Compartilhar o formato permite interoperabilidade. Não prova que o estado persistente, o relógio, o cache ou a retirada estejam corretos em um produto específico.

O limite de segurança é ainda mais importante. O próprio TSR diz que um host malicioso no mesmo link pode disputar conflitos. Sem TSR, ele já pode anunciar dados incompatíveis e responder ao probe para negar serviço. A proposta não torna mDNS seguro ou privado. Autenticação, autorização e sigilo precisam vir da aplicação ou de descoberta com DNSSEC quando cabível.

A dimensão de privacidade aparece em RFC 8882. Anúncios revelam dispositivos, serviços e atividade. Ao atravessar links, uma informação correta chega a uma audiência maior. O registro mais novo ainda pode estar no domínio administrativo errado.

Uma operação auditável deve preservar identidade e chave do solicitante, SRP Update original, registrador, proxy, owner name, RRset completo, momento de recebimento, base do relógio, checksum, offset TSR, probes, conflito, escolha, renomeação e goodbyes. A cadeia continua no cliente: resposta recebida, destino usado, conexão, autenticação de aplicação e resultado visível.

Um passo não antecipa o próximo. O registrador ter aceitado a atualização não prova que todos os proxies apagaram a antiga. TSR escolher um RRset não prova alcance. Abrir conexão não prova identidade. Autenticar o serviço não prova que caches remotos deixaram de oferecer o endereço anterior.

A retirada percorre o caminho inverso. Remover estado no registrador, observar as projeções, manter cópias redundantes ainda válidas, aguardar TTLs e confirmar que o endpoint antigo deixou de receber tráfego. Um painel vazio no controlador não encerra o fato se a resposta antiga ainda circula.

A especificação inicial mínima de Heng Lu sugere compartilhar somente a informação necessária para coordenação. As camadas da realidade impedem que recência, identidade e resultado se confundam. A primazia do código em execução exige verificar a resposta e a experiência real.

O recharter do DNSSD identifica uma mudança de autoridade provocada pela escala. Um proxy torna o serviço visível além do seu primeiro link, mas também separa quem fala de quem sabe. TSR pode ordenar as cópias. A confiança continua sendo uma decisão independente, sustentada por outro conjunto de provas.

Fontes