Na ARIN, o bloco de origem define a divisão do DNS reverso

Resumo

• A ARIN cria as maiores delegações reversas admitidas para cada componente CIDR de uma alocação direta. Nos exemplos oficiais, um /23 resulta em dois /24; um /16 fica com uma delegação /16.
• A exceção à autoridade compartilhada considera o bloco de origem do ISP. Ela não impede uma subdelegação na camada DNS, mas deixa ao operador da zona pai a tarefa de organizar essa entrega.

Duas entregas que não se confundem

Um provedor pode entregar a um cliente uma faixa de endereços perfeitamente identificada sem entregar, no mesmo ato, uma parte equivalente de seu controle sobre o DNS reverso. A diferença não aparece olhando apenas para o tamanho da faixa do cliente. É preciso voltar à alocação direta e descobrir como ela foi representada nas delegações da ARIN.

Os exemplos da documentação de DNS reverso dão uma medida concreta dessa separação. Uma alocação direta /23 produz duas delegações /24, cujos servidores de nomes podem ser administrados separadamente. Uma alocação /16 produz uma única delegação /16. O bloco maior oferece mais endereços, mas não mais objetos de delegação independentes no registro.

A lógica é escolher a maior delegação suportada para cada bloco CIDR que compõe uma Direct Allocation. Em IPv4, a ARIN trabalha nos limites /8, /16 e /24, sendo /24 o menor tamanho suportado. Como /23 não é uma dessas fronteiras, seu espaço é coberto por dois /24. O /16 já coincide com uma fronteira e cabe em uma delegação.

Isso não retira do titular do /16 o controle do conjunto. Muda a escala na qual o registro apresenta a edição. Tampouco significa que qualquer agregado que contenha a faixa do cliente determine o resultado: o ponto de partida documentado são os componentes da alocação direta, não uma agregação escolhida posteriormente ou cada nova designação a um usuário. Para IPv6, a documentação utiliza limites de quatro bits. A condição /16 discutida aqui pertence ao caso IPv4 e não deve ser transportada para aquela família.

O detalhe está em “a partir de”

Considere um cenário hipotético: uma empresa recebe um /24 extraído do /16 de seu ISP e quer usar seus próprios servidores para o DNS reverso. Saber que os 256 endereços pertencem à faixa entregue não basta para identificar qual delegação ela pode editar na ARIN. Ainda falta verificar a relação com o bloco do provedor.

A ARIN prevê autoridade compartilhada entre titulares diretos e indiretos elegíveis. Uma organização autorizada indicada para a zona pode participar da gestão correspondente aos endereços delegados a ela. Há, porém, uma exclusão expressa: a designação ou realocação feita a partir de um bloco /16 ou maior do ISP não recebe esse compartilhamento de gestão reversa.

O tamanho relevante não é apenas o que o cliente recebeu. No cenário proposto, o /24 continua vindo do /16 do ISP. Ler a exceção como se atingisse somente clientes que recebem um /16 inteiro mudaria o sentido do requisito. “Maior”, por sua vez, significa mais endereços e um prefixo numérico mais curto, não um número superior a 16 depois da barra.

Não há aqui uma empresa real que tenha sofrido uma recusa observada. A documentação permite localizar uma condição; não informa a frequência com que ela afeta clientes, nem substitui um teste de permissões de conta. A utilidade do exemplo é impedir que o tamanho anunciado no contrato seja tomado como descrição suficiente do controle no registro.

A gestão de registros de recursos reforça a distinção. Uma modificação de rede pode alterar nome, contatos e comentários públicos, mas não a delegação DNS reversa. As descrições gerais de administração compartilhada precisam ser lidas junto da ressalva específica sobre DNS. É possível que uma organização tenha atribuições sobre o registro da rede sem dispor da mesma operação sobre a delegação. Não é necessário acusar as páginas de contradição para explicar dois escopos diferentes.

A associação também tem um fim previsto. A ARIN orienta o ISP a remover o registro de designação ou realocação do cliente desconectado para retirar a autoridade compartilhada. É uma regra documentada para o ciclo de vida do vínculo, não evidência de que algum operador tenha deixado acessos antigos em aberto. E não serve de justificativa para retirar o registro de um cliente ativo apenas para simplificar uma lista de permissões.

A zona pai pode fazer uma entrega menor

O limite do registro não é o limite de tudo o que o DNS permite. A empresa do exemplo pode depender de outra entrega: uma subzona organizada pelo ISP ou pelo prestador que opera seu DNS.

O RFC 1034 descreve como o operador de uma zona pode delegar subzonas. O lado pai mantém os registros NS necessários e, quando exigidos, os registros de apoio que permitem localizar os servidores. A configuração dos dois lados do corte precisa permanecer coerente. Um /24 sob um /16 pode, assim, usar a delegação DNS ordinária para dar ao cliente a administração de sua zona, sem repassar a conta da ARIN ou a autoridade sobre todo o /16.

Isso desloca a responsabilidade, não a faz desaparecer. Alguém precisa preparar o lado pai e atualizá-lo quando o vínculo com os servidores do cliente mudar. A capacidade de editar os dados da zona filha não equivale à capacidade de mudar sozinho esse vínculo. Também não se pode inferir, a partir do protocolo, que um provedor específico ofereça ou sustente tal serviço. A possibilidade técnica e o compromisso comercial precisam ser verificados separadamente.

Há uma técnica própria para conjuntos com menos de 256 endereços IPv4. O RFC 2317 combina nomes delegados adicionais e referências CNAME sem alterar o mecanismo de consulta do DNS. A dependência do pai continua presente. Esse documento não prova que a ARIN crie livremente delegações /25 e não precisa explicar o caso de um /24 comum sob um /16. Tratar toda subdelegação como se exigisse essa construção esconderia a diferença que ela foi feita para resolver.

O resultado é uma separação de funções. A ARIN pode manter uma delegação relativamente ampla; o responsável por essa zona pode organizar uma responsabilidade mais estreita abaixo dela. A falta de uma edição independente no registro não demonstra uma proibição técnica. A existência de uma solução no DNS não demonstra que sua operação já foi combinada.

Antes de salvar, descobrir o que está selecionado

As operações Reg-RWS mostram que rede e delegação não são o mesmo objeto. As delegações surgem e desaparecem com as redes associadas, sem criação ou exclusão independente. São identificadas pelo nome da delegação, não pelo identificador NET. A documentação prevê consultar as delegações ligadas a um NET e ler o estado atual antes de modificar. Nenhuma chamada de provisionamento à ARIN foi realizada nesta análise.

Na interface, o guia de gerenciamento DNS relaciona as zonas reversas, os servidores de nomes, as etiquetas de chaves DS e as organizações com autoridade compartilhada. Uma alteração de servidores substitui os valores anteriores em todas as delegações selecionadas. A descrição de um chamado como “o /24 do cliente” não reduz o alcance de uma seleção mais ampla na tela.

O guia também informa TTL de 86.400 segundos quando o campo fica vazio e distingue a atualização imediata da base da visibilidade DNS, que pode levar até 24 horas. A indicação não é uma medição de indisponibilidade nem uma garantia de vencimento simultâneo de todos os caches. Ela ajuda a separar o ato de gravar da confirmação do efeito desejado.

As fontes disponíveis em 3 de setembro de 2026 estabelecem esse modelo de administração. Não medem migrações, incidentes, custos, recusas ou consultas DNS de clientes. Um PTR correto tampouco comprova roteamento, propriedade ou identidade completa. A pergunta útil é mais específica: quem consegue alterar a resposta para esta faixa, em qual zona e com qual dependência do operador acima dela?