Resumen

  • RFC 5395 distribuyó la autoridad de asignación entre bits de cabecera, OpCodes, RCODE, tipos de datos, QTYPE, Meta-TYPE y CLASS; compartir 16 bits no convierte esos espacios en uno solo.
  • Los RRTYPE 65280–65534 son de uso privado. Pueden sostener acuerdos locales, pero IANA no registra sus significados ni evita que dos sitios los usen de manera incompatible.
  • La prueba debe conservar registro y campo, valor, procedimiento, fecha del estado IANA, versión de implementación, interpretación del par y resultado; “funciona” no sustituye esa cadena.

El choque estaba aplazado, no resuelto

RFC 8126 define Private Use como uso privado o local. IANA no registra asignaciones en esas franjas y no intenta impedir que múltiples sitios usen el mismo número con propósitos diferentes. La responsabilidad de evitar conflictos pertenece a quienes delimitan el experimento.

Eso explica por qué ambos laboratorios podían estar correctos. Cada uno había controlado su propio dominio. El problema surgió cuando la frontera cambió sin cambiar el código. Un resolver compartido, un repositorio de zonas o una API común vio 65300 y no tenía un hecho global para elegir entre dos RDATA incompatibles.

La solución no consiste en declarar ilícito el uso privado. Consiste en tratarlo como autoridad acotada. El registro interno necesita propietario, sistemas participantes, duración, formato, controles para impedir salida, dominio de colisión y plan de retiro. Una fusión, federación o exposición pública debe activar una revisión antes de que el valor cruce.

También es incorrecto refugiarse en un número “Unassigned”. No asignado indica que el registro no contiene una asignación, no que el primero en desplegar se convierta en propietario. Una asignación legítima posterior puede reutilizar ese mismo entero y convertir la práctica previa en colisión. Private Use al menos declara explícitamente el régimen local.

La tabla no era un espacio uniforme

RFC 5395 trataba varios registros DNS. Los tipos de recurso se dividían en data TYPE, QTYPE y Meta-TYPE. Los primeros almacenan datos. Los QTYPE aparecen en consultas. Los Meta-TYPE representan información transitoria asociada al mensaje y, en algunos casos, también se consultan.

Las políticas cambian según rango y función. Un valor de dos octetos no adquiere la misma autoridad por compartir tamaño. Tampoco una columna genérica type puede mezclar sin contexto un RRTYPE con una CLASS o un OpCode. El nombre exacto del registro forma parte de la identidad.

La distinción se vuelve práctica en migraciones. Si una base guarda sólo número y etiqueta, puede unir 16 de un espacio con 16 de otro. Si una herramienta conserva el número pero pierde si era data TYPE o Meta-TYPE, puede intentar cachear información transitoria. Un esquema correcto usa registro, campo, función y versión como clave, no el entero aislado.

RFC 5395 es además una fotografía histórica. RFC 6195 lo sustituyó en 2011 para cambiar de manera significativa la lista de revisión pública. RFC 6895 sustituyó a RFC 6195 en 2013, simplificó el proceso de RRTYPE y cerró el registro de subtipos AFSDB. La tabla IANA congelada aquí representa el estado mantenido en 2026. Las cuatro piezas son compatibles porque responden a tiempos distintos.

El código 16 necesitaba saber dónde vivía

Los RCODE pueden aparecer en la cabecera, en OPT, en TSIG y en TKEY. OPT amplía la anchura efectiva del código. RFC 5395 mostraba 16 como BADVERS en OPT y BADSIG en TSIG. RFC 6895 preservó la excepción y añadió una explicación contextual para el número 9.

Un sistema de observabilidad que registra sólo 16 no ha normalizado el dato; lo ha mutilado. El mismo entero puede enviar al equipo hacia una negociación de versión o una verificación de firma. La corrección requiere conservar el RR contenedor, el campo, la anchura, el mensaje, el par y la especificación aplicada.

Por eso RFC 6895 impide, salvo las excepciones históricas, asignar el mismo número a errores diferentes aunque aparezcan en RR distintos. Reducir contextos implícitos es una forma de seguridad operacional: hace que una alerta llegue al dueño correcto y que la remediación no se base en una lectura inventada.

El bit libre podía ser una copia

Algunos bits de la cabecera tienen sentido teórico sólo en consulta o sólo en respuesta. RFC 5395 advertía que ciertas implementaciones construían la respuesta copiando primero la cabecera de la consulta. Un bit no limpiado podía regresar sin que el servidor pretendiera afirmar nada nuevo.

Asignar a ese bit otro significado en la dirección opuesta habría convertido una copia mecánica en una orden. El bit Z llevaba incluso una conducta antigua: algunos sistemas lo habían leído como exigencia de que respondiera el servidor primario. El RFC creía que los sistemas actuales lo ignoraban, pero exigía Standards Action para reutilizarlo.

No es una medición de los servidores de hoy. Es una advertencia sobre el inventario invisible. La posición vacía del diagrama no demuestra que el ecosistema carezca de estado. Hacen falta autoridad pública y pruebas con implementaciones reales antes de declarar que un bit está disponible para semántica nueva.

El examen reservó identidad, no entregó servicio

Para ciertos RRTYPE, RFC 5395 creó una política específica de Expert Review. RFC 6895 la simplificó: plantilla completa, lista dedicada, experto nombrado por IANA, aprobación o rechazo explícito y archivo público.

El tipo de datos debe poder viajar como RR desconocido conforme a RFC 3597, o el Meta-TYPE debe ser opcional y seguro de descartar. Una descripción incompleta, supuestos DNS erróneos, procesamiento incompatible o demasiados valores son causas de rechazo. Standards Action con asignación temprana queda disponible para otros casos.

La aprobación prueba una decisión. No prueba que BIND, Knot, PowerDNS o cualquier producto concreto implemente el tipo; estas fuentes no miden productos. Tampoco prueba que una interfaz de aprovisionamiento lo acepte, que un secundario lo transfiera, que una aplicación lo entienda o que el usuario vea el resultado.

El registro puede adelantarse al despliegue para evitar colisiones. Esa ventaja se pierde si la organización usa la fila registrada como certificado de ejecución. El expediente debe separar plantilla y decisión de la matriz de versiones, las capturas y el resultado.

Transportar octetos no era comprenderlos

RFC 3597 permite representar un RR desconocido con TYPE y el número decimal, seguido de \#, longitud y RDATA hexadecimal. Define además reglas para compresión y comparación. Así un servidor puede almacenar, transferir y devolver un tipo nuevo sin conocer su semántica.

El mecanismo habilita evolución gradual. Sin embargo, un secundario que conserva los bytes sólo demuestra custodia. Un resolver que los devuelve demuestra acceso. La aplicación puede ignorarlos, rechazarlos o interpretarlos mal. El último salto sigue sin probarse.

Una prueba seria atraviesa la cadena: entrada de zona, parser, representación textual, cable, transferencia, caché, API, consumidor y resultado. Debe incluir negativos y vuelta completa. Un tipo conocido escrito en formato genérico sigue siendo conocido después de parsearse y conserva sus reglas específicas; el disfraz textual no borra la obligación semántica.

Un registro vivo exige fecha

La captura IANA de esta investigación informa actualización el 28 de agosto de 2026. Contiene asignaciones, referencias y estados que RFC 5395 no podía anticipar, además de rangos no asignados, reservados y privados. El documento antiguo y la tabla viva no compiten: uno registra una decisión histórica; la otra incorpora acciones posteriores.

Por eso “según IANA” necesita nombre exacto del registro, formato y hora de consulta. HTML, XML, texto, módulos generados y copias integradas pueden desincronizarse. La gobernanza se verifica comparando versiones y hashes, no confiando en la marca del archivo.

Límite de la evidencia

Las fuentes congeladas prueban el texto y la sucesión de RFC 5395, 6195 y 6895, las reglas de RR desconocidos, el significado general de Private Use y el estado capturado de IANA. No prueban una colisión real, un incidente, un producto defectuoso ni la adopción actual de una función.

La conclusión permanece firme: elegir un entero, obtener una asignación, aparecer en el registro, atravesar infraestructura, ser comprendido y producir resultado son hechos distintos. Una organización que conserve esos recibos puede innovar rápido sin presentar una convención local como autoridad mundial.