Resumen

  • RFC 3405 exigía que el esquema URI o espacio URN, su especificación estable y su autoridad reconocida existieran antes de publicar una regla NAPTR en uri.arpa. o urn.arpa.. Una sintaxis DNS válida no creaba potestad.
  • Las zonas compartidas debían usar TTL extraordinariamente largos. Las reglas propensas al cambio se delegaban a otra zona con TTL menor, detrás de una pista inicial estable.

Un TTL largo suele verse como un obstáculo. RFC 3405 lo convirtió en una materia de arquitectura. Si una entrada global podía sobrevivir años en cachés, no debía contener la política más variable; debía señalar de manera duradera a quien podía mantenerla.

Publicado como Best Current Practice 65 en octubre de 2002, el documento cerró la serie DDDS. RFC 3401 explicó el marco, RFC 3402 el algoritmo, RFC 3403 las reglas NAPTR en DNS, RFC 3404 los servicios URI y URN, y RFC 3405 las asignaciones de uri.arpa. y urn.arpa..

No era un apéndice burocrático. Determinaba quién podía escribir el primer paso en un espacio DNS mundial, cómo demostraba su autoridad y qué capa podía cambiar deprisa. El procedimiento de registro formaba parte del comportamiento ejecutable.

Un esquema URI suministraba la primera clave bajo uri.arpa.. En los URN, la entrada urn extraía el identificador del espacio y trasladaba la búsqueda a urn.arpa.. Una regla pequeña, situada al comienzo, podía redirigir una familia completa de identificadores.

El NAPTR no podía inventar la autoridad que decía representar. El esquema necesitaba registro y especificación estable previos; el NID debía completar su propio proceso. La pista de resolución sucedía a la legitimidad del espacio, no la otorgaba retrospectivamente.

El orden impedía usar urn.arpa. para evitar la revisión de un namespace y evitaba que una regla de URI basada en DNS delegara hacia alguien distinto del titular del nombre incluido. Una expresión técnicamente bien formada podía seguir siendo un secuestro de autoridad.

La revisión examinaba corrección, solidez, coherencia con la especificación y respeto de la titularidad DNS. Si el documento estaba controlado fuera del IETF, cualquier incorporación o cambio posterior necesitaba además el permiso del dueño o mantenedor. Revisión experta y autorización respondían a preguntas diferentes.

En un NID, el control alcanzaba todos sus NAPTR aunque una regla afectara solo a una parte del espacio. Reducir el alcance del patrón no eliminaba la autoridad del mantenedor.

La plantilla pedía Key, Authority y Records. Key seleccionaba la ranura global; Authority identificaba al solicitante autorizado; Records describía la delegación ejecutable. Era una cadena de procedencia, no solo texto de zona.

La vía original utilizaba listas abiertas y dos semanas para objeciones. Estas solo podían tratar el impacto sobre la zona o DNS. Los méritos del esquema o NID ya aceptado pertenecían al foro anterior. Cada capa discutía lo que controlaba.

IANA operaba zonas y listas. La centralización operativa no significaba autoría central: las autoridades del identificador aportaban derecho y especificación, los revisores medían el riesgo compartido, IANA publicaba y los operadores delegados mantenían las reglas variables.

La instrucción clave hablaba de tiempo. Los registros comunes usarían TTL quizá medidos en años para reducir carga. Una política que necesitaba ajustes frecuentes no podía instalarse directamente en esa superficie.

La solución era delegación temporal. Un NAPTR estable en la zona común apuntaba a otra zona con TTL corto. La primera optimizaba estabilidad global; la segunda, cambio operativo. El mismo recorrido tenía dos relojes y dos autoridades observables.

Un caché podía conservar el primer puntero mientras renovaba las reglas posteriores. Cambiar la zona delegada no revocaba un puntero antiguo; cambiar el puntero tardaría mucho en difundirse. El recibo debe atribuir cada versión a su capa y TTL.

Algunos esquemas fijaban la siguiente clave en su sintaxis. Un URI HTTP lleva un host que una regla estable puede extraer. Otros espacios necesitaban delegación flexible a una zona aparte. La ubicación de la próxima clave definía la geometría de control.

La entrada urn mostraba gobernanza anidada: el URI genérico entraba por uri.arpa., se extraía el NID y la decisión propia del espacio ocurría bajo urn.arpa.. Una puerta común no imponía una política uniforme.

Dos erratas técnicas verificadas cambian la ejecución real. Las 2687 y 2688 corrigen \2 por \1 en dos expresiones con un único grupo de captura. Las versiones impresas son inválidas y no deben copiarse a configuración.

También envejeció la elegibilidad. RFC 3405 exigía pertenencia al «IETF tree» de RFC 2717, pero los árboles de esquemas desaparecieron. Una propuesta de arreglarlo como errata fue rechazada porque una norma no se cambia editorialmente.

RFC 8958 realizó la actualización en 2020: eliminó el árbol y exigió registro permanente conforme a BCP 35, hoy RFC 7595. Cambió la forma del portal sin alterar el orden fundamental: primero nace el espacio autorizado y después su pista compartida.

El registro IANA actual distingue estados permanente, provisional e histórico; aparecer allí no basta para URI.ARPA. El registro de namespaces URN sigue RFC 8141. Registrar el nombre y publicar la pista son actos distintos.

La página actual de .arpa sigue asignando uri.arpa a RFC 3405 y RFC 8958, y urn.arpa a RFC 3405. Eso prueba propósito infraestructural, no despliegue universal ni éxito del resolutor.

Las zonas comunes concentraban ataques de denegación y falsificación. DNSSEC podía autenticar datos publicados, pero no el permiso original, la conducta de la autoridad posterior o el recurso final.

La evidencia completa conserva estado de esquema/NID, especificación, autoridad, aprobación, solicitud, revisión, aceptación IANA, registro, DNSSEC, TTL largo, clave delegada, autoridad y TTL corto, cambio, caché, regla escogida y resultado del consumidor.

La especificación inicial mínima de Lu Heng explica los dos ritmos: estandarizar el relevo durable y localizar decisiones futuras detrás. La primacía del código operativo permite probarlo: observar DNS real, aplicar las erratas, modificar solo la zona inferior, comparar TTL y confirmar que la autoridad sigue al mantenedor registrado, no a quien sabe escribir NAPTR.

RFC 3405 hizo de la estabilidad una decisión de ubicación. La pista inicial era lenta porque no fingía ser la regla vigente. El sistema podía adaptarse porque el cambio tenía lugar, dueño y reloj propios.

Fuentes