Resumen

  • La revisión 03 de draft-brown-epp-deleg, publicada el 29 de septiembre, incorpora <deleg:rem><deleg:all/></deleg:rem> para solicitar la eliminación de todos los DELEG de un dominio. La revisión anterior exigía indicar los registros que se retiraban.
  • Es un Internet-Draft individual, sin aprobación como RFC ni constancia de que un registro lo haya desplegado. «Todos» se refiere al conjunto DELEG de ese dominio, no a la inscripción del dominio o sus registros NS habituales.

La lista de objetos a retirar suele formar parte de la propia explicación de un cambio. Si una orden cita dos registros, un revisor puede cotejar la solicitud con esos dos destinos. Si dice «todos», el alcance definitivo depende de lo que el servidor encuentre cuando procese la orden. Esa diferencia, fácil de perder entre etiquetas XML, es el hecho nuevo que ofrece la tercera revisión del borrador EPP DELEG.

En la sección 5.2.2, el elemento de retirada admite ahora dos caminos: una enumeración de registros deleg:deleg o el elemento vacío <deleg:all/>. El documento incluye un ejemplo de actualización que quita todos los DELEG sin añadir otros. La versión 02 no ofrecía ese atajo. No hay aquí una noticia de borrados efectivos, sino una propuesta de capacidad administrativa cuya adopción futura exigiría delimitar los permisos del cliente.

El límite del objeto importa. El borrador coloca la operación dentro de la extensión DELEG de una actualización de dominio. No da de baja el dominio, no borra objetos de host ni equivale a retirar toda la delegación DNS. Su sección 6 contempla DELEG junto a los NS tradicionales. Y ni siquiera una confirmación de EPP demostraría por sí sola qué han publicado ya los servidores autoritativos o qué siguen viendo los resolutores por sus cachés. La orden de aprovisionamiento y la observación de DNS no son la misma prueba.

La revisión trae también una remodelación de datos. Los atributos de deleg:params se convierten en elementos deleg:param; el espacio de nombres propuesto pasa de deleg-0.01 a deleg-0.02; desaparecen del esquema anterior los campos priority y target. Un artículo anterior de BTW examinó precisamente la discordancia de esos campos entre el borrador EPP de entonces y otro de RDAP. La retirada de ambos campos reduce esa discordancia textual. No demuestra una ruta completa y operativa desde EPP hasta DNS y RDAP. Esta pieza examina otra cosa: el poder de vaciar el conjunto en una sola transacción.

La sección de seguridad propone rechazar nombres de parámetros desconocidos o valores inválidos y actualizar periódicamente las listas de claves registradas. Una validación correcta de parámetros, sin embargo, no equivale a una autorización para el alcance total de una orden. Además, el texto principal de DELEG, en su revisión 11, todavía solicita crear el registro de información de delegación en IANA. La solicitud y las referencias entre borradores no prueban que el registro ya esté operativo.

El Datatracker presenta la extensión EPP como Internet-Draft individual activo, sin flujo RFC ni director de área asignado y en estado IESG «I-D Exists». El anuncio público certifica la aparición de la revisión, no consenso del IETF, disponibilidad comercial, despliegue ni incidente. Su consecuencia de gobernanza es prospectiva: quien pueda mantener registros particulares no debería recibir por inercia el permiso de borrar el conjunto completo.

Fuentes