Resumo

  • O primeiro rascunho ULD do grupo DNSSD estabelece uma escolha determinística de servidor por enlace e manda o cliente registrar novamente todos os seus serviços quando migra para outro servidor.
  • O comprovante necessário não é apenas o resultado da preferência. Ele deve ligar o servidor antigo ao novo, registrar a causa da troca e conciliar o conjunto esperado com aceitações, recusas, conflitos, leases, publicação por proxy e eventual retorno ao mDNS.

Uma transição pode funcionar e ainda perder algo

Considere uma oficina com impressoras, terminais e controladores anunciados apenas no enlace local. Surge um servidor de infraestrutura ULD com prioridade maior que a opção ad hoc existente. Os clientes convergem para ele. Três equipamentos voltam imediatamente; um controlador não aparece para o tablet IPv4 usado no chão de fábrica. O servidor novo está no ar e foi escolhido conforme a regra. O inventário, porém, não é o mesmo.

draft-ietf-dnssd-uld-00, de 18 de agosto de 2026, é um Internet-Draft ativo do grupo DNSSD da IETF. A proposta de Unicast Local Discovery reúne registro SRP e consultas DNS unicast, mantendo uma ponte com dispositivos mDNS. O documento pretende seguir o Standards Track e atualizaria a RFC 6762 se fosse aprovado. Ainda não é uma RFC e conserva itens em aberto nas seções de segurança, de roteadores SNAC e de alocação IANA.

O serviço ULD contém cinco peças lógicas. O registrador SRP grava anúncios em uma zona .local; o servidor autoritativo responde às consultas; o Discovery Proxy acrescenta o que ouviu por mDNS; e o Advertising Proxy apresenta ao lado mDNS o que entrou por SRP. Para registros compartilhados, a resposta costuma juntar a zona autoritativa e a visão do proxy.

Essa composição é útil, mas impede que uma simples consulta positiva prove continuidade. O registro pode estar na zona e não ter sido refletido como esperado. Pode estar visível para IPv6 e faltar a um cliente IPv4. Pode haver uma entrada antiga no cache enquanto a nova inscrição falhou. Disponibilidade do servidor e integridade do catálogo são grandezas diferentes.

O mecanismo escolhe; o cliente recompõe

Cada servidor anuncia uma chave pri. O menor valor vence. A infraestrutura usa prioridade 0; servidores ad hoc recebem faixas mais altas conforme capacidade e tipo de enlace. Empates são resolvidos pelo menor endereço IPv6 link-local em valor numérico. Um servidor de infraestrutura também publica uma opção ULD em Router Advertisements IPv6.

Em redes administradas, o operador precisa habilitar explicitamente a designação de infraestrutura e garantir que apenas um roteador por enlace anuncie essa opção. Em uma casa, o roteador de borda pode assumir a função por padrão quando já é a infraestrutura de fato. Um equipamento que não seja claramente o gateway principal não deve reivindicar o papel sem configuração explícita.

O cliente procura primeiro a infraestrutura. Sem ela, escolhe entre servidores ad hoc; sem candidato viável, retorna ao mDNS. Depois que adota ULD, deve deixar de participar diretamente do mDNS naquele enlace e passar as operações .local ao servidor preferido.

Essa preferência precisa ser revista. Falhas persistentes de consulta, de renovação do lease SRP ou da sessão DNS Push fazem o cliente reiniciar a descoberta. Quem está em um servidor ad hoc também continua procurando uma alternativa superior. Quando a escolha muda, seja por falha ou pela chegada de um candidato melhor, o cliente deve registrar novamente todos os seus serviços no destino.

O apêndice C explica a opção por convergência. Vários registradores independentes podem aceitar o mesmo nome e deixar que o conflito apareça apenas no mDNS, sem retorno correto aos clientes. ULD escolhe levar todos ao mesmo servidor, em vez de exigir replicação entre servidores. Isso reduz o problema de estado dividido, mas não transporta automaticamente os registros anteriores.

Um rascunho expirado de SRP Replication mostra o caminho alternativo. Ele buscava conservar estado entre parceiros e evitar que certos failovers exigissem nova inscrição do cliente. Não é parte da ULD atual. No desenho de revisão 00, é o cliente que percebe a mudança e reconstrói o que possui.

O inventário esperado é a linha de base

Um retorno de sucesso do SRP informa que uma atualização foi aceita. Não informa quantas outras deveriam ter sido enviadas. Contar registros no servidor novo também não resolve o problema se ninguém fixou o total esperado antes da mudança.

O recibo começa pelo escopo: enlace, interface, família de endereços e intervalo de observação. Uma máquina multihomed pode usar ULD em uma interface e mDNS em outra. Marcar o dispositivo inteiro como “migrado” mistura transições independentes.

Depois vêm os participantes: endereços link-local do servidor anterior e do novo, valor pri, classe infraestrutura ou ad hoc e critério de desempate. A causa precisa ser classificada: indisponibilidade persistente, renovação de lease que falhou, sessão push perdida, aparecimento de servidor mais prioritário ou ação administrativa.

Também é necessário registrar a procedência do papel. Em rede gerida, qual alteração autorizou o novo servidor de infraestrutura? Em casa, quais sinais demonstravam que o equipamento era o gateway efetivo? A opção RA e a política RA Guard dão evidência sobre o anúncio, mas não equivalem a autenticar o servidor. O rascunho aceita certificado autoassinado, recomenda que o cliente não o rejeite e afirma que a autenticação não é o objetivo desse TLS oportunista.

O núcleo é a reconciliação. Antes de sair, o cliente pode formar um digest das descrições normalizadas que pretende reapresentar. Depois, registra para cada serviço se houve aceitação, recusa, conflito, timeout, lease concedido e nova tentativa. O servidor fornece um resumo compatível da zona. Consultas de validação comparam a resposta unicast, a contribuição do Discovery Proxy e a saída mDNS do Advertising Proxy.

IPv4 e IPv6 devem ser observados separadamente. A descoberta de infraestrutura por RA é IPv6; um cliente somente IPv4 procura servidores por mDNS e pode voltar a ele se o preferido não for alcançável por IPv4. Um teste dual-stack bem-sucedido não cobre automaticamente esse caso.

Serviço retirado de propósito, nome alterado por conflito, inscrição pendente e fallback são resultados diferentes. Todos podem ser legítimos, mas não podem desaparecer em uma contagem agregada de sucesso.

Continuidade não autoriza vigilância permanente

Nomes locais podem expor pessoas, salas, modelos de aparelhos e hábitos. Um histórico central completo criaria um risco de privacidade desnecessário.

É possível provar a comparação com menos dados: digest salgado das descrições, contagem por categorias amplas, códigos de exceção e duração. A lista integral e o sal permanecem por pouco tempo no cliente ou em ambiente operacional restrito. O registro durável guarda o identificador da troca, os totais, as diferenças e um compromisso criptográfico que impede a alteração posterior da linha de base.

O prazo de retenção deve cobrir expiração de leases, renovação de caches e relatos tardios. Depois disso, nomes sem utilidade para investigação devem ser apagados. O objetivo é comprovar uma passagem, não manter um catálogo histórico da vida local.

Limites da evidência atual

O rascunho separa claramente eleição e re-registro, mas não especifica o recibo proposto neste artigo. Não há, no conjunto consultado, métricas públicas de perda, tempo de recuperação ou interoperabilidade multivendor.

A RFC 7113 descreve limites de RA Guard. O uso de chaves e SIG(0) no SRP protege a posse de um registro, não a completude de um conjunto transferido. A autoridade da zona ULD fica dentro de .local e do enlace; não é delegação sobre o DNS global.

A conclusão operacional cabe em uma pergunta: todos os serviços esperados voltaram, foram retirados intencionalmente ou falharam de modo visível? Enquanto a resposta não estiver registrada, a eleição terminou, mas a troca ainda não.

Fontes

  1. Rascunho ULD vigente
  2. Histórico do documento
  3. Revisão 00 em HTML
  4. Revisão 00 em texto
  5. API do Datatracker
  6. Repositório de trabalho DNSSD
  7. Apresentação ULD na IETF 126
  8. Carta do grupo DNSSD
  9. RFC 6762 — Multicast DNS
  10. RFC 6763 — DNS-Based Service Discovery
  11. RFC 9665 — Service Registration Protocol
  12. RFC 8766 — Discovery Proxy
  13. RFC 8765 — DNS Push Notifications
  14. RFC 8490 — DNS Stateful Operations
  15. RFC 6105 — RA Guard
  16. RFC 7113 — Orientações para RA Guard
  17. RFC 4861 — Neighbor Discovery no IPv6
  18. Rascunho Advertising Proxy
  19. Rascunho Time Since Received
  20. Rascunho expirado de SRP Replication