Antes de aprobar DKIM delegación, solicite el cambio DNS exacto y la identidad de firma que habilitará. "Agregar nuestros registros DNS " es una instrucción demasiado amplia para una revisión de seguridad. A selector CNAME, una delegación NS y el acceso a toda la cuenta DNS otorgan diferentes formas de control.
Dibuja el límite antes de aprobarlo.
Un CNAME en el nombre del propietario de un selector dirige la resolución a través de su objetivo. Un proveedor que controle ese objetivo puede cambiar los datos de verificación alcanzados a través del alias. Por sí solo, no otorga permiso para editar nombres arbitrarios en su zona. Una delegación NS establece un límite de zona y otorga a los servidores autorizados delegados la responsabilidad de los nombres debajo de él, sujeto a la jerarquía DNS . El acceso administrativo a toda la cuenta puede ser aún mucho más amplio. RFC 1034 §3.6.2 y RFC 1034 §4.2 describir estos mecanismos DNS .
Escriba el nombre del propietario y el subárbol afectado en la aprobación. una solicitud de service1._domainkey.example.com es diferente del control de todo el _domainkey.example.com subárbol. No reemplace un registro limitado respaldado por un proveedor con una delegación amplia solo porque parezca más sencillo de automatizar.
Distinguir el alcance DNS del impacto de la firma
La verificación DKIM obtiene una clave utilizando el selector de firma y el dominio de firma. El control sobre los datos de verificación de un selector utilizable, junto con la clave de firma privada correspondiente, puede permitir firmas válidas para ese dominio de firma. Por lo tanto, la aparente estrechez de un nombre DNS no significa que la consecuencia de confianza en el correo electrónico sea insignificante.
Un ejemplo sintético ilustra la distinción. Un proveedor recibe un CNAME en invoices._domainkey.example.com y opera el firmante coincidente para d=example.com. Su acceso DNS se limita al destino del alias, pero ese firmante puede producir firmas que afirmen ser responsables de example.com. Un selector llamado facturas no restringe las firmas a facturas, destinatarios particulares o una campaña aprobada. Los controles de aplicaciones y cuentas deben imponer esos límites.
Si utiliza un subdominio de envío dedicado, evalúe las condiciones aplicables DMARC alineación reglas también. La separación de subdominios no aísla automáticamente la alineación relajada. RFC 9989 §4.4 describe cómo se comparan los identificadores autenticados con el dominio del autor; la política y la determinación del dominio organizacional importan.
Recopilar evidencia que responda a la pregunta de aprobación.
Solicite las instrucciones actuales del proveedor, los nombres generados, el identificador de cuenta, el dominio de firma admitido y el modelo de rotación. Verifique quién puede cambiar esos valores dentro de la cuenta del proveedor y si la separación de roles está disponible. Pregunte por cierre de cuenta y manejo de DNS obsoletos, sin asumir garantías contractuales que no le hayan sido suministradas.
Cree un registro compacto: propietario DNS , tipo de registro, destino o servidores de nombres, propietario del servicio, previsto d= identidad, usuarios proveedores privilegiados, fecha de renovación y procedimiento de retiro. Para una delegación NS propuesta, inspeccione todo el subárbol afectado en busca de selectores existentes antes de aprobarlo. Para una solicitud de acceso a una cuenta, cuestione por qué las instrucciones por registro o una función admitida más limitada son insuficientes.
Incorporación de pruebas y terminación del plan
Después de un cambio aprobado, compare las observaciones DNS autoritativas y recursivas y envíelas a través del servicio previsto. Inspeccione el resultado y la alineación DKIM de un receptor confiable. La prueba debe demostrar la identidad otorgada, no simplemente mostrar que alguna firma pasa.
Al finalizar, detenga el acceso a la aplicación, elimine las credenciales de envío obsoletas y coordine el retiro del selector con las colas de entrega y el proceso del proveedor. Si se sospecha que el proveedor está comprometido, invoque la respuesta a incidentes en lugar de preservar automáticamente una superposición de rutina. Un servicio marcado como inactivo en los registros de adquisiciones aún puede representar una dependencia técnica activa.
Documente explícitamente el fideicomiso residual: qué puede firmar el proveedor, quién puede administrarlo y qué tan rápido la organización puede eliminar la dependencia. Ese registro hace que las renovaciones posteriores sean una revisión de la autoridad real en lugar de una repetición del ticket DNS original.
Compare tres solicitudes de aprobación hipotéticas
Utilice el alcance y la consecuencia juntos:
- Un selector CNAME : revise su propietario y destino exactos, la identidad deseada y los controles de cuenta del proveedor. No otorga acceso arbitrario de edición de zonas, pero su asignación de claves puede permitir firmar para esa identidad.
- Delegación NS debajo de _domainkey.example.com : haga un inventario de los selectores en esa zona delegada y quién controla sus servidores autorizados. Los selectores existentes o futuros pueden verse afectados, sujeto a nuevos recortes de zona.
- Acceso completo a la cuenta DNS : requiere una necesidad explícita e inspecciona los permisos reales de la cuenta. Puede llegar a registros web y de correo no relacionados; esto no equivale a publicar un alias de selector.
Estos son escenarios de revisión, no autorizaciones o cambios realizados en una zona real. Si se desconoce el alcance o la propiedad exactos, resuelva esa brecha antes de la aprobación.
Lectura relacionada
Publicación DKIM TXT y CNAME : sigue el modelo de gestión de claves del proveedor · Revocar una clave DKIM y distinguir la revocación de un registro DNS faltante.