Summary

  • Na sessão Database da RIPE 93, em 29 de outubro de 2026, Kaveh Ranjbar propôs que titulares possam receber consultas RDAP sobre recursos mais específicos em servidores próprios. Pediu análise de impacto e discussão no grupo; a sessão não aprovou a implantação.
  • Leo Vegoda gostou da direção, mas cobrou duas verificações: o serviço delegado precisa continuar disponível e responder da mesma forma à RIPE NCC e a qualquer outro cliente. Era a descrição de um risco de respostas seletivas, sem relato de abuso ocorrido.

A porta do registro leva a outra mesa

A descrição oficial da palestra diz que uma busca RDAP pode parar no objeto mais específico guardado pela RIPE NCC. Se o titular mantém detalhes abaixo dele, não há hoje uma indicação descobrível que leve o cliente ao serviço do titular. Ranjbar sugeriu quatro peças voluntárias: registrar a URL RDAP no objeto de cobertura, redirecionar consultas subordinadas, acrescentar um link de delegação e validar continuamente o serviço, retirando o encaminhamento quando ele falhar.

Isso permitiria que os dados detalhados fossem publicados perto de quem os mantém, em vez de copiados em massa para a base central e deixados envelhecer. O custo da conveniência é uma mudança de autoria. O usuário chega pela resposta da RIPE NCC, mas a informação seguinte vem de uma máquina administrada pelo titular. A seta do registro empresta visibilidade ao novo balcão.

Vegoda apontou uma diferença operacional que a proposta ainda precisa resolver. Se a máquina cair, todos podem observar a falha. Se ela mostrar à RIPE NCC uma resposta legítima e a outros clientes uma versão enganosa, a checagem de disponibilidade continuará sorrindo. Ele pediu proteção contra esse comportamento; Ranjbar aceitou debater o desenho.

O registro da reunião não traz um teste de equivalência entre clientes, regra de retirada por divergência ou calendário de ativação. O próximo documento decisivo seria a análise de impacto acompanhada de um procedimento reproduzível de comparação. A pergunta de Vegoda é curta porque o mecanismo de falha é simples: um serviço pode dizer “estou aqui” sem dizer a mesma coisa a todos.

Fontes: transcrição da RIPE 93; resumo oficial da palestra; perfil de Leo Vegoda na RIPE Labs.