Resumo

  • O pai publica CNAMEs por endereço para zonas-filhas com nomes convencionais.
  • A filha controla PTRs, enquanto o pai mantém o caminho que permite alcançá-los.
  • A resposta não comprova alocação, ROA, aceitação BGP, DNS direto, autenticação de e-mail nem serviço ativo.

O exemplo do RFC 2317 divide 192.0.2.0/24 entre um /25 e dois /26. O DNS reverso tradicional só oferece um corte natural no limite do /24. Como uma zona só pode ser delegada uma vez, sem outro mecanismo uma organização teria de administrar todos os PTRs.

A solução cria nomes como 128/26, delega-os com NS e instala no pai um CNAME para cada endereço. A consulta de 192.0.2.129 segue para 129.128/26.2.0.192.in-addr.arpa, onde a filha publica o PTR. A barra é apenas parte do rótulo DNS; o RFC permite outras convenções e até alvos fora de in-addr.arpa.

O ganho de compatibilidade deslocou trabalho. Quase 256 aliases podem ser necessários. A folha passa a depender de mais um operador. O RFC recomenda secundários no pai para contornar comportamento antigo e veta repetir a técnica, pois CNAME apontando para CNAME reduz robustez.

Um PTR continua sendo um registro de nome. O A direto é separado. Certificados de recursos e ROAs do RFC 6480 tratam de alocação e autorização de origem. SPF, DKIM e DMARC tratam de identidades e alinhamento de e-mail. BGP, encaminhamento, porta e aplicação produzem recibos próprios. Nenhum deles nasce do alias reverso.

Assim, o RFC 2317 tornou a administração granular sem tornar a autoridade total. A consulta alcança a filha porque o pai decidiu manter a ponte.