Resumen

  • El padre conserva una zona inversa alineada por octeto y publica un CNAME por dirección hacia una zona hija convencional.
  • El operador de la hija mantiene los PTR, pero depende de que el padre conserve alias y delegación correctos.
  • El resultado describe una ruta de nombres; no acredita titularidad, autorización de origen, DNS directo, reputación ni servicio.

La dificultad no era que el DNS desconociera los CNAME. Era que una zona se delega una sola vez y el árbol in-addr.arpa no ofrece cortes naturales en cada bit. Al dividir 192.0.2.0/24 en un /25 y dos /26, tres organizaciones podían recibir rangos distintos mientras una sola zona seguía abarcando las 256 direcciones.

El RFC 2317 añadió puntos administrativos. El padre publica NS para nombres como 128/26 y, para cada dirección, un alias hacia ese espacio. La consulta de 192.0.2.129 llega primero al padre; su CNAME apunta a 129.128/26.2.0.192.in-addr.arpa; la hija responde con el PTR. El resolutor no aprende una operación nueva: sigue el alias que ya sabe procesar.

La barra y la longitud no convierten el nombre en un prefijo de encaminamiento. Son una convención legible para operadores. El propio documento permite otros nombres e incluso destinos fuera de in-addr.arpa. Lo ejecutable es la cadena de registros, no la apariencia semántica del rótulo.

La solución trasladó costes. Un /24 dividido puede exigir casi 256 CNAME en el padre. La hoja depende de una autoridad adicional. Los servidores antiguos podían devolver solo el alias, por lo que el RFC recomendó que los servidores del padre fueran también secundarios de las hijas. Y la técnica no debía repetirse para subdividir otra vez el mismo espacio: encadenar CNAME debilitaba la robustez.

Que el PTR funcione responde a una pregunta limitada. El DNS directo se mantiene aparte; por eso el RFC 1912 pide coherencia entre PTR y A. La autorización de origen se mantiene aparte; el RFC 6480 define certificados de recursos y ROA con prefijos y un AS autorizado. El correo mantiene SPF, DKIM y DMARC, además de memoria de reputación y política del receptor. La disponibilidad requiere ruta, entrega de paquetes, puerto y aplicación.

Nada de ello está dentro del alias del padre. Un PTR puede nombrar una máquina inexistente. Una ruta puede existir sin PTR. Un bloque puede tener ROA y carecer de servicio. La utilidad surge precisamente de no confundir estas capas.

El logro del RFC 2317 fue hacer delegable la administración inversa de rangos pequeños sin cambiar los resolutores desplegados. No entregó las credenciales del padre ni convirtió el DNS en registro de propiedad, sistema de rutas o monitor de aplicaciones.