Borrar una zona DNS desde un pipeline: por qué un dashboard vacío no es prueba
La propuesta que circula entre operadores encadena cuarentena, evidencia de entregabilidad y una aprobación ligada a un identificador de zona inmutable para que el borrado automático deje de ser irreversible.
Provisionar un subdominio para cada inquilino es barato y se repite sin coste. Borrarlo no. Un pipeline puede llevarse por delante el espacio de nombres DNS del que dependen el enrutado, la verificación y la autenticación de correo de un cliente mientras su plano de control sigue informando de que todo va bien. La propuesta que se está discutiendo entre operadores es poner una puerta de evidencias delante de cada desmontaje de zona: cuarentena primero, recogida de evidencia de entregabilidad después y, solo al final, un commit autorizado por separado y atado a un plan de borrado con caducidad.
El punto de partida normativo es el RFC 7489, que define los informes agregados de DMARC, el registro de política bajo la etiqueta _dmarc y la alineación entre el dominio visible en el From y los identificadores autenticados. Esos informes son evidencia de que un espacio de nombres se ha usado para correo y de que los receptores lo han evaluado. Lo que no hacen es convertir la ausencia de observaciones en prueba de que nadie lo usa.
El silencio es ambiguo
No ver tráfico puede significar muchas cosas: que el intervalo de reporte aún no ha cerrado, que el receptor no manda informes, que el tráfico es raro o que la telemetría está rota. Una ventana larga y silenciosa solo responde a la pregunta "¿qué ha observado este recolector?", no a "¿se puede borrar este nombre?". La regla que se propone es directa: la evidencia positiva veta, y la evidencia ausente se trata como desconocida salvo que una señal de ciclo de vida independiente cierre el hueco.
El ejemplo es el de un inquilino llamado acme cuyo nombre legible sigue resolviendo a una zona mientras un plan de baja anterior apunta a otro identificador. El inquilino se reactivó tras la cuarentena, el aprovisionamiento creó un espacio de nombres de reemplazo y la aprobación vieja seguía en la cola. Un worker que busca por "acme" y borra lo que coincida puede destruir el reemplazo aunque cada llamada a la API devuelva éxito.
Un plan de borrado, no un botón
La alternativa es una máquina de estados con al menos tres fases: activo, en cuarentena y borrado aprobado. La cuarentena corta la configuración nueva del inquilino pero conserva la zona. Durante ese intervalo el pipeline guarda la decisión de ciclo de vida, el identificador de zona inmutable del proveedor, el nombre DNS esperado, la evidencia de correo, la salud del recolector y una aprobación emitida para el mismo digest del plan. El worker final recibe ese digest, no un dominio en texto libre, y vuelve a leer el objetivo justo antes del commit: si el nombre o el identificador cambiaron tras la aprobación, el plan caduca en lugar de intentar adivinar la intención.
El código que acompaña la propuesta es un paquete Go con una estructura Plan (inquilino, zona, nombre, cuarentena, ventana observada, número de observaciones, salud del recolector, cierre de ciclo de vida, digest y caducidad de la aprobación) y un Authorize que devuelve un permiso ligado a un único objetivo. Los umbrales de tiempo son política de operación, no constantes escondidas en el cliente de borrado; el RFC no prescribe ningún retardo seguro.
Lo relevante para quien mantiene esto es que un dashboard no sustituye a los datos: una línea suave comprime salud de recolección, cobertura de informes y actividad del inquilino en una sola imagen, y la decisión necesita los timestamps y las identidades de debajo. Un inquilino con poco tráfico merece el mismo rechazo que uno con mucho, porque la evidencia débil se vuelve más peligrosa según se apaga el tráfico.
