Resumo

  • RFC 5855 criou espaços de nomes próprios para os servidores das zonas reversas IPv4 e IPv6 e previu glue na zona pai, permitindo que as duas árvores fossem operadas por conjuntos diferentes.
  • O RFC não obriga essa separação. A escolha dos operadores cabe a uma função da IANA, e nomes distintos não provam que redes, rotas ou domínios de falha sejam independentes.

Uma consulta reversa começa com um endereço, mas só encontra o nome correspondente depois que o resolvedor localiza os servidores autoritativos da zona. Essa descoberta também depende de infraestrutura. Se o endereço de um servidor de nomes não puder ser obtido, a consulta termina antes de chegar ao PTR.

Esse foi o trajeto abordado por RFC 5855, Nameservers for IPv4 and IPv6 Reverse Zones. Publicado como Best Current Practice em maio de 2010, o documento foi escrito em conjunto por Joe Abley e Terry Manderson. Ele registrou a configuração daquele período: parte dos servidores raiz atendia IN-ADDR.ARPA, enquanto sistemas operados por APNIC, ARIN, ICANN, LACNIC e RIPE NCC atendiam IP6.ARPA.

A proposta deu a cada árvore reversa um espaço estável para nomear seus servidores. Os de IPv4 ficariam sob IN-ADDR-SERVERS.ARPA; os de IPv6, sob IP6-SERVERS.ARPA. A zona pai ARPA publicaria os endereços IPv4 e IPv6 de glue necessários para chegar a esses servidores. Com isso, a delegação poderia fornecer o próximo destino sem exigir que o resolvedor iniciasse outra busca recursiva para descobrir o endereço de um servidor de IP6.ARPA.

Os exemplos de consulta no RFC mostram o efeito operacional. A antiga referência de IP6.ARPA podia chegar sem glue na seção adicional. O resolvedor precisava pesquisar primeiro o nome de um servidor e só então consultar a zona reversa. RFC 5855 traz essa dependência para o desenho da delegação: nomes próprios e endereços na zona pai deixam o percurso mais direto e mais fácil de inspecionar. É uma mudança discreta em um ponto pelo qual todas as consultas reversas passam.

O documento também compara o tamanho codificado dos nomes NS. No exemplo histórico de IPv6, eram 74 bytes; no conjunto proposto sob IP6-SERVERS.ARPA, 39. Essa é uma contagem de bytes na representação DNS, não uma medição de latência ou de falhas. A comparação mostra como sufixos comuns podem ser comprimidos numa referência consultada com frequência e como o destino seguinte fica mais explícito.

A divisão dos nomes também pretendia permitir uma divisão operacional. O RFC diz que as zonas reversas IPv4 e IPv6 podem ser delegadas a conjuntos distintos de servidores, reduzindo a chance de uma falha numa família afetar as consultas da outra. Mas não transforma essa opção em requisito. Não determina empresas, instalações, provedores de trânsito ou rotas diferentes. O próprio documento observa que, dentro de cada família, o espaço de nomes dos servidores e a zona reversa correspondente podem compartilhar o mesmo destino em caso de falha. Um limite no espaço de nomes abre uma possibilidade; não atesta isolamento físico ou de rede.

O texto é explícito sobre quem toma a decisão restante. A seção da IANA registra as novas delegações e os endereços de glue, mas afirma que a escolha dos operadores está fora do escopo do RFC e cabe a uma função da IANA conforme o memorando de entendimento entre IETF e ICANN. RFC 5855 define, portanto, uma interface técnica e a passagem de responsabilidade que a acompanha. Não certifica quem opera cada servidor hoje nem quanto isolamento há entre os conjuntos.

A trajetória de Manderson aparece dos dois lados dessa fronteira. Ele é coautor do RFC, listado entre seus documentos no Datatracker da IETF. Uma história posterior do RSSAC registra que ele assumiu a gestão do departamento DNS Operations da ICANN em 2013; em 2014, a equipe passou para a ICANN IT e recebeu o nome DNS Engineering. Uma entrevista da ICANN o identifica como diretor naquele momento. Esses registros demonstram experiência operacional, não que Manderson tenha projetado, escolhido ou implantado sozinho os operadores do RFC.

Esse limite torna a norma mais útil para análise. Ela separa o que o protocolo consegue nomear daquilo que a organização dos operadores precisa decidir. Para saber se o DNS reverso de IPv4 e IPv6 realmente falha de forma independente, é preciso examinar os conjuntos NS em serviço, o glue, a hospedagem, as rotas e as respostas. Dois sufixos diferentes numa especificação não respondem a isso.

Fontes