DNS, correo electrónico y webhooks

Estas integraciones entregan los cambios y eventos de Opfield a sistemas externos: proveedores de DNS, servidores de correo y receptores de webhooks. Da a cada una credenciales con el mínimo privilegio y confirma la entrega en el lado del destinatario: que Opfield acepte un cambio no demuestra que los resolutores, los buzones o los consumidores de webhooks lo hayan recibido.

Para configurar un conector DNS, sigue la guía de Cloudflare. El correo electrónico y los webhooks de notificación o de despliegue son superficies de integración separadas, no cuentas de hosting.

La configuración de correo admite flujos de autenticación y entrega de notificaciones cuando están activados. Prueba la identidad del remitente, TLS, la entregabilidad y los límites de envío antes de depender de los códigos de un solo uso por correo.

Los webhooks pueden desencadenar flujos de despliegue o de automatización compatibles. Usa secretos generados, verifica las firmas, haz que los receptores sean idempotentes y distingue una operación aceptada de un despliegue completado. No devuelvas errores internos del daemon ni credenciales en las respuestas de los webhooks.

Conectores DNS

Usa un token de Cloudflare dedicado y restringido a la cuenta, las zonas y los permisos DNS previstos. Verifica las zonas visibles para ese token antes de activar los registros gestionados o los desafíos DNS-01. Opfield solo debe ser responsable de los registros asociados explícitamente a dominios gestionados; los registros no relacionados siguen siendo estado externo.

En una migración, registra los valores y el TTL actuales, confirma la dirección del Ingress de destino, aplica el cambio y verifica la resolución desde resolutores públicos independientes. No elimines el endpoint antiguo hasta que el tráfico de los clientes llegue a la nueva ubicación.

Correo electrónico

Configura la identidad del remitente, el host SMTP, el puerto, el modo TLS y la autenticación según el proveedor en Settings > Advanced > SMTP configuration. Envía un mensaje de prueba y comprueba la bandeja de entrada real, la clasificación como spam, la alineación SPF/DKIM/DMARC y los límites de envío del proveedor.

Si los códigos de un solo uso por correo están activados, mantén otra vía de recuperación para los administradores. Una conexión SMTP correcta no demuestra que los usuarios puedan recibir los mensajes de autenticación.

Webhooks de notificación

1. Crea un receptor HTTPS con tamaño de petición y tiempo de espera limitados.
2. Configura la autenticación o la firma HMAC.
3. Envía un evento de prueba y verifica la firma con el cuerpo en bruto de la petición.
4. Devuelve una respuesta de éxito determinista solo después de que el receptor haya aceptado el evento de forma duradera.
5. Haz que los reintentos sean idempotentes usando el identificador del evento o de la entrega.
6. Supervisa el historial de entregas, la latencia, los reintentos y los fallos definitivos.

Webhooks de despliegue

Trata la entrega de un webhook como una petición para evaluar un evento de origen, no como prueba de un despliegue. Verifica de forma independiente la firma del proveedor, la lista de repositorios permitidos, la política de ramas o tags, el commit resuelto, la admisión del build y el Task final de despliegue.

Rota los secretos de conectores y webhooks instalando el sustituto, verificándolo y revocando después el valor antiguo. No expongas respuestas completas del receptor, credenciales del proveedor ni errores internos del daemon a llamantes no fiables.

Modos de fallo y recuperación

Los fallos de DNS suelen deberse a una cuenta o zona incorrecta, a permisos insuficientes del token, a cachés de resolutores desactualizadas, a un modo de proxy/CDN inesperado o a un registro de desafío que no se puede observar públicamente. Compara el registro en Opfield con la respuesta del servidor de nombres autoritativo y de al menos un resolutor independiente. Durante una migración, restaura el valor anterior registrado si el nuevo endpoint no se puede verificar antes del plazo de reversión acordado.

La entrega de correo tiene varias etapas independientes: Opfield aceptó el mensaje, el proveedor SMTP lo aceptó, el sistema receptor lo aceptó y el usuario puede encontrarlo. Comprueba cada etapa antes de cambiar la política de autenticación. Si la entrega de códigos de un solo uso está degradada, mantén disponible la vía alternativa de administrador ya probada y evita pedir códigos repetidamente, lo que activaría la limitación del proveedor.

Los fallos de webhooks requieren el registro de la entrega, el número de intentos, la clase de respuesta y el ID de correlación del lado del receptor. Una respuesta 2xx debería significar que el receptor ha aceptado el evento de forma duradera; el procesamiento puede continuar de forma asíncrona. Para los fallos reintentables, haz que el receptor elimine duplicados por ID de entrega o de evento. Para los fallos de autenticación definitivos, rota el secreto compartido o la clave de firma y verifica ambos lados antes de reenviar un número acotado de entregas fallidas.

Límites de seguridad

Usa endpoints HTTPS sin credenciales en la URL. Restringe los destinos salientes a los hosts públicos esperados o a CIDR privados aprobados explícitamente. Los receptores deben validar las marcas de tiempo o las ventanas de repetición cuando la integración lo admita, comparar las firmas en tiempo constante, limitar el tamaño de las peticiones y evitar reflejar el cuerpo de la petición en las respuestas de error.

Los tokens de los proveedores de DNS y de correo son credenciales administrativas aunque Opfield los cifre en reposo. Mantén activada la auditoría en el lado del proveedor, revisa su alcance con regularidad y revoca el token antiguo solo cuando el sustituto haya completado una operación de prueba real.

Para la autenticación o las notificaciones críticas para el negocio, documenta una vía alternativa de comunicación y de recuperación para los administradores. El éxito y la latencia de los proveedores externos están fuera del límite de disponibilidad de Opfield, así que no hagas que un único proveedor sin probar sea la única forma de acceder a la instalación u operarla.