Resumo

  • Na sugestão 2026.4, Richard Laager descreveu uma reatribuição detalhada de um NET seu para outra organização. A chave do lado da rede-mãe era barrada no GET pelo identificador do filho, embora pudesse excluí-lo e encontrá-lo por mostSpecificNet; a chave da organização receptora fazia o GET pelo identificador.
  • Em 30 de março de 2026, a ARIN considerou as ferramentas alternativas de consulta e planos futuros suficientes para deixar as permissões da API como estavam. Encerrou a sugestão com a concordância do remetente.

O registro tinha um identificador, mas a consulta por esse identificador era proibida para quem o tinha criado. Richard Laager apresentou o caso na sugestão 2026.4 da ARIN. Ele fez uma reatribuição detalhada de um NET seu para uma segunda organização. Depois tentou usar sua chave de API do lado da rede-mãe para ler o NET filho pelo handle. Recebeu um erro de permissão. A mesma relação, segundo o relato, permitia excluir o filho e procurá-lo pelo endereço inicial e final em mostSpecificNet. O Whois público também mostrava as informações sem login.

Uma reatribuição detalhada dá à organização receptora capacidade de administrar o endereço com seu próprio Org ID. O guia da ARIN afirma que o registrante direto conserva o poder de recuperar essa reatribuição. Para objetos IRR e DNS reverso ligados ao registro, a gestão é compartilhada. Assim, há duas organizações com vínculos operacionais ao NET filho. A pergunta é qual desses vínculos cada método da API aceita ao decidir sobre uma leitura.

Laager detalhou quatro resultados. A chave da receptora fazia GET pelo handle. A chave da rede-mãe era recusada no mesmo endpoint. Essa chave encontrava o objeto pelo intervalo de IPs. Qualquer pessoa consultava informação equivalente por Whois, usando identificador ou endereço. Não se tratava de esconder o conteúdo de olhos não autorizados. O limite estava na combinação entre uma identidade autenticada e uma forma particular de pedir os dados.

A documentação Reg-RWS separa as operações. GET /rest/net/NETHANDLE devolve o NET indicado. GET /rest/net/mostSpecificNet/STARTIP/ENDIP devolve o mais específico para um intervalo. DELETE /rest/net/NETHANDLE cria uma solicitação processada por ticket para retirar uma reatribuição ou realocação; não é uma borracha instantânea para alocações diretas. PUT /rest/net/NETHANDLE envia um payload para modificar dados. O fato de um desses caminhos funcionar não altera a resposta dos outros. Sistemas automáticos precisam modelar essa diferença, em vez de supor uma autorização uniforme para o objeto.

O preço aparece na conciliação. A empresa que criou a reatribuição guarda o handle do NET filho. Quando tenta conferir se o registro ainda corresponde ao inventário, o GET direto falha. Ela precisa manter também os limites de endereços, usar a busca por intervalo e verificar se o resultado aponta para o mesmo filho, a mesma rede-mãe e a mesma receptora. O Whois ajuda a investigação humana, mas não substitui o recibo da chamada autenticada. O DELETE disponível é um péssimo atalho: remover um registro ativo para reconstruí-lo seria transformar um problema de leitura em uma intervenção no cadastro do cliente.

Laager pediu que o GET de NETs fosse amplamente permitido. Pediu também que a rede-mãe pudesse fazer PUT num filho direto, já que, em sua análise, podia excluir e recriar o registro. Essas propostas não são a mesma regra. Uma consulta sobre dados também públicos por Whois tem um impacto diferente da modificação do nome da rede, de vínculos de contato ou de comentários públicos descrita no guia de alterações de NET. A ARIN não adotou a extensão de PUT na resposta.

Em 30 de março, a ARIN afirmou ter examinado outros instrumentos existentes para obter a informação e planos futuros de desenvolvimento. Concluiu que mudar as verificações atuais de permissão não era necessário naquele momento. O remetente concordou com o encerramento. A resposta não anunciou correção do GET por handle. Colocou no fluxo do cliente a tarefa de escolher outro caminho de consulta e conferir a identidade do objeto recebido.

Uma nova sequência de chamadas de produção, com as chaves das duas organizações e os métodos documentados, mostraria se a negativa ainda ocorre depois daquela resposta. O registro público fixa a reprodução informada por Laager e a decisão de manter a checagem. Para quem automatiza muitas reatribuições, isso já define uma exigência concreta: tratar «permissão negada neste GET» de forma distinta de «NET inexistente».

O cadastro tem um nome, um intervalo e dois atores legítimos. Quando o caminho pelo nome fecha para um ator que ainda consegue consultar pelo intervalo e retirar o registro, a ARIN economiza uma mudança na regra do servidor. O custo da diferença reaparece em cada cliente que precisa reconciliar as duas identidades.

Sugestão e resposta da ARIN · Métodos Reg-RWS · Gestão de recursos · Alterações de NET