Resumo

  • D1 condicionava uma nova delegação reversa à existência de uma atribuição ou subalocação registrada e previa lembretes para LIRs sem esses registros, mas preservava de forma categórica as delegações reversas preexistentes.
  • D2 esclareceu que, para um /24, bastaria ao menos uma atribuição ou subalocação registrada naquele /24; não seria necessário registrar como atribuída a faixa inteira.
  • D2 acrescentou um período de doze meses contado do lembrete antes de uma possível retirada da delegação reversa, sem contudo especificar prova de recebimento, verificação da correção, revisão independente ou exceção de continuidade.
  • Ao mesmo tempo, D2 eliminou a proteção absoluta das delegações existentes e passou a permitir a retirada da delegação reversa de qualquer alocação de LIR depois do mesmo período de doze meses.
  • O índice anual da AFRINIC coloca páginas de D1 e D2 sob o rótulo de 23 de abril de 2012, mas o histórico da própria proposta registra D2 como submetido em 30 de novembro de 2012, um dia depois de a AFRINIC-17 ainda discutir D1. A data substantiva usada nesta análise é, portanto, 30 de novembro.
  • Desabilitar rDNS não revoga recursos numéricos nem desliga por si só o roteamento BGP. É a retirada de uma delegação na zona-pai operada pelo registro, capaz, ainda assim, de afetar correio eletrônico, reputação de rede, diagnósticos e rotinas de clientes.
  • A AFRINIC é um contador de registros e coordenador técnico privado. Ela não possui autoridade soberana, regulatória, policial, punitiva, confiscatória ou jurisdicional; sua operação do cadastro e do serviço reverso não transforma uma divergência documental em licença para punir.

A troca embutida em poucas linhas

O ponto decisivo da passagem de D1 para D2 não está numa mudança de objetivo declarado, mas na redistribuição de proteção e risco dentro do mecanismo. D2 fez duas correções que, isoladamente, parecem favorecer a continuidade. Primeiro, substituiu uma condição vaga por uma medida localizada: para obter delegação reversa de um /24, ao menos uma atribuição ou subalocação deveria estar registrada para aquele /24, sem exigir que o bloco inteiro aparecesse como atribuído. Segundo, criou uma espera de doze meses após o lembrete antes que se pudesse cogitar a retirada do serviço.

A precisão do objeto e a demora antes da ação reduziram a chance de uma reação imediata a uma lacuna ampla ou mal compreendida.

Mas D2 também removeu a barreira que D1 havia erguido em torno das delegações já existentes. No primeiro texto, essas delegações preexistentes ficavam fora do caminho de retirada. No segundo, qualquer alocação de LIR poderia ter sua delegação reversa removida após os doze meses. O redline, portanto, não aponta numa única direção. Ele restringe o gatilho documental, desacelera o tempo e amplia a população alcançada. A melhoria procedimental e o aumento de exposição não se cancelam; precisam ser examinados juntos. É justamente essa combinação que impede a leitura confortável de D2 como simples moderação de D1.

A distinção importa porque o serviço em jogo não é um ornamento administrativo. A retirada da delegação reversa na zona-pai não equivale a revogar a alocação de endereços e tampouco encerra automaticamente o anúncio de rotas. Ainda assim, o rDNS participa de verificações de correio, reputação de rede, diagnósticos e práticas operacionais de clientes. A continuidade pode sofrer mesmo quando os pacotes continuam circulando. Usar essa dependência para pressionar o preenchimento de registros desloca o problema: uma inconsistência do cadastro passa a ser tratada por meio de um serviço vivo do qual terceiros podem depender.

A cronologia que o índice não consegue explicar

Há uma anomalia documental que deve ser exposta antes de qualquer interpretação. O índice do arquivo de 2012 da AFRINIC agrupa as páginas de D1 e D2 sob o rótulo de 23 de abril. Lido isoladamente, esse índice poderia sugerir que os dois textos já existiam na mesma altura do calendário. A sequência mantida pela própria AFRINIC, porém, não sustenta essa conclusão. D1 é identificado como AFPUB-2012-DNS-001-DRAFT-01, de autoria de Tim McGinnis, submetido em 10 de abril de 2012. Em 18 de maio, a reunião AFRINIC-16 discutiu D1. Em 29 de novembro, a AFRINIC-17 ainda registrou o item com o identificador de D1.

O histórico da proposta situa a submissão de D2 em 30 de novembro de 2012.

Esses elementos não deixam espaço para tratar 23 de abril como a data substantiva de D2. O índice existe e faz parte do registro; por isso não deve ser apagado, corrigido por suposição ou escondido numa nota lateral. Mas um rótulo de arquivo não pode prevalecer sobre uma sequência em que o texto posterior aparece depois de duas discussões registradas sobre D1 e, de modo especialmente próximo, um dia depois de a reunião de 29 de novembro ainda debater o problema que D2 passou a enfrentar.

A conclusão responsável é limitada: há um conflito na apresentação cronológica do arquivo, e 30 de novembro é a data que o histórico de D2 atribui à sua submissão.

Isso também disciplina o alcance da análise. O objeto aqui é o ato de publicar o segundo texto e a diferença imediata entre os dois rascunhos, iluminada pelas discussões de D1. Não há necessidade de buscar em eventos posteriores uma validação retrospectiva. Um texto deve ser julgado pelo que propunha naquele momento, pelas provas que apresentava, pelos efeitos operacionais que colocava em movimento e pelas salvaguardas que continha ou deixava de conter. A cronologia até 30 de novembro é suficiente para revelar o problema institucional.

D1: registro obrigatório, lembrete aberto e proteção existente

D1 combinava três movimentos. Para novas delegações reversas, sua seção 3.1 exigia que uma atribuição ou subalocação estivesse registrada para o espaço de endereços. Para LIRs que já tinham DNS reverso, mas não apresentavam atribuições ou subalocações registradas, a seção 3.2 previa contato pela AFRINIC. MyAFRINIC e correio eletrônico apareciam como canais imaginados, enquanto pormenores de execução ficavam com a equipe. A seção 3.3, enfim, estabelecia uma linha de proteção: a delegação reversa preexistente não seria removida. A consequência era assimétrica.

O registro incompleto poderia impedir um pedido novo, mas não levaria à interrupção de uma delegação já operante.

Essa assimetria não resolvia todos os problemas. D1 não fixava um período de correção. Não descrevia como provar que o aviso chegara à pessoa capaz de agir. Não definia uma etapa de confirmação de que o registro apresentado solucionava a divergência. Também não previa revisão independente. A proteção categórica das delegações existentes, entretanto, evitava que essas lacunas processuais se transformassem em retirada de serviço. Era uma barreira grosseira, mas efetiva, entre o desejo de melhorar o banco de dados e a continuidade de uma função operacional já ativa.

É importante não atribuir a essa barreira um estatuto que os documentos não demonstram. Ela era uma opção do primeiro rascunho, não prova de um direito criado por alguma autoridade pública. Do mesmo modo, o requisito de registro não era uma determinação legislativa. Era o desenho proposto por uma corporação privada que opera um cadastro e uma zona-pai. Essa entidade pode estabelecer verificações estreitas e objetivas para aceitar uma solicitação técnica. O cuidado começa quando a dependência de um serviço é usada como instrumento de coerção ou como se a organização tivesse competência para julgar abandono, abuso, propriedade ou legalidade.

AFRINIC-16: um diagnóstico forte, uma base não publicada

Na discussão de 18 de maio de 2012, o autor apresentou a lacuna que motivava a proposta e, segundo o relatório da reunião, afirmou que perto de 40% dos provedores de internet não haviam registrado nenhuma atribuição. O registro da reunião também reconhece a importância do rDNS e as consequências de sua indisponibilidade. Participantes levantaram dúvidas sobre a efetividade da medida, a carga para a equipe e a ideia de escanear redes. Não houve consenso, e o tema retornou à lista.

O número próximo de 40% é relevante como afirmação feita no debate, mas não pode carregar mais peso do que a fonte permite. O relatório não publica o conjunto de dados, o denominador, a data de coleta nem o método. Também não mostra se a ausência de uma atribuição no banco correspondia a endereços sem uso, a uso não documentado, a atraso de atualização ou a qualquer outra situação. O fato verificável é a discrepância apontada: certos registros esperados não apareciam no cadastro. A partir daí, qualquer salto para abuso, ilegalidade, abandono ou perda de controle seria inferência sem sustentação.

Esse limite probatório é central porque a resposta proposta atingia outro plano. Se a falha é documental, o remédio mais direto é identificar o campo ausente, indicar quem pode corrigi-lo, validar a correção e preservar o serviço enquanto a verdade cadastral é apurada. A indisponibilidade de rDNS, por sua vez, alcança operações que não são equivalentes ao preenchimento do registro. Ela pode tocar sistemas de correio, sinais de reputação, investigação de falhas e rotinas de clientes. A severidade prática não depende de chamar a medida de sanção. Ela decorre do canal técnico escolhido.

O resultado sem consenso também precisa ser interpretado com contenção. A reunião mostra uma comunidade de participantes confrontando um desenho e devolvendo o tema para discussão. Ela não é um parlamento, e o procedimento de consenso interno não cria soberania. Os comentários ajudam a compreender quais defeitos os presentes perceberam, mas não demonstram representação universal, mandato público ou competência para impor punição. São evidências do processo de coordenação privada — nem mais, nem menos.

AFRINIC-17: a pergunta que D2 transformou em limiar

Em 29 de novembro, a ata da AFRINIC-17 ainda tratava a proposta como D1. A discussão registrou uma questão particularmente concreta: uma única atribuição seria suficiente para tornar disponível o DNS reverso? Também houve apoio à ideia de declarar um limiar percentual. Mais uma vez não houve consenso, e o assunto retornou à lista. No dia seguinte, o histórico da proposta identifica a submissão de D2.

D2 respondeu à ambiguidade sem adotar um percentual. A unidade passou a ser o /24, e a suficiência foi definida por um mínimo: ao menos uma atribuição ou subalocação registrada naquele /24. O texto explicitou que não era necessário que o /24 inteiro estivesse atribuído. Essa é uma mudança substancial, porque impede que a obtenção do serviço dependa de representar todo o espaço como entregue a usuários finais. Também reduz o risco de interpretar uma exigência genérica como demanda de documentação integral de cada endereço.

O novo limiar, porém, não é um atestado abrangente de precisão. Um único objeto registrado satisfaz a condição declarada para a delegação do /24; ele não prova que todos os endereços, usuários ou usos do bloco estejam corretamente documentados. D2 escolheu uma regra de suficiência administrativa, não uma auditoria completa. Essa modéstia do teste é uma virtude quando o objetivo é evitar intrusão e excesso, mas também revela por que a retirada de um serviço não pode ser descrita como julgamento sobre a situação material da rede. O teste diz algo estreito sobre o banco de dados, e somente isso.

Doze meses melhoram o relógio, não criam devido processo

A segunda alteração clara foi a criação de um período de doze meses contado do lembrete. Para uma organização capaz de receber, compreender e corrigir a notificação, o intervalo oferece tempo substancial. Ele é inequivocamente melhor do que uma ameaça sem prazo definido ou uma retirada imediata. A longa janela reconhece, ao menos em parte, que alterações cadastrais exigem contato, investigação e ação de pessoas responsáveis.

Mas duração não é sinônimo de devido processo. O texto de D2 não especificava prova de que o lembrete fora entregue, repetição da mensagem quando o contato falhasse, identificação exata do objeto ausente, confirmação da autoridade de quem efetuasse a correção, validação final por equipe, revisão por pessoa independente ou exceção destinada a proteger operações dependentes. Um relógio pode correr por doze meses sem que a parte certa saiba que ele começou. Também pode continuar correndo enquanto existe uma divergência legítima sobre qual dado é exigido ou se o banco interpretou corretamente a situação.

Por isso, o avanço temporal deve ser reconhecido sem ser exagerado. D2 desacelerou o mecanismo. Não construiu o conjunto de garantias necessário antes de uma decisão que alcança um serviço em uso. A linguagem “poderá remover” ainda deixava discricionariedade no ponto de maior consequência, ao passo que os critérios para exercê-la permaneciam subespecificados. A combinação de um gatilho objetivo na entrada e uma escolha discricionária na saída não resolve o risco; ela apenas o desloca para o final do período.

A ampliação que a palavra “qualquer” produz

A terceira mudança é a mais fácil de perder quando se olha apenas para o prazo. D1 separava as delegações novas das existentes e protegia as segundas contra retirada. D2 substituiu essa barreira por uma permissão aplicável a qualquer alocação de LIR depois de transcorridos doze meses desde o lembrete. O novo texto, portanto, não apenas disciplinou melhor uma categoria já exposta. Ele levou delegações antes preservadas para dentro do alcance potencial do mecanismo.

Esse alargamento transforma a avaliação de proporcionalidade. Se a melhora no limiar reduz falsos gatilhos e o prazo reduz precipitação, a eliminação da proteção aumenta o número de situações em que um erro não corrigido, um aviso não recebido ou uma disputa cadastral pode culminar em retirada. Não sabemos quantas zonas seriam alcançadas, quantos clientes dependeriam delas ou quais perdas ocorreriam; as fontes não quantificam esses efeitos. Sabemos, contudo, que a classe normativa mudou. O universo deixou de excluir as delegações preexistentes.

A leitura institucional correta precisa manter os dois movimentos no mesmo quadro. Descrever D2 apenas como mais severo apaga as melhorias reais. Descrevê-lo apenas como mais razoável apaga a expansão de alcance. A pergunta adequada é se uma regra mais precisa e paciente oferecia salvaguardas suficientes para justificar colocar um serviço ativo em risco. Pelos elementos do texto, a resposta é não. Precisão e tempo eram necessários, mas não bastavam diante da ausência de entrega comprovada, correção verificável, revisão independente e proteção contra dano colateral.

Operar a zona-pai não cria poder de punir

A AFRINIC é descrita como um registro regional de internet sem fins lucrativos e baseado em membros, ligado à coordenação de recursos numéricos e serviços relacionados. Essa posição lhe confere tarefas reais. Ela mantém registros, ajuda a preservar unicidade, verifica se uma pessoa tem autoridade para solicitar mudanças e opera componentes técnicos como a delegação reversa na zona-pai. Essas funções exigem regras, consistência e capacidade de recusar solicitações que não satisfaçam condições objetivas.

Nada disso a converte em governo, legislador, regulador, polícia, promotor, órgão de punição, confiscador ou tribunal. Controle operacional é alavanca técnica, não fonte de soberania. A instituição pode provar o que escreveu, publicou e discutiu; seus documentos não provam, por si mesmos, que ela possua mandato legal para penalizar. Se a proposta se descreve como “enforcement mechanism”, essa expressão é evidência da forma como o mecanismo foi apresentado, não demonstração de uma competência legítima de enforcement.

Essa separação evita dois erros opostos. O primeiro seria negar à AFRINIC qualquer possibilidade de cuidar do cadastro ou condicionar um novo serviço a informações mínimas. Isso impediria o contador de manter o livro. O segundo seria concluir que, por operar o livro e a zona-pai, a organização pode usar a continuidade do serviço para impor sua avaliação final sobre quem merece recursos, quem agiu legalmente ou quem deve sofrer consequência. Isso transformaria uma dependência técnica em poder punitivo.

O papel legítimo está no meio estreito: regras públicas, objetivas e verificáveis para registrar fatos e executar mudanças autorizadas, sem converter discrepância em julgamento.

rDNS não é roteamento, mas tampouco é irrelevante

Uma análise cuidadosa precisa resistir ao falso dilema entre catástrofe total e efeito nulo. A retirada da delegação reversa não revoga a alocação numérica e não interrompe, por seu mecanismo direto, o anúncio BGP. Uma rede pode continuar encaminhando pacotes. Isso impede que o ato seja descrito como confisco de endereços ou desligamento automático da conectividade.

Por outro lado, o fato de o roteamento persistir não torna o rDNS descartável. Sistemas de correio podem considerar a resolução reversa em suas avaliações; equipes podem depender dela para diagnóstico; mecanismos de reputação e rotinas de clientes podem incorporá-la. O impacto aparece como degradação, rejeição, perda de legibilidade operacional ou trabalho adicional, não necessariamente como um único apagão. A fonte histórica não mede quantos casos ocorreriam, e esta análise não inventa um incidente para dramatizar o risco. O ponto é estrutural: retirar a delegação na zona-pai altera um serviço de que operações legítimas podem depender.

Essa natureza distribuída do dano reforça a obrigação de cautela. O LIR responsável pelo cadastro não é a única parte potencialmente afetada. Clientes e operadores a jusante podem sofrer a consequência sem controlar a atualização no banco da AFRINIC ou o canal pelo qual o lembrete foi enviado. O mecanismo, assim, pode deslocar o custo da correção para terceiros. Uma política de registro bem desenhada deveria reduzir esse descompasso, não explorá-lo.

O melhor argumento a favor de D2 — e seu limite

O argumento mais forte em favor de D2 é sério. Um serviço de delegação reversa depende de dados que relacionem o espaço a registros apropriados. Exigir ao menos um objeto por /24 é uma condição modesta, bem mais estreita do que demandar documentação integral. Doze meses constituem uma janela longa para correção. Sem alguma consequência, lembretes poderiam ser ignorados e o cadastro permanecer incompleto. Sob essa leitura, a possibilidade de retirada alinharia o serviço com o banco público de que ele depende e seria mais proporcional do que a formulação indeterminada anterior.

As duas primeiras premissas procedem. O limiar localizado e o prazo são melhorias materiais. O problema está em converter a terceira premissa em autorização para afetar um serviço existente. D2 não demonstrava entrega do aviso, não separava erro do banco de inação do titular, não oferecia revisão independente e não previa exceção de continuidade. Além disso, ampliava o alcance ao remover a proteção anterior. Um mecanismo de correção não se torna proporcional apenas porque espera; ele também precisa garantir que a pessoa certa foi avisada, que o defeito foi definido, que a cura foi verificada e que terceiros não serão usados como pressão.

A resposta não é preservar registros ruins. É escolher instrumentos adequados ao papel institucional. O registro pode recusar um pedido novo que não cumpra a condição objetiva, marcar uma inconsistência, solicitar informação específica, confirmar a atualização e encaminhar eventual controvérsia jurídica a autoridades soberanas competentes. O que não pode fazer é tratar o acesso a um serviço operacional como pena. Desabilitar rDNS não é punição legítima; é retirada de serviço com consequências de continuidade e, por isso mesmo, exige uma justificativa técnica estreita e salvaguardas mais fortes do que D2 apresentava.