Resumen

  • En RFC 3632, el patrocinador actual usaba -Approve:No para rechazar una transferencia; el registrador solicitante usaba el mismo valor para cancelarla. La sesión autenticada y el estado aportaban el verbo institucional.
  • 200 Command completed successfully acredita que el servidor RRP procesó la orden. No acredita voluntad del titular, consentimiento humano, cambio de delegación DNS ni resultado público.
  • La evidencia debe enlazar actor, rol, objeto, estado previo, regla, plazo, respuesta, estado posterior y aviso fuera de banda. Sin esa unión, un registro exacto puede atribuir la decisión a la institución equivocada.

Dos actores frente a una misma palabra

La lectura habitual de un log empieza por el verbo y sus parámetros. En RFC 3632, esa costumbre conduce a un error. El documento, publicado como Informativo en diciembre de 2003, añadió a RRP 2.0.0 la posibilidad de que el registrador solicitante cancelara una transferencia pendiente. Para hacerlo reutilizó una forma ya conocida: TRANSFER con -Approve:No.

Cuando el mensaje procedía del registrador que patrocinaba el dominio, “No” era rechazo. Cuando procedía del registrador que había solicitado el cambio, era cancelación. En un caso, una institución se oponía a la petición de otra. En el otro, retiraba su propio acto. La igualdad de bytes ocultaba una diferencia de competencia.

La ficha del RFC Editor, el Datatracker, el historial y la búsqueda de erratas permiten verificar el estatus del texto. No prueban que una entidad concreta lo desplegara ni que una transferencia real siguiera sus reglas. El valor del documento no es una recomendación operativa actual, sino la claridad con la que separa comando y autoridad.

La sesión decidía quién podía hablar

RFC 2832 situaba la identidad del registrador en la sesión activa autenticada. El registro conocía además al patrocinador actual del dominio. Por eso podía resolver dos preguntas diferentes: quién estaba conectado y qué relación tenía con el objeto.

El diseño impedía que un parámetro se otorgara a sí mismo autoridad. Una carga útil puede afirmar cualquier identidad; la sesión autenticada y la base del registro son las que permiten aceptarla o negarla. Si un tercero trataba de aprobar o rechazar una transferencia, la operación debía fallar.

El mismo RFC exigía notificar fuera de banda al posible registrador saliente, mediante correo o informes. Por tanto, la historia de la transferencia no vivía en un solo canal. Parte estaba en la sesión, parte en la respuesta, parte en el estado persistente y parte en la notificación.

Había además un vacío forense deliberado: RRP no devolvía identificadores de transacción ni marcas de tiempo. Los informes diarios o semanales descritos aportaban horas en el huso local del registro. Para ordenar un caso posterior era necesario conservar correlaciones y bases temporales que el diálogo inmediato no contenía.

El plazo transformaba una orden válida en una orden tardía

RFC 3375 definía la distribución de funciones. El solicitante inicia y puede cancelar antes de que se adopte la decisión. El patrocinador vigente aprueba o rechaza. Los actores no autorizados deben ser rechazados. Ambos lados necesitan observar las solicitudes pendientes y terminadas.

La cancelación de RFC 3632 sólo era posible mientras la petición seguía pendiente: antes de una aprobación o rechazo explícito y antes de que el registro aplicara una decisión implícita al expirar su plazo. El mismo mensaje podía ser correcto en un instante e inaplicable después.

Así, el tiempo no era una anotación para analistas; era un argumento de la transición. Hacen falta la hora recibida por el servidor, la política que fijaba el plazo, el evento de cierre y los estados a ambos lados. Un timestamp del cliente no basta si su reloj o zona no están vinculados al servidor que decidió.

El borde irreversible es la pérdida de la ventana. Cuando la decisión se materializa, el solicitante ya no puede retirar aquella petición como si siguiera pendiente. Un remedio posterior pertenece a otra operación. Si el sistema sólo guarda el estado final, no podrá distinguir cancelación tardía, carrera con el temporizador o rechazo autorizado.

El código 200 tiene un sujeto limitado

El ejemplo de RFC 3632 recibe 200 Command completed successfully. Esa frase es evidencia positiva del servidor RRP. No debe devaluarse, pero tampoco ampliarse.

No demuestra que el titular del dominio ordenara la cancelación. No conserva por sí sola la aprobación interna del registrador. No prueba que cambió el patrocinio, que una zona DNS fue publicada o que un resolutor obtuvo otra respuesta. La conclusión correcta es más estrecha: el servidor procesó con éxito aquella orden dentro de su interfaz.

Lu Heng formula en On Authority and Belief la pregunta que protege el límite: ¿quién emite el enunciado y sobre qué tiene autoridad? El registro puede hablar sobre su procesamiento y sus objetos. No puede certificar por sustitución la intención de un cliente o la experiencia de un usuario.

La cadena completa mantiene columnas distintas para autorización del titular, acción del registrador, estado del registro, delegación DNS y observación del servicio. Las correlaciona sin permitir que un verde borre los interrogantes de las demás.

EPP cambió la legibilidad de la prueba

En RFC 5731, EPP separa las operaciones de transferencia: solicitar, cancelar, aprobar, rechazar y consultar. Puede presentar el identificador del cliente solicitante, su fecha, el cliente que actúa, la fecha de acción y el estado pendiente. RFC 5730 añade identificadores de transacción del cliente y del servidor.

Esta forma es menos ambigua para una exportación. La intención protocolaria ya no depende de interpretar el mismo “No” con datos externos. Sin embargo, los nuevos campos siguen necesitando custodia. Un identificador perdido por el recolector no correlaciona nada; una fecha sin reloj confiable no ordena; el cliente solicitante no es automáticamente el titular; una respuesta exitosa no prueba DNS.

RFC 3730 ofrece el puente histórico, pero ningún RFC demuestra por sí solo una migración o una implementación. El contraste sirve para diseñar recibos, no para inventar despliegues.

La validez de una representación no es un derecho sobre el nombre

Otro cambio de RFC 3632 fue el código 510 para una codificación no válida en operaciones ADD o MOD. El marco posterior de RFC 5890 diferencia con mayor precisión las formas de nombres internacionalizados.

El resultado del registro sigue siendo local: una cadena pasó o no pasó su gramática y política de entrada. Esa decisión no acredita marca, identidad, intención, seguridad visual o delegación efectiva. Confundir una representación aceptada con un nombre legítimo sería repetir el mismo error que confundir una orden aceptada con consentimiento.

Los códigos funcionan mejor cuando su etiqueta conserva el objeto: “codificación aceptada por esta interfaz”, no “nombre válido” sin complemento.

IPv6 añadió datos, no una prueba de funcionamiento

RFC 3632 permitió direcciones IPv6 completas o comprimidas en objetos de servidores de nombres. RFC 4291 define la arquitectura; RFC 5952 recomienda después una forma textual canónica.

Aceptar la cadena demuestra capacidad de representación. Guardarla demuestra una mutación del objeto. Publicarla en la delegación, anunciar su ruta, responder autoritativamente y servir a usuarios son observaciones adicionales. Pueden divergir.

Una dirección “válida” en una consola no es todavía una dirección alcanzable. La evidencia operativa necesita el objeto host, la zona padre o raíz, rutas, respuestas DNS y sondas desde puntos relevantes. Cada una tiene un emisor distinto.

El bloqueo 557 impedía que un nivel se apropiara del siguiente

RFC 3632 añadió 557 para un servidor de nombres bloqueado por estar asociado a un dominio de nivel superior. El cambio debía coordinarse fuera de banda con soporte. La interfaz ordinaria del registrador no tenía autoridad unilateral sobre aquella superficie.

La gestión contemporánea de la raíz por IANA muestra otro conjunto de controles: gestión de la zona raíz, guía para gestores de TLD, consentimiento, requisitos técnicos y API RZMS. Usuarios autenticados tienen permisos limitados; contactos o gestores autorizan; un cambio que afecta a varios TLD puede requerir a otras partes; las pruebas técnicas son una base, no garantía integral.

Estas fuentes actuales no explican una operación RRP de 2003. Demuestran una separación duradera: objeto del registro, petición autorizada a la raíz, implementación en la zona y servicio observado son hechos relacionados, no idénticos.

El recibo mínimo conserva relaciones

Un expediente útil reúne versión, sesión, identificador del registrador, rol, dominio, origen y hora de la petición, estado previo, bytes exactos, política y temporizador, evaluación de autorización, respuesta, estado posterior, avisos y decisión final. Si se afirma un resultado DNS, añade la publicación y la observación correspondientes.

El Minimum Initial Specification de Heng ayuda a evitar el exceso contrario: no hay que introducir todo el mundo institucional en la carga útil. Basta una interfaz probatoria común que permita a cada autoridad conservar su propia decisión.

Las Reality Layers impiden presentar la orden, la decisión, el registro y la realidad de red como sinónimos. Running Code Primary exige comprobar el estado ejecutado. El resultado es una pregunta más rigurosa que “¿qué decía el comando?”: “¿quién, en qué rol, cambió qué estado, bajo qué regla y antes de qué límite?”

La sintaxis de RFC 3632 no era ambigua para el servidor que conservaba actor y estado. Se volvió ambigua para el archivo que los descartó. Ésa es la advertencia vigente: la normalización técnica puede borrar la diferencia institucional que una auditoría necesita explicar.

Fuentes

  1. RFC 3632 — VeriSign Registry Registrar Protocol 2.0.0
  2. RFC 3632 en texto plano
  3. Información del RFC Editor sobre RFC 3632
  4. Registro de RFC 3632 en IETF Datatracker
  5. Historial de RFC 3632
  6. Búsqueda de erratas de RFC 3632
  7. RFC 2832 — Registry Registrar Protocol 1.1
  8. RFC 3375 — Requisitos genéricos de protocolo registro–registrador
  9. RFC 3730 — Extensible Provisioning Protocol
  10. RFC 5730 — Extensible Provisioning Protocol
  11. RFC 5731 — Mapeo de dominios EPP
  12. RFC 5732 — Mapeo de hosts EPP
  13. RFC 4291 — Arquitectura de direccionamiento IPv6
  14. RFC 5952 — Representación textual de direcciones IPv6
  15. RFC 5890 — Definiciones de IDNA
  16. IANA — Gestión de la zona raíz
  17. IANA — Gestión de un dominio de nivel superior
  18. IANA — Consentimiento para un cambio en la zona raíz
  19. IANA — Requisitos técnicos de servidores de nombres
  20. IANA — API del sistema de gestión de la zona raíz
  21. Lu Heng — On Authority and Belief
  22. Lu Heng — On Reality Layers
  23. Lu Heng — Running Code Primary
  24. Lu Heng — Minimum Initial Specification