A DMARC La solicitud de cambio debe permitir que otra persona determine exactamente qué cambiará, qué servicios podrían verse afectados y cómo se demostrará el éxito. Una captura de pantalla que muestre la política deseada no es suficiente. Preservar la línea base y el RRset propuesto, luego conectarlos con los flujos de negocios aprobados y una decisión de recuperación.
Capture la línea de base con precisión
Registre la cuenta del proveedor DNS o el inquilino, la zona, el nombre del propietario, el tipo de registro, el valor completo y el TTL. Incluya la hora y la fuente de la observación. Capture el descubrimiento de políticas DMARC actuales para los dominios de autor afectados, además de los remitentes aprobados y cualquier excepción no resuelta. Conserve los identificadores de autenticación en lugar de reducir una prueba a un color del tablero.
DMARC puede pasar a través de un exitoso alineado SPF o DKIM resultado. Por lo tanto, el dominio visible de un mensaje y sus identificadores autenticados son más importantes que una declaración genérica que pasa SPF . RFC 9989. Para publicación de dominios p=reject, RFC 9989 las secciones 7.4 y 8 requieren por separado firmas DKIM válidas y prohíben confiar únicamente en SPF ; el éxito a nivel de mensaje no renuncia a ese deber de implementación. Un pase de autenticación no certifica la solicitud comercial ni garantiza la ubicación en la bandeja de entrada.
Describe la diferencia deseada
Indique los RRsets exactos antes y después y los nombres afectados. Explique por qué se necesita el cambio ahora, qué servicios se probaron y qué evidencia sigue incompleta. Mantenga las ediciones DNS no relacionadas fuera de la solicitud para que un aprobador no apruebe accidentalmente una operación más amplia. Identifique al implementador técnico, el aprobador comercial y el contacto de escalamiento.
Si los destinos de los informes o los servicios delegados cambian, evalúe el flujo de información y la dependencia por separado. Preservar la configuración de recepción de informes necesaria para el seguimiento previsto. Informes agregados son observaciones del receptor con limitaciones de cobertura, por lo que no pueden ser la única señal de aceptación para un flujo legítimo en el que el tiempo es crítico. RFC 9990.
Escribir criterios de aceptación observables.
Utilice criterios que puedan fallar: el RRset autorizado es igual al valor aprobado; los mensajes críticos representativos utilizan las identidades previstas y se autentican como se espera; el destinatario del negocio confirma el resultado esperado; y la recepción de informes continúa. Registre los tiempos de observación y distinga las pruebas disponibles inmediatamente de la revisión de informes posteriores. Un informe que aún no ha llegado no es una prueba aprobada.
Defina los desencadenantes de la recuperación antes de la implementación. Si un flujo crítico falla y el diagnóstico lo vincula con el cambio aprobado, invoque el plan de recuperación aprobado. Preservar el antiguo Estado y explicar sus limitaciones. La restauración de una política no revierte instantáneamente DNS almacenado en caché ni recupera mensajes ya rechazados. Planifique la observación más allá de la ventana de mantenimiento nominal.
Pruebe si una solicitud realmente puede cerrarse
Supongamos que una solicitud hipotética cambia solo la política de una nómina De dominio de p=none a p=quarantine manteniendo su destino de informes y TTL. La revisión aún debe vincular la línea base completa y el RRset propuesto, la cuenta y el dominio objetivo, el alcance de la nómina aprobada y el plan de recuperación. Aquí no se proporciona ninguna carga útil real, aprobación o cambio DNS .
Supongamos que una observación posterior al cambio autorizada coincide con el estado DNS aprobado y un mensaje de nómina representativo se autentica como se esperaba, pero el destinatario comercial no ha confirmado la recepción y el siguiente informe agregado aún no está disponible. Registre las comprobaciones de configuración y autenticación por separado de los resultados pendientes. Asignar el seguimiento de los recibos al propietario de la nómina y la revisión de la admisión retrasada al propietario de los informes; no cierre todos los criterios de aceptación basándose en un registro coincidente. Se trata de hallazgos hipotéticos, no de controles ejecutados.
El flujo de trabajo de cambios anterior es una recomendación operativa, no un requisito de protocolo. Los controles CM-3 y CM-5 NIST SP 800-53 Rev. 5 proporcionan una base general para revisar, aprobar y restringir cambios; el enlace de carga útil exacto, los roles y los campos de transferencia aquí son la implementación propuesta. Catálogo de controles NIST.