Resumen

  • RFC 5144 creó DCHK como servicio ligero de disponibilidad dentro de IRIS.
  • active e inactive hablan de publicación DNS, no de titularidad ni de posibilidad contractual de registro.
  • reserved niega el registro ordinario aunque el nombre no esté publicado en DNS.
  • Los estados de disputa y gracia conservan fases que un «sí/no» no puede representar.
  • Crear, borrar, renovar, restaurar, transferir o actualizar puede estar pending o prohibited.
  • El atributo actor separa registro, registrador y proveedor de servicios de registro.
  • scope y la autoridad del subestado impiden convertir una afirmación local en regla universal.
  • La fecha de actualización de la base fuente no equivale a la hora de consulta o decisión.
  • Una referencia de registro dirige a otro servicio, pero no transporta credenciales ni aprobación.
  • IRIS depende del transporte para autenticación y privacidad.
  • Las asignaciones vigentes de IANA no demuestran que exista un servicio DCHK en producción.
  • Cada cambio irreversible exige un recibo posterior de mutación, publicación DNS y resultado observado.

La gramática de un estado operativo

DCHK no reduce un dominio a libre u ocupado. Su resultado puede incluir publicación activa o inactiva, disputa, reserva, cumplimiento de política, periodos de gracia y operaciones sobre el objeto. Para crear, borrar, renovar, restaurar, transferir y actualizar, el atributo disposition añade dos palabras decisivas: pending y prohibited.

Un panel que conserva «transfer» y elimina «pending» no resume; invierte el significado. El sistema puede haber reconocido una operación sin haberla completado. Puede estar esperando revisión humana, acción de un tercero o una transición posterior. RFC 5731 explica esta separación en EPP: una transformación procesada puede quedar pendiente, y el cierre llega con un cambio de estado y una notificación. La comparación no convierte DCHK en EPP. Solo recuerda que el nombre de una acción no es su comprobante final.

El mismo problema aparece con active. RFC 5144 lo define como disponible mediante DNS, ya sea por delegación o publicación directa. inactive es lo contrario en ese plano. No son sinónimos de registrable o no registrable. reserved existe precisamente para expresar que un nombre no se ofrece por el procedimiento normal.

El ciclo de vida no cabe en una luz verde

Los periodos de gracia provienen del modelo de EPP. RFC 3915 describe cómo una eliminación puede abrir una fase de redención, pasar a restauración pendiente o continuar hacia supresión definitiva. Solo después de la purga aparece la posibilidad de nuevo registro. En cualquier instante intermedio, una consulta puede ser correcta y, sin embargo, no predecir el estado de mañana.

La disputa añade otra dimensión. La publicación técnica puede coexistir con una controversia sobre asignación. La política puede considerar un nombre conforme o no conforme según un subestado definido por una autoridad concreta. Un producto que elige un solo estado «principal» pierde las relaciones necesarias para decidir.

El diseño correcto conserva el conjunto completo y pregunta qué operación se está evaluando. La evidencia necesaria para renovar no es idéntica a la necesaria para transferir. El hecho de que una restauración sea posible no significa que cualquier solicitante esté autorizado a pedirla.

Quién habla importa tanto como lo que dice

Cada estado puede identificar a su actor: registro, registrador o proveedor de servicios de registro. Puede tener alcance, fecha de aplicación, tickets, descripciones en lenguaje natural y un subestado cuyo origen normativo debe declararse. Estas piezas permiten reconstruir responsabilidad.

Sin actor, una prohibición del registrador parece prohibición del registro. Sin alcance, una regla local parece global. Sin autoridad del subestado, dos cadenas iguales pueden expresar políticas incompatibles. Sin ticket, el equipo pierde el puente hacia la decisión operativa que produjo el estado.

La fecha lastDatabaseUpdateDateTime es igualmente concreta: fecha la última actualización de la base que alimentó la respuesta. No fecha el renderizado de la página. Una API puede responder en veinte milisegundos con datos que llevan horas sin cambiar. Disponibilidad del servicio y actualidad del conocimiento son métricas distintas.

La siguiente dirección no es una aprobación

registrationReference puede señalar el servicio situado aguas abajo. IRIS también permite referencias de entidad y continuaciones de búsqueda entre instancias. El cliente debe evitar seguir repetidamente una referencia para no caer en un bucle.

Seguirla con éxito solo demuestra navegación. El nuevo servicio puede aplicar otra política, exigir autenticación o disponer de una fuente más reciente. La primera autoridad no puede conceder por referencia los derechos que pertenecen a la segunda.

La capa XML de IRIS tampoco añade autenticación o privacidad por sí sola; delega esas propiedades en el transporte. RFC 5144 exige IRIS-LWZ y deja XPC y BEEP como opciones. Una conexión autenticada protege el intercambio bajo su modelo, pero no prueba que el solicitante pueda disponer del nombre ni que el servidor haya realizado una mutación.

Estándar, registro y código en ejecución

RFC 5144 sigue figurando como Proposed Standard. IANA mantiene dchk1, DCHK1 y el perfil BEEP. El único erratum verificado corrige una errata ortográfica en “Straightforward-NAPTR”. Todo ello documenta el protocolo; nada cuantifica implantación, uso o exactitud actual.

El rastro de internacionalización exige otra cautela. El texto remite a Nameprep, RFC 3491, que hoy está obsoleto. RFC 5891 define IDNA2008. No hay base para afirmar que RFC 5144 quedó formalmente sustituido, pero tampoco para ejecutar su referencia antigua sin revisar la política contemporánea del registro.

RFC 9083 muestra un modelo posterior de respuestas registrales en JSON. Se incluye como contraste de evolución, no como prueba de reemplazo. La disciplina consiste en declarar lo que la fuente demuestra y detenerse antes de inventar la genealogía operacional.

De consulta a resultado: siete recibos

El primer recibo identifica consulta normalizada, autoridad y respuesta DCHK. El segundo conserva la edad de la base fuente. El tercero guarda estado, actor, alcance, disposición, tickets y autoridad del subestado. El cuarto documenta la referencia y el servicio alcanzado. El quinto registra identidad, elegibilidad, política y precio. El sexto demuestra aceptación y posterior mutación comprometida. El séptimo observa delegación DNS y servicio útil.

No todas las decisiones necesitan llegar al séptimo paso, pero ninguna debe fingir que ya llegó. La arquitectura más segura no hace omnisciente a DCHK; hace explícita la pregunta siguiente.

Fuentes

  1. RFC 5144, HTML
  2. RFC 5144, texto
  3. Ficha de RFC Editor
  4. Ficha de IETF Datatracker
  5. Historial del documento
  6. Búsqueda de erratas
  7. RFC con errata verificada
  8. Registro XML de IANA
  9. Parámetros S-NAPTR de IANA
  10. Parámetros BEEP de IANA
  11. RFC 3981: núcleo IRIS
  12. RFC 3982: registro de dominios IRIS
  13. RFC 3983: IRIS sobre BEEP
  14. RFC 4992: canalización XML para IRIS
  15. RFC 4993: transporte UDP ligero para IRIS
  16. RFC 3915: periodos de gracia EPP
  17. RFC 5731: mapeo EPP de dominios
  18. RFC 3491: Nameprep
  19. RFC 5891: protocolo IDNA2008
  20. RFC 9083: respuestas JSON de RDAP
  21. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  22. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  23. Running-Code Primacy