Resumen

  • La revisión 01 de un Internet-Draft individual registra dos asignaciones completadas por Expert Review el 20 de agosto de 2026: UNECE recibió el tipo DNS 69 e ISO el 70. IANA ya publica ambos números, pero el borrador no es un RFC ni una adopción del grupo DNSOP.
  • El formato conserva literalmente el código mantenido fuera de IANA y omite el año de edición. El borrador aconseja usar el inicio de validez del RRSIG para hallar la revisión histórica pertinente, aunque la firma no contiene el identificador ni la huella de esa revisión externa.

La novedad cabe en dos filas del registro de parámetros DNS de IANA. UNECE aparece con el valor decimal 69; ISO, con el 70. La fecha es 20 de agosto de 2026 y cada fila enlaza una solicitud técnica distinta.

Asignar el sobre no equivale a escribir el diccionario que va dentro.

La revisión 01 de draft-woodcock-faltstrom-external-registry-rrtypes fue cargada el 9 de septiembre. El apéndice y la comparación oficial dicen que el único cambio frente a la revisión 00 es dejar constancia de los números y del Expert Review concluido el 20 de agosto. El expediente Datatracker, su historial y el registro de la API siguen mostrando un Internet-Draft individual activo, sin RFC, stream ni Area Director responsable.

El encabezado propone Standards Track. No certifica que el grupo lo haya adoptado. RFC 6895 utiliza Expert Review para asignar RRTYPEs y RFC 8126 define ese examen como una evaluación de expertos designados. La escasez numérica recibe control; el texto normativo mantiene su propio recorrido.

La semántica no se muda a IANA

El diseño evita copiar las listas UNECE e ISO a subregistros de IANA. El RRTYPE nombra a la organización mantenedora. Un discriminador identifica luego una recomendación o estándar concreto, y el campo Code lleva el valor exactamente como lo publicó esa autoridad. No hay conversión de mayúsculas y minúsculas. El emisor no puede acuñar un código.

Las solicitudes públicas de UNECE e ISO explican el motivo: TXT obliga a convenios privados y pierde estructura; un espejo generaría un segundo dueño aparente. Las listas siguen bajo las superficies de recomendaciones UNECE y mantenimiento de ISO 3166. RFC 6116 ya había mostrado una separación parecida al usar en ENUM códigos E.164 administrados fuera de IANA.

Un receptor que no conozca el discriminador o el código debe transportarlo y mostrarlo sin interpretarlo. No puede invalidarlo solo por ser nuevo. Esta regla favorece la evolución, aunque obliga a la aplicación consumidora a reconocer explícitamente el estado «desconocido».

El identificador estable omite la edición

Para mantener compatibilidad futura, el token 3166-1, 4217, 639 o 20 no añade año, enmienda ni corrección. Una actualización del catálogo externo no exige otro tipo DNS ni otro discriminador. Los octetos pueden permanecer iguales durante varias ediciones.

La continuidad externa no es uniforme. El borrador describe códigos UNECE retirados que siguen marcados en las listas, monedas ISO 4217 históricas con fecha de retiro, identificadores ISO 639 que no se reasignan y códigos ISO 3166 sometidos a reserva temporal, aunque ha habido reasignaciones. Por eso una aplicación no puede convertir «mismo código» en «mismo significado histórico» sin mirar la política del mantenedor.

El texto exige que la lista esté activa, sea citable y accesible gratuitamente cuando el emisor publica el RR. También pide que futuras especificaciones documenten el tratamiento de bajas y reasignaciones. Es una condición de entrada valiosa. No dice qué copia concreta abrió el receptor después.

La fecha del RRSIG necesita un puente

Cuando importa la historia, la propuesta indica que el código se lea según la revisión externa vigente al comenzar el RRSIG que cubre el RRset. El criterio fija un tiempo, pero no una versión.

RFC 4034 define Signature Inception como el primer momento en que la firma puede autenticar el conjunto. El RRSIG contiene también expiración, algoritmo, key tag y nombre del firmante. No incluye el número de publicación UNECE, una edición ISO, la URL recuperada ni una suma criptográfica de la tabla. RFC 9364 sitúa esas propiedades en la autenticación e integridad de DNSSEC, no en la conservación de catálogos ajenos.

Además, una zona puede volver a firmar el mismo RDATA. Cambia el inicio de la firma sin que cambie el código. Una organización externa puede publicar otra tabla mientras la firma anterior sigue dentro de su periodo válido. El software todavía debe correlacionar hora, archivo y política.

No hay aquí evidencia de una interpretación incorrecta, una disputa o una implantación. La conclusión es más limitada: la validación de los octetos y la identificación de la edición que les dio sentido son pruebas distintas.

Registrar la resolución, no duplicar la autoridad

Propongo una constancia local de resolución del registro externo. Contendría RRTYPE, discriminador, valor y código originales; mantenedor; edición exacta o, si no existe un número estable, URL, hora de consulta y huella del contenido; inicio, expiración, firmante y resultado del RRSIG; regla de retiro o reasignación aplicada; salida ante código desconocido; versión de la política emisora; y decisión local que consumió el significado.

La constancia no vuelve verdadera una tabla ni autoriza el acto posterior. Solo conserva el camino probatorio. Si el sitio cambia, queda visible qué material se usó. Si una nueva firma cubre datos idénticos, no se reescribe por accidente la historia del código. Si dos sistemas discrepan, la diferencia se puede localizar en la fuente, la fecha o la política.

La idea sigue la especificación inicial mínima de Heng Lu: fijar una frontera verificable pequeña y dejar la política dentro de cada dominio. The Policy Mirror aporta la disciplina de reconstruir regla, autoridad y resultado. La constancia es mi recomendación, no una exigencia del borrador.

Los números 69 y 70 ya tienen sitio en DNS. La versión externa utilizada para actuar necesita un sitio igual de claro en la evidencia local.

Fuentes