Resumo

  • O rascunho individual de Changshan Su propõe registros DNS-SD na rede local para localizar gateways de IA e descrever caminhos e recursos anunciados.
  • O serviço descoberto é um “endpoint candidato”: a confiança precisa vir antes de qualquer solicitação ou credencial.

Encontrar uma impressora na rede não exige uma audiência para decidir quem ela é. Encontrar um gateway de IA traz uma pergunta bem mais cara: quem pode receber a chave que vai pagar a próxima chamada?

Em 26 de outubro de 2026, Changshan Su submeteu a versão 00 de “DNS-Based Service Discovery for AI Gateways” como Internet-Draft individual. O Datatracker o lista como proposta individual, sem fluxo de RFC ou status de RFC pretendido. _ai-gateway._tcp é um nome de serviço proposto; o próprio texto diz que ele ainda não tem atribuição da IANA.

A base técnica usa peças conhecidas. O DNS-Based Service Discovery usa um registro PTR para listar uma instância, SRV para indicar host e porta TCP, TXT para dados específicos do serviço, e A ou AAAA para informar o endereço do host. Su propõe um vocabulário compacto para o caminho de montagem do gateway, a segurança do transporte, a exigência de autenticação e os protocolos anunciados. Assim, o cliente lê o que o serviço declara oferecer sem gravar um endereço fixo na configuração.

O espaço é pequeno por projeto: o rascunho espera que o TXT padrão fique abaixo de 200 bytes e limita o registro completo a 400. Um anúncio pode carregar nome, porta, caminho e algumas declarações. Não cabe uma constituição ali; mais bytes tampouco dariam poder de decisão ao registro.

O termo que merece atenção é “endpoint candidato”. O cliente analisou um registro, mas ainda não confiou na máquina nem aprovou o envio de credenciais. A sequência proposta é navegar, resolver, validar, conectar, confirmar a confiança e só então enviar uma solicitação. Consultar o catálogo de modelos é opcional. A chave de API fica fora do TXT.

A ordem importa porque a rede local deixa máquinas anunciarem presença; ela não funciona como tribunal para decidir quem pode gastar o segredo de outra pessoa. A seção de segurança diz que alguém no mesmo segmento pode forjar um anúncio mDNS, declarar auth=0 ou apontar o registro SRV para um host sob seu controle. O id anunciado não comprova identidade. O cliente precisa da confirmação do usuário, de uma regra de confiança configurada ou da verificação da identidade TLS do servidor. Uma chave reutilizável não deve trafegar por HTTP ou WebSocket sem criptografia, salvo aprovação explícita para aquele ambiente local confiável.

Um anúncio novo em texto claro também não pode rebaixar um gateway já confiável em HTTPS ou WSS.

A RFC 6763 dá ao DNS-SD uma tarefa direta: localizar instâncias nomeadas de um serviço. A RFC 6762 descreve o mDNS no enlace local e diz que a resolução de conflitos de nomes pressupõe participantes cooperativos. Nenhuma das duas tarefas entrega à máquina descoberta o direito de usar as credenciais do cliente. A campainha pode avisar “gateway aqui”. Quem tem a chave ainda decide se abre.

A separação útil é esta: descoberta localiza; a identidade TLS ajuda a verificar qual servidor respondeu; a regra do cliente decide se aquele servidor pode receber um segredo. Se as três decisões virarem uma luz verde de “encontrado”, a ficha de diretório terá virado uma autorização. O rascunho deixa a decisão adicional visível para usuário ou administrador.

A evidência disponível é uma especificação, não um relato de campo: o Datatracker mostra apenas um rascunho individual -00. O material consultado não contém teste de interoperabilidade, comparação de implementações nem números de implantação; um relatório de teste primário mudaria qualquer afirmação sobre adoção. Por enquanto, vale observar a interface entre as três decisões. Se o cliente pedir aprovação, deve mostrar host, porta, caminho, estado TLS e exigência de autenticação que estão em jogo. “Gateway encontrado” é resultado de busca. “Esta máquina pode usar minha chave” é autorização.

Fontes