Resumen

  • Las delegaciones inversas que ofrece ARIN siguen los componentes de la asignación directa: un /23 se divide en dos /24, pero un /16 conserva una sola delegación /16.
  • La excepción a la autoridad compartida depende del bloque del proveedor del que procede la entrega, no solo del tamaño recibido por el cliente. Una subdelegación DNS es una vía distinta y requiere coordinación con la zona padre.

Más direcciones, menos piezas separadas

En los ejemplos de ARIN, un bloque de 512 direcciones permite administrar dos delegaciones inversas por separado. Otro de 65.536 presenta una sola. La diferencia parece extraña únicamente si se supone que el registro construye sus controles a la medida de cada cliente que aparece después.

La guía de DNS inverso de ARIN parte de otra unidad: los bloques CIDR que componen una Direct Allocation, una asignación directa. Para cada componente crea las delegaciones de mayor tamaño que admite. En IPv4 trabaja con límites /8, /16 y /24; /24 es el tamaño mínimo admitido. Por eso su ejemplo /23 produce dos delegaciones /24, cuyos servidores de nombres se gestionan por separado, mientras que el ejemplo /16 produce una delegación a ese nivel.

No cabe concluir que el titular del /16 tenga menos poder total sobre sus recursos. Tiene un objeto que abarca más espacio. Lo que cambia es la granularidad de los objetos que el registro permite editar independientemente. Tampoco basta con encontrar cualquier agregado superior /16 y aplicar la regla: la documentación se refiere a los componentes de la asignación directa, no a cualquier agrupación que alguien dibuje sobre una lista de redes.

El alcance también es importante por familia de direcciones. ARIN describe para IPv6 fronteras de cuatro bits. La excepción vinculada a /16 que interesa aquí pertenece al tratamiento de IPv4; no es una regla general sobre la autoridad de todos los clientes del registro.

La entrega no crea por sí sola otro mando

Supongamos, sin atribuirlo a un proveedor real, que una empresa recibe un /24 procedente del /16 de su ISP. La empresa puede necesitar que sus propios servidores respondan a las consultas inversas de esas direcciones. El inventario comercial dice qué recibió; todavía no dice quién puede cambiar la delegación pertinente.

ARIN contempla la gestión conjunta del DNS inverso mediante autoridad compartida para titulares directos e indirectos que cumplan las condiciones. Una organización autorizada que aparece para la zona puede intervenir en la gestión correspondiente a las direcciones que le fueron delegadas. Pero la guía excluye expresamente las reasignaciones a usuarios y las redistribuciones a otros proveedores —reassignments y reallocations, respectivamente— que proceden del bloque /16 o mayor de un ISP.

La condición mira hacia arriba. No dice que la excepción solo se active cuando el cliente recibe un /16 completo. También importa el /16 de origen en el ejemplo del cliente /24. «Mayor», además, significa más direcciones: un prefijo numéricamente más corto, no cualquier cifra superior a 16 detrás de la barra.

El registro de la entrega y la delegación DNS son, por tanto, dos instrumentos distintos. La documentación de gestión de recursos permite modificar el nombre de una red, sus contactos y sus comentarios públicos mediante una modificación de red; esa operación no cambia el DNS inverso. Una descripción general de derechos sobre registros no anula la salvedad específica de la guía DNS. Leer ambas con su ámbito propio resulta más útil que presentar la diferencia como una contradicción.

La misma distinción aparece al terminar una relación. ARIN indica al ISP que retire el registro de reasignación o reallocation del cliente desconectado para quitar la autoridad compartida. La instrucción describe cómo se extingue un permiso asociado al registro. No demuestra que haya permisos abandonados en una red concreta, ni justifica retirar el registro de un cliente que sigue utilizando el servicio.

El siguiente responsable está en la zona padre

Que el cliente no disponga de un control separado en ARIN no significa que deba renunciar a administrar su DNS. Significa que hay que buscar el punto de entrega en otra capa.

El RFC 1034 describe la jerarquía de zonas y la delegación de subzonas por su operador. El padre publica los registros NS correspondientes y, cuando hacen falta, los datos de enlace para localizar los servidores. La información a ambos lados del corte debe ser coherente. El ISP o su operador DNS puede organizar así una zona hija para el cliente sin entregarle la cuenta de ARIN ni el derecho de alterar toda la delegación /16.

En el supuesto de un /24 bajo un /16, esa es una subdelegación DNS ordinaria. Se conserva una responsabilidad en el padre: alguien debe establecerla y actualizarla cuando cambie el enlace con el hijo. La autonomía para editar los datos dentro de una zona no elimina ese trabajo. Tampoco una posibilidad prevista por el protocolo demuestra que cierto proveedor la venda, la admita en su portal o la incluya en su soporte. Esas serían afirmaciones sobre un servicio concreto que estas fuentes no permiten hacer.

Para conjuntos de menos de 256 direcciones IPv4 existe la técnica descrita en el RFC 2317. Añade nombres delegados y enlaces CNAME para permitir la gestión sin alterar el mecanismo de búsqueda del DNS. El padre sigue participando. No es una prueba de que ARIN cree delegaciones /25 arbitrarias, ni hace falta invocarla para explicar todo /24 delegado bajo un /16. Confundir ambos casos convertiría una solución para límites menores en una supuesta obligación universal.

El relevo entre registro y proveedor tiene, pues, una forma concreta. ARIN mantiene un determinado objeto de delegación; el operador de esa zona puede preparar una entrega más estrecha. Son decisiones conectadas, no intercambiables.

La selección importa más que la etiqueta del cliente

Las operaciones Reg-RWS muestran cómo se representa esa diferencia. Los objetos de delegación aparecen y desaparecen junto con las redes asociadas, sin creación o borrado independiente. Se identifican por el nombre de la delegación, no por un identificador NET. La documentación permite consultar las delegaciones de un NET y obtener el estado actual antes de modificarlo. Esta lectura no equivale a haber probado una cuenta o confirmado permisos en una red real.

La interfaz también obliga a mirar el objeto efectivo. Según la guía de gestión DNS en ARIN Online, se muestran las zonas inversas, los servidores, las etiquetas de clave DS y las organizaciones con autoridad compartida. Al cambiar servidores, los nuevos valores sustituyen a los anteriores en todas las delegaciones seleccionadas. Saber que se atiende a un cliente /24 no es suficiente si la operación apunta a otra extensión.

La guía fija 86.400 segundos como TTL cuando el campo queda vacío y distingue la actualización inmediata de la base de datos de la visibilidad DNS, que puede tardar hasta 24 horas. Esa previsión no acredita una interrupción observada ni promete que todos los cachés del mundo caduquen al mismo tiempo. Su utilidad aquí es recordar que guardar una selección y comprobar su efecto son actos distintos.

La documentación disponible el 3 de septiembre de 2026 permite reconstruir un límite de administración. No permite contar cuántos clientes han tropezado con él: no se han ensayado permisos, medido consultas DNS, seguido migraciones ni observado denegaciones para este artículo. Un PTR correcto tampoco prueba el encaminamiento, la propiedad o la identidad completa de quien utiliza una dirección. La conclusión es más acotada y más práctica: antes de pedir acceso, conviene saber qué zona debe cambiar y quién tiene a su cargo el enlace con la siguiente.