Resumen

  • RFC 3375 definió requisitos para un sistema compartido donde varios registradores administraban objetos patrocinados, mientras un único registro conservaba la autoridad de cada espacio de nombres y zona.
  • El documento mantuvo separados identidad, patrocinio, asociación con recursos comunes, transferencia, estado de la transacción y publicación DNS. Una confirmación en el registro no demostraba por sí sola el resultado público.

Para un titular, registrar un dominio parece una compra ordinaria. Elige una empresa, envía datos y recibe una confirmación. Detrás del mostrador, sin embargo, el registrador se autentica ante otro sistema: el registro. Ese registro conserva el repositorio central de delegaciones y proyecta una parte de sus datos hacia las zonas DNS. La cadena funciona porque sus participantes no poseen la misma autoridad.

RFC 3375 apareció en septiembre de 2002 como documento Informational. No era un estándar de Internet ni una encuesta de despliegue. Formulaba las capacidades de un protocolo genérico entre registro y registradores en una época en que múltiples empresas ya necesitaban trabajar sobre un mismo inventario de nombres sin convertirse en una sola organización.

La terminología establecía el reparto. El registrante o titular solicitaba nombres mediante un registrador. El registrador daba servicio al público y enviaba operaciones al registro. El registro administraba la base central vinculada a delegaciones y normalmente generaba y distribuía archivos de zona. En un sistema compartido, varios registradores independientes accedían a esa función común.

Abrir la interfaz comercial no fragmentaba la autoridad técnica. Según RFC 3375, había uno y solo un registro autoritativo para un espacio de nombres y una zona determinados, aunque el mismo registro pudiera servir a varios. El registrador obtenía facultades para gestionar objetos concretos; no adquiría soberanía sobre el espacio donde esos objetos existían.

El protocolo debía ofrecer sesiones, consultas, creación, modificación, renovación, borrado y transferencia. También debía identificar y autenticar a clientes y servidores, comprobar autorizaciones y devolver estados comprensibles. Cada operación modificadora llevaba un identificador de transacción exclusivo del registro. Era una pieza esencial de auditoría, pero no una prueba universal: decía qué había procesado el registro, no si el cambio ya estaba en todos los servidores DNS ni qué veía un resolvedor con caché.

La identidad del objeto se diseñó para sobrevivir a la custodia. Los identificadores tenían que ser globalmente únicos y permanecer invariables durante la vida del objeto en un repositorio, incluso si cambiaba el control administrativo. Así, transferir un dominio no obligaba a fingir que el nombre anterior había desaparecido y otro acababa de nacer. La continuidad del identificador permitía reconstruir la historia.

Los objetos compartidos mostraban por qué la asociación tampoco equivalía a control. Un servidor de nombres administrado por el registrador X podía dar autoridad a un dominio patrocinado por el registrador Y. Y necesitaba poder asociar ese servidor existente a su dominio, pero no modificarlo. Si cada referencia concediera administración, cualquier usuario indirecto podría afectar a todos los demás dominios que dependían del recurso.

La transferencia modificaba el patrocinador siguiendo un proceso. El registrador que aspiraba a ser nuevo administrador iniciaba la solicitud. El protocolo debía confirmar la autorización, indicar el estado, enumerar objetos asociados que se trasladarían, permitir cancelar antes de la decisión y comunicar aceptación o rechazo. Los servidores registrados dentro del dominio podían acompañar al dominio. La operación no era un simple cambio de etiqueta.

RFC 3375 también aceptó que hubiera registros gruesos y delgados. El modelo grueso reunía datos técnicos y datos sociales o de contacto en el registro. El delgado repartía parte de estos últimos entre registro y registradores. Los requisitos genéricos buscaban una base interoperable para ambos modelos, no imponer una topología única de base de datos.

La salida hacia DNS constituía otro límite. RFC 1034 y RFC 1035 explican zonas, servidores autoritativos, cachés y resolución. RFC 2136 define actualización dinámica de una zona. RFC 3375 habla de objetos de registro y de la responsabilidad de generar archivos de zona. Una renovación o un cambio de contacto puede completarse sin alterar DNS; una nueva delegación puede ser aceptada y todavía requerir generación, distribución y carga. La respuesta a una orden y el resultado observable no son el mismo recibo.

RFC 2832 había documentado el Registry Registrar Protocol. Después, RFC 3730 especificó EPP; RFC 5730 lo reemplazó como base, y RFC 5731, RFC 5732 y RFC 5733 desarrollaron los mapeos de dominio, host y contacto. La secuencia muestra una interfaz que se volvió más precisa. No demuestra que todos los registros adoptaran cada función o compartieran el mismo tiempo de publicación.

RFC 2119 ayuda a interpretar los verbos normativos: una obligación del diseño no confirma que un operador real la haya implementado. RFC 2277 añade la exigencia histórica de internacionalización. En una infraestructura global, caracteres, lenguas humanas, datos de contacto e identificadores DNS planteaban problemas relacionados pero no idénticos.

La idea de Lu Heng sobre una especificación inicial mínima explica la economía del documento: acordar el núcleo necesario para cooperar y dejar decisiones posteriores a cada contexto legítimo. Su marco de capas de realidad propone una disciplina de evidencia. Petición del titular, autorización del registrador, patrocinio, aceptación del registro, estado del repositorio, generación de zona, servicio autoritativo y observación del resolvedor forman una cadena; ningún eslabón resume toda la cadena.

RFC 3375 permitió imaginar un mercado con muchas puertas y un espacio de nombres coherente. Un objeto podía cambiar de administrador sin perder identidad. Un recurso podía servir a varios dominios sin quedar bajo el control de todos sus usuarios. Y una operación podía ser correcta en el registro antes de volverse visible en DNS. La separación de poderes hizo escalable el sistema; la separación de pruebas lo hace auditable.

Fuentes