Resumo

  • O objeto de DNS reverso que repetia ns1.ibits.xyz em fevereiro agora lista esse nome e ns2.ibits.xyz. A observação de setembro encontrou ambos na indicação do servidor pai e uma resposta SOA autoritativa do primeiro destino. O exemplo antigo não deve ser descrito como ainda duplicado.
  • Linhas de atributos, nomes DNS distintos, respostas medidas e independência diante de falhas são propriedades diferentes. Um alerta para repetição exata pode melhorar a entrada sem certificar a disponibilidade, impor dois servidores em todo cadastro ou justificar sanções sobre endereços.

Uma linha a menos no diagnóstico, não uma prova a mais

O caso concreto mudou. Na consulta em modo somente leitura das 04:12 UTC de 2026-09-14, o objeto 8.c.4.f.f.0.c.2.ip6.arpa trazia ns1.ibits.xyz e ns2.ibits.xyz. Uma consulta NS a ns1.afrinic.net indicou os dois nomes. Ao consultar SOA no primeiro deles, o resultado foi NOERROR, com a marca de resposta autoritativa e um registro SOA. A repetição exata descrita em fevereiro já não aparecia nessa observação.

Essa é uma melhora relevante. O registro observado não tem duas linhas com o mesmo nome, o pai não indica apenas um destino e o primeiro servidor não retorna a recusa mostrada no relato antigo para aquela consulta. Um diagnóstico que preservasse a acusação anterior apesar desses resultados seria menos preciso que a evidência disponível. A correção deve ser reconhecida antes de discutir o que ainda falta verificar.

O serviço WHOIS público permite localizar o objeto. Já a evidência operacional aqui descrita tem limites claros: um ponto de observação, um momento, uma zona, uma consulta SOA ao primeiro destino. Não houve consulta SOA ao segundo, teste de PTR, medição em diversas regiões ou ensaio de recuperação após falha. Tampouco foram mapeados os endereços, caminhos, locais físicos e fornecedores por trás dos nomes.

Não foi identificada a autoria ou a data exata da correção. Também não se demonstrou que o controle geral de entrada mudou. Um objeto mantido por um membro pode melhorar sem uma nova regra aplicada a todas as interfaces. Consultar o conteúdo salvo e a resposta do pai não testa o que cada caminho de criação ou atualização aceita atualmente.

Isso retira do artigo uma afirmação inadequada: o exemplo não permanece igual ao de fevereiro. Mas preserva a questão interessante. A contagem de linhas pode enganar quem procura saber quantas alternativas úteis existem. Mesmo depois de dois nomes se tornarem distintos, a capacidade de sobreviver a uma interrupção depende de outra investigação, e não apenas de um número mais bonito no cadastro.

O pedido original era menor que uma política de disponibilidade

Em 2026-02-19, Frank Habicht perguntou ao grupo de trabalho de banco de dados se a criação de um objeto deveria ser rejeitada quando dois atributos nserver: contivessem exatamente o mesmo valor. O exemplo mostrava ns1.ibits.xyz duas vezes. Ele pediu informações sobre as verificações existentes e afirmou não falar como presidente. Era uma pergunta e uma proposta de discussão, não uma decisão anunciada por AFRINIC.

Na mensagem seguinte, de 20 de fevereiro, admitiu que a redação documental então disponível permitia a entrada. A preocupação era humana: alguém poderia olhar duas linhas e concluir que havia dois servidores autoritativos, com algum grau de redundância. O comando apresentado para o pai devolvia um único destino NS. Outro comando, para SOA no destino, recebia REFUSED.

Os resultados tratavam de coisas diferentes. O nome repetido explicava por que duas linhas não produziram duas alternativas no DNS. A recusa tratava da prestação de serviço daquela zona pelo servidor consultado. Eliminar uma repetição não faz uma máquina responder autoritativamente. Fazer a máquina responder também não converte o mesmo nome em dois destinos diferentes.

Esses comandos são evidência arquivada do que o participante relatou naquela data, não testes realizados por este autor em fevereiro. A observação de setembro tem sua própria data e alcance. Preservar essa separação evita que um relato reproduzível de meses atrás seja utilizado como uma medição atual sem que ninguém tenha repetido a verificação.

O DNS não transforma uma cópia em alternativa

A seção 5 de RFC 2181 define um conjunto de registros de recursos, o RRSet, por nome proprietário, classe e tipo comuns, com dados diferentes. Se os dados também forem iguais, a segunda cópia não cria uma alternativa significativa; servidores devem suprimir duplicatas. Repetir exatamente um destino NS, portanto, não acrescenta um segundo nome à delegação.

WHOIS e DNS exibem informação para tarefas diferentes. O cadastro guarda atributos que podem ser consultados e editados. O DNS apresenta o conjunto usado na resolução. Um pode mostrar duas linhas enquanto o outro contém apenas um valor distinto. O protocolo pode funcionar corretamente e, ainda assim, a pessoa que conta linhas pode sair com uma ideia errada sobre a configuração.

Essa é uma ambiguidade de entrada e apresentação. Não é preciso classificá-la como ataque, nem supor indisponibilidade geral, para reconhecer sua importância. O problema pode influenciar o entendimento de quem verifica se a tarefa de preparar um serviço de reserva já foi concluída. O fato de o exemplo atual ter melhorado não muda a diferença entre os dois tipos de contagem.

As perguntas devem ser separadas. Quantos atributos há? Quantos nomes canônicos distintos representam? Quais destinos responderam autoritativamente, de onde, quando e para qual consulta? Que falhas poderiam derrubar todas as alternativas úteis ao mesmo tempo? Cada resposta exige um tipo de evidência que a contagem anterior não oferece.

Em setembro, foram observados dois atributos com nomes distintos, dois destinos no pai e uma resposta autoritativa do primeiro. Não foi medida a independência de suas falhas. Mesmo duas respostas corretas não demonstrariam dois prédios, duas rotas ou duas estruturas administrativas separadas. A observação atual é positiva sem precisar ser convertida em uma certificação de toda essa arquitetura.

RFC 2182 trata da escolha de servidores secundários a partir de falhas plausíveis e de dispersão geográfica e topológica. Duas máquinas na mesma sala podem resistir à falha de uma delas e continuar expostas à mesma queda de energia. Serviços em locais diferentes podem compartilhar administração ou outras dependências. São hipóteses úteis para planejar uma avaliação, não resultados medidos sobre a zona citada.

Também vale o cuidado inverso: um único nome pode atender por infraestrutura distribuída. Dois nomes não provam máquinas ou endereços separados, mas tampouco provam uma dependência comum. Nada disso foi mapeado neste caso. A recomendação de diversidade diz o que procurar; ela não revela, por si só, a configuração real de um operador.

Repetível não é obrigatoriamente duplo

Uma parte da conversa decorreu da leitura do modelo. nserver: é marcado como mandatory e multiple. O primeiro exige a presença do atributo; o segundo permite repeti-lo. A combinação não estabelece, por si mesma, um mínimo de duas linhas nem de dois serviços independentes. Interpretá-la assim muda o objeto da proposta: em vez de evitar uma repetição exata, passa-se a exigir uma configuração mais ampla.

Em uma explicação de 20 de fevereiro, Habicht usou o manual então vinculado para esclarecer a multiplicidade. Em 2026-03-23, Sylvain BAYA aceitou a correção de sua leitura. Ainda propôs discutir restrições a objetos com um único servidor, comparação de atributos, tratamento de delegações sem serviço adequado e um documento de boas práticas. A posição era individual, não consenso ou implementação demonstrada.

A consulta atual do modelo continua mostrando mandatory, multiple e inverse key. Sua descrição detalhada aborda nomes válidos, ponto final opcional e determinados endereços de apoio. Não se tentaram criações ou atualizações para testar a validação de produção. Um modelo publicado é evidência da estrutura anunciada, não um teste completo de todas as interfaces e seus comportamentos.

O guia de DNS reverso de AFRINIC recomenda pelo menos dois servidores para redundância e descreve configuração prévia, verificação e propagação da delegação. A recomendação é sensata. Transformá-la em condição universal de aceitação seria outra decisão, com escopo e transição próprios, inclusive para objetos existentes que precisam de reparos úteis.

O argumento por medidas mais amplas merece sua melhor versão. Um alerta de duplicata não instala um secundário ausente nem corrige a autoridade de um servidor. Orientação e apoio prático podem trazer mais benefício que uma nova mensagem de rejeição. Isso não torna a apresentação fiel inútil; apenas impede que uma proteção pequena prometa resolver todo o problema de operação.

Contar nomes sem apagar informação

Uma proteção limitada poderia explicar ao editor que duas entradas idênticas representam um só destino. Uma rejeição proposta na criação poderia exigir a retirada da cópia, sem obrigar previamente todo objeto com destino único a passar por uma mudança mais ampla. O objetivo seria reduzir uma interpretação enganosa, não certificar um secundário ou declarar a zona resistente a falhas.

Mas comparar linhas inteiras ou apagar qualquer hostname repetido seria grosseiro. Letras maiúsculas e minúsculas, ou um ponto final opcional, não criam necessariamente nomes DNS diferentes. Em contrapartida, a descrição atual permite certos endereços IPv4 ou IPv6 depois de um nome situado no domínio delegado. Duas entradas que guardam dados glue legítimos e diferentes precisam ser preservadas, mesmo quando compartilham o nome de destino.

A interface pode mostrar o total bruto de atributos e, separadamente, o total de nomes canônicos distintos. Resultados de autoridade ou alcance podem aparecer em outra indicação, com data e escopo. Assim, ninguém precisa supor que um número de nomes seja um número de máquinas ou de dependências independentes. Dados de apoio continuam disponíveis, e a melhora na apresentação não promete uma arquitetura que nunca foi medida.

Fontes