Summary

  • La revisión del 27 de octubre de dns-account-01 está en la última consulta del IESG hasta el 10 de noviembre. Asigna a cada cuenta ACME un nombre DNS propio para delegar la validación del mismo dominio mediante CNAME distintos.
  • El nombre sale de los primeros diez bytes del SHA-256 de la URL de la cuenta, codificados en Base32. Rotar la clave mantiene el nombre; cambiar la URL durante una migración del servidor puede invalidar los registros preparados.

El cuello de botella tiene un nombre preciso: _acme-challenge delante del dominio. El dns-01 de RFC 8555 puede alojar varios valores TXT. El choque llega cuando dos sistemas quieren delegar ese mismo nombre mediante CNAME a resolutores diferentes. En un nombre DNS cabe un único destino CNAME. Un despliegue multinube termina compartiendo un mecanismo de validación que pretendía mantener separado.

El borrador del IETF añade una etiqueta vinculada a la cuenta antes de _acme-challenge. Toma la URL completa de la cuenta ACME, calcula SHA-256, conserva diez bytes y los expresa en Base32. El ejemplo publicado es _ujmmovf2vn55tgye._acme-challenge.example.org. Cada cuenta puede tener así su propio CNAME; el servidor sigue el alias hasta el TXT y comprueba el resumen de la autorización del desafío. La separación ocurre en DNS, donde estaba el conflicto.

La factura aparece en la sección 3.5. Para calcular la etiqueta cuentan el esquema, el host, el puerto y la ruta de la URL de la cuenta. Una nueva clave de la misma cuenta mantiene la etiqueta. Si el proveedor ACME cambia esa URL durante una migración, el DNS configurado de antemano deja de corresponder; el texto pide conservar identificadores anteriores cuando haya que mover el servicio. El expediente del IETF sitúa la revisión 04 en la última consulta, con cierre el 10 de noviembre y objetivo de norma propuesta.

Falta una lista de implementaciones y una prueba pública de cómo un servidor conservaría esas URL durante una migración real.