Prácticas recomendadas de seguridad del DNS: una lista de comprobación completa para reforzar la seguridad

La infraestructura del Sistema de Nombres de Dominio (DNS) suele ser el componente más fiable de una red empresarial, pero sigue siendo uno de los menos supervisados. Cuando los administradores de sistemas configuran los registros de dominio, suelen pasar a ocuparse de los cortafuegos, la seguridad de los terminales o la gestión de identidades. Los atacantes saben que existe esta brecha y la aprovechan al máximo.

Si un atacante consigue controlar la resolución de tu nombre de dominio, puede redirigir el tráfico web de forma encubierta, interceptar correos electrónicos corporativos y generar certificados válidos de Seguridad de la Capa de Transporte (TLS) en tu nombre. Todo ello sin necesidad de acceder a ningún servidor de tu red interna.

La implementación de medidas de seguridad sólidas para el DNS no es opcional en una infraestructura moderna. Esta guía ofrece un conjunto completo de buenas prácticas de seguridad para el DNS que te ayudarán a evitar problemas y errores habituales.

¿Qué es la seguridad del DNS?

La seguridad del DNS es el conjunto de controles técnicos, protocolos criptográficos y políticas administrativas diseñados para proteger la integridad, la disponibilidad y la confidencialidad de los servicios de resolución de nombres de dominio.

En lugar de basarse en una única herramienta, una seguridad eficaz del DNS requiere controles defensivos en cuatro capas distintas:

1. El registrador y la capa de cuentas: esto incluye medidas de protección administrativas en tu registrador de dominios que impiden las transferencias no autorizadas de dominios y el robo de credenciales.
2. La capa de servidores de nombres autorizados: se trata de controles de infraestructura que garantizan que tus archivos de zona oficiales permanezcan disponibles, sin modificaciones y resistentes frente a los ataques de denegación de servicio distribuido (DDoS).
3. La capa de resolución y transporte: esta capa incluye protocolos que protegen las consultas DNS durante su tránsito entre los clientes de los usuarios finales, los resolutores recursivos y los servidores autoritativos.
4. La capa de registros de recursos e identidad: registros criptográficos publicados en el archivo de zona, como las extensiones de seguridad del Sistema de Nombres de Dominio (DNS) y los registros de autenticación de correo electrónico, que validan la autenticidad de los datos de tu dominio.

Por qué el DNS es un objetivo: la superficie de ataque

Dado que el DNS funciona como una infraestructura de fondo fiable, las configuraciones heredadas permiten a los autores de amenazas llevar a cabo diversos ataques.

Secuestro de DNS y compromiso de registradores

En un ataque de secuestro de dominio, un atacante consigue acceder a tu cuenta del registrador de dominios o se aprovecha de los procedimientos deficientes del registrador para modificar las delegaciones de tus servidores de nombres. Una vez que el atacante cambia tus registros NS para que apunten a sus servidores maliciosos, pasa a controlar todo el tráfico entrante de tu dominio.

Las campañas recientes se han centrado en los registradores de dominios mediante el «credential stuffing» y la ingeniería social dirigida. Cuando los atacantes logran llevar a cabo un secuestro de DNS, pueden emitir al instante certificados válidos para tu dominio raíz utilizando protocolos automatizados de validación de la autoridad de certificación (CA).

Suplantación de DNS y envenenamiento de caché

Las consultas DNS tradicionales se transmiten a través del protocolo UDP sin cifrar en el puerto 53. Dado que las consultas estándar carecen de autenticación de transacciones integrada, un atacante situado en la ruta de la red puede falsificar paquetes de respuesta y enviarlos de vuelta a un resolutor recursivo antes de que el servidor autoritativo legítimo responda.

Esta técnica, conocida como «spoofing de DNS», obliga a los servidores recursivos a aceptar direcciones IP falsas para los nombres de host seleccionados. Cuando un resolutor almacena estas respuestas falsificadas en su memoria local, se produce un «envenenamiento de la caché de DNS ». Todos los usuarios que utilicen ese resolutor son redirigidos a sitios maliciosos hasta que caduque la entrada almacenada en la caché. Comprender estos vectores es muy importante a la hora de analizar los tipos más comunes de ataques de DNS.

Amplificación de DNS y DDoS

Los servidores de nombres de autoridad son objetivos prioritarios para los ataques DDoS basados en el volumen. Los atacantes suelen aprovechar los resolutores recursivos abiertos para lanzar un ataque de amplificación de DNS.

Al enviar pequeñas solicitudes falsificadas (como consultas ANY o TXT ) con la dirección IP de origen falsificada de la víctima a los resolutores vulnerables, estos devuelven respuestas con una gran cantidad de datos a la víctima. Esta avalancha de tráfico satura el ancho de banda de la red y provoca interrupciones generalizadas del servicio.

Registros pendientes y apropiación de subdominios

A medida que las organizaciones migran servicios entre distintos proveedores de nube, los ingenieros de sistemas suelen eliminar recursos en la nube —como buckets de Amazon S3, GitHub Pages o Azure App Services— sin borrar los registros CNAME correspondientes de su zona DNS.
Este descuido da lugar a un registro DNS «colgante ». Un atacante externo puede apropiarse del bucket o de la instancia de aplicación abandonados en la plataforma del proveedor de la nube, obteniendo al instante el control de tu subdominio. La apropiación de subdominios permite a los atacantes alojar formularios de phishing, ejecutar scripts entre sitios (XSS) y robar cookies de sesión.

Suplantación de identidad en el correo electrónico a través de registros DNS poco seguros

El envío de correos electrónicos depende en gran medida del DNS. Si tu organización no publica registros de autenticación correctamente configurados, los ciberdelincuentes pueden enviar correos electrónicos salientes falsificados para que parezca que proceden de tu dominio. Esto expone a tus socios comerciales, clientes y empleados a campañas directas de phishing.

Prácticas recomendadas de seguridad del DNS: la lista de comprobación para el refuerzo de la seguridad

Utiliza esta lista de comprobación paso a paso para reforzar de forma sistemática la infraestructura de tu dominio frente a la interceptación y el uso indebido.

1. Bloquea tu dominio a través del registrador

Las solicitudes de transferencia no autenticadas constituyen una de las principales vulnerabilidades para los activos críticos de los dominios. Aplica los códigos de estado «clientTransferProhibited» y «clientUpdateProhibited» a tus dominios.

En el caso de los dominios corporativos de gran valor, solicita un «Registry Lock» a tu registrador. El «Registry Lock» requiere una verificación fuera de línea, como una confirmación telefónica con el personal designado, antes de que se pueda realizar cualquier cambio en las delegaciones de los servidores de nombres o en los contactos administrativos del WHOIS.

2. Implemente la autenticación multifactorial (MFA) y el acceso basado en roles en su registrador

Asegúrate de que las cuentas administrativas de tu registrador de dominios y de tu proveedor de alojamiento DNS no dependan únicamente de contraseñas. Implemente la autenticación multifactorial (MFA) basada en hardware mediante llaves de seguridad FIDO2 / WebAuthn.

No guardes las credenciales de inicio de sesión del registrador en los buzones compartidos del equipo. Implementa un control de acceso basado en roles (RBAC) estricto, de modo que el personal de TI general tenga acceso de solo lectura, reservando los permisos de gestión del dominio para los administradores de dominio designados.

3. Restricción de transferencias de zona (AXFR)

Los servidores DNS de referencia utilizan transferencias de zona completas (AXFR) para replicar los datos del DNS entre los servidores primarios y secundarios. Si tu servidor de nombres permite solicitudes AXFR sin restricciones desde cualquier dirección IP, los atacantes pueden descargar todo tu archivo de zona. Esto deja al descubierto las estructuras internas de nombres de host, los servidores de prueba y la infraestructura de red oculta.

Configura tus servidores de nombres principales para que solo permitan transferencias AXFR a las direcciones IP específicas de tus servidores de nombres secundarios autorizados. Puedes comprobar tu configuración desde la línea de comandos de un terminal:

Ninguno
dig AXFR tudominio.com @ns1.tudominio.com

dig AXFR tudominio.com @ns1.tudominio.com

Si el servidor devuelve la lista completa de registros DNS en lugar de un error de «Transferencia fallida» o «RECHAZADA», la configuración de transferencia de tu zona está abierta y es necesario restringirla de inmediato.

4. Implementar servidores de nombres autoritativos redundantes en redes diferentes

Depender de un único proveedor de DNS o de un único centro de datos físico supone un punto único de fallo. Si tu proveedor sufre un ataque DDoS o una interrupción de la red, toda tu presencia en línea queda inactiva.

Implementa al menos dos servidores de nombres autoritativos alojados en números de sistema autónomo (ASN) distintos y en redes geográficamente dispersas. El uso de un modelo de DNS autoritativo con dos proveedores garantiza que, si uno de ellos sufre un fallo en su infraestructura, el proveedor secundario seguirá resolviendo las consultas sin interrupciones.

5. Implementar DNSSEC con criptografía moderna

DNSSEC añade firmas digitales a tus registros DNS. Cuando un resolutor recursivo consulta una zona habilitada para DNSSEC, valida las firmas criptográficas (registros RRSIG) comparándolas con una cadena de confianza que se remonta hasta la zona raíz. Esto ayuda a garantizar que la respuesta no se haya modificado durante la transmisión.

A la hora de implementar DNSSEC, sigue las directrices actualizadas de la norma NIST SP 800-81r3:

• Utiliza criptografía moderna basada en curvas elípticas, como la curva ECDSA P-256 o Ed25519, en lugar de claves RSA obsoletas. Las claves de menor tamaño reducen el riesgo de fragmentación de paquetes a través de UDP.
• Mantenga los plazos de validez de las firmas entre 5 y 7 días para limitar el periodo de exposición de una clave comprometida.
• Programa las renovaciones de las claves de firma de zona (ZSK) cada 1 a 3 años y almacena las claves de firma de claves (KSK) en configuraciones de hardware seguras siempre que sea posible.

Puedes comprobar si la cadena criptográfica de tu dominio está intacta sometiendo tu dominio a una herramienta de verificación de DNSSEC específica.

6. Publicar un registro de autorización de autoridad de certificación (CAA)

Un registro CAA es un registro de tipo TXT del DNS que especifica explícitamente qué autoridades de certificación están autorizadas a emitir certificados TLS públicos para tu nombre de dominio.

Si un atacante intenta solicitar un certificado no autorizado para tu dominio a una autoridad de certificación (CA) automatizada, esta debe comprobar tu registro CAA público antes de la emisión. Si la CA no figura en la lista, se bloquea la emisión.

Para limitar la emisión de certificados a determinados proveedores, añade un registro CAA a tu dominio raíz:

Ninguno
yourdomain.com. IN CAA 0 issue «letsencrypt.org»
yourdomain.com. IN CAA 0 issue «digicert.com»
yourdomain.com. IN CAA 0 iodef «mailto:[email protected]»

El parámetro «iodef» indica a las autoridades de certificación (CA) compatibles que envíen correos electrónicos de notificación en tiempo real a su equipo de seguridad si alguien intenta solicitar un certificado no autorizado.

7. Auditoría de registros sueltos y huérfanos

Revisa periódicamente tu inventario de registros publicados para detectar nombres de host obsoletos. Presta especial atención a los registros CNAME que apuntan a servidores en la nube de terceros, a los subdominios asociados a proveedores de correo electrónico fuera de servicio y a los registros A caducados que apuntan a direcciones IP retiradas.
Antes de realizar cambios estructurales, comprueba tus registros publicados utilizando una herramienta fiable de búsqueda de registros DNS. Revisar los distintos tipos de registros DNS en todos los subdominios activos ayuda a evitar la exposición accidental a ataques de apropiación de subdominios.

8. Establecer valores de TTL razonables y realizar un seguimiento de los plazos de propagación

Los parámetros de «Time-To-Live» (TTL) determinan durante cuánto tiempo los resolutores recursivos almacenan en caché un registro DNS antes de solicitar una copia actualizada a tu servidor de nombres autoritativo.

• Operaciones estándar: Establece los valores predeterminados de TTL entre 3.600 segundos (1 hora) y 86.400 segundos (24 horas). Esto permite equilibrar la carga del servidor y la latencia de las consultas.
• Antes de la migración o en caso de respuesta ante incidentes: reduce los valores de TTL a 300 segundos (5 minutos) al menos entre 24 y 48 horas antes de los cambios previstos en la infraestructura.

Reducir los TTL con antelación garantiza una rápida caducidad de la caché en todos los resolutores globales si necesitas desviar el tráfico de un servidor afectado. Puedes supervisar cómo se propagan los cambios por los resolutores globales utilizando una herramienta de comprobación de la propagación del DNS en tiempo real.

9. Cifrado del transporte entre el cliente y el resolutor (DoH / DoT / DoQ)

Las consultas DNS estándar en texto claro a través del puerto UDP 53 exponen los hábitos de navegación de los clientes a los intrusos locales, a los operadores de redes Wi-Fi no autorizados y a los proveedores de servicios de Internet (ISP) de tránsito. El cifrado de la ruta de la consulta protege la privacidad del usuario final y evita la manipulación de la red local.

Las redes empresariales modernas admiten tres estándares principales de transporte cifrado:

• DNS sobre TLS (DoT): funciona a través del puerto TCP dedicado 853. El DoT se utiliza ampliamente para proteger el transporte entre terminales internos, resolutores recursivos locales y servidores de nivel superior.
• DNS sobre HTTPS (DoH): encapsula las consultas DNS dentro del tráfico HTTPS en el puerto 443, lo que hace que el tráfico de consultas sea indistinguible del tráfico web habitual.
• DNS sobre QUIC (DoQ): utiliza el protocolo de transporte QUIC para reducir la latencia y mejorar el rendimiento en conexiones de red inestables.

Al implementar un DNS cifrado en entornos empresariales, configura los dispositivos cliente locales mediante herramientas de gestión de dispositivos móviles (MDM) para que utilicen los servidores de resolución cifrados internos que hayas designado. Bloquea en el cortafuegos de tu red el tráfico DoT saliente no autorizado (puerto 853) y los puntos de conexión DoH públicos, con el fin de evitar que las aplicaciones eludan el registro de seguridad local.

10. Reforzar la seguridad del software de resolución local y de los servidores de nombres

Si tu organización cuenta con resolutores recursivos autohospedados o con instancias internas de BIND, Unbound o PowerDNS, sigue unas prácticas estrictas de refuerzo de la seguridad de los servidores:

• Limitar la resolución recursiva a los rangos de direcciones IP internas autorizadas. Los servidores de resolución abiertos en la red pública de Internet se utilizan con frecuencia en ataques DDoS de amplificación.
• Aplicar la minimización de QNAME y configurar los resolutores para que envíen únicamente las etiquetas de dominio mínimas necesarias a los servidores autoritativos de nivel superior (RFC 7816). De este modo se evita que los servidores raíz autoritativos vean los nombres de host de destino completos.
• Coloca los servidores primarios de referencia detrás de direcciones IP ocultas que no figuren en los conjuntos de registros NS públicos. Los servidores secundarios públicos obtienen las actualizaciones de la zona del servidor primario oculto.

11. Implementar las zonas de política de respuesta (RPZ)

Las zonas de políticas de respuesta, a menudo denominadas «cortafuegos DNS», permiten a los administradores de resolutores recursivos superponer fuentes de información sobre amenazas personalizadas a la resolución de nombres estándar.

Cuando un dispositivo cliente intenta resolver un dominio que se sabe que aloja malware, servidores de comando y control (C2) o páginas de phishing, las reglas RPZ interrumpen la consulta. El resolutor devuelve una respuesta NXDOMAIN o redirige al usuario a una página de bloqueo interna.

12. Aplicar los protocolos de autenticación de correo electrónico: SPF, DKIM y DMARC

Los protocolos de autenticación del correo electrónico son registros DNS. Si no se aplican SPF, DKIM y DMARC, un atacante puede suplantar la identidad de tu dominio en correos electrónicos de phishing, incluso aunque tu registrador y tus servidores de nombres estén totalmente protegidos.

Supervisión del DNS: la práctica que la mayoría de los equipos pasan por alto

Los equipos de seguridad suelen descubrir la manipulación del DNS solo después de que el servicio de atención al cliente informe de interrupciones en el sitio web o de fallos en el flujo de correo. Las configuraciones pasivas dejan enormes puntos ciegos.

Para que la supervisión del DNS sea eficaz, se requieren tres controles activos:

1. Supervisión automatizada de la integridad de los archivos de zona: configura programas de supervisión automatizados que controlen tus archivos de zona de referencia las 24 horas del día, los 7 días de la semana. Tu equipo debería recibir alertas inmediatas si se producen cambios inesperados en registros críticos (como los registros NS, MX, A o TXT raíz).
2. Alertas sobre modificaciones en los registros MX y NS: La modificación de un registro MX permite a un atacante redirigir el correo entrante a través de sus servidores para obtener tokens confidenciales de restablecimiento de contraseña. Las alertas sobre cambios en los registros MX y NS deben activar de forma inmediata los flujos de trabajo de incidentes prioritarios.
3. Análisis de registros de consultas DNS: integra los registros de Protective DNS (PDNS) en tu plataforma de gestión de información y eventos de seguridad (SIEM). La correlación de los registros de consultas DNS con los historiales de asignaciones DHCP permite a los analistas rastrear las búsquedas de dominios maliciosos hasta los dispositivos internos comprometidos.

La autenticación del correo electrónico como medida de control del DNS

Un error habitual en materia de seguridad del DNS es separar los controles del tráfico web de los controles del correo electrónico. SPF, DKIM y DMARC se basan íntegramente en los registros TXT del DNS para publicar claves públicas y políticas de remitentes.

• SPF: Publica una lista de direcciones IP y servidores de correo autorizados para enviar correo saliente en nombre de tu dominio.
• DKIM: Añade firmas criptográficas a los encabezados de los correos electrónicos salientes. Los destinatarios obtienen la clave pública correspondiente del DNS de tu dominio para verificar que el mensaje no ha sido alterado durante la transmisión.
• DMARC: combina SPF y DKIM. DMARC indica a los servidores de correo receptores cómo gestionar los correos electrónicos que no superan la autenticación.

Si configuras tu política con p=reject, se indica a los servidores de correo receptores que descarten automáticamente los mensajes no autenticados. Comprender tu política DMARC activa protege la reputación de tu marca en las redes receptoras de todo el mundo.

Puedes comprobar al instante el estado actual de la autenticación de tu correo electrónico utilizando una herramienta en línea para comprobar los registros DMARC.

Aunque DMARC impide la suplantación de dominios en el correo electrónico, hay que tener en cuenta que DMARC no protege contra el envenenamiento de caché ni la apropiación de subdominios. Una estrategia defensiva completa requiere reforzar tanto la resolución DNS de la red como los registros DNS del correo electrónico.

DNS gestionado y filtrado en la capa DNS: dónde encajan

Las empresas modernas suelen implementar plataformas de DNS gestionadas y filtros de seguridad en la capa de DNS para simplificar las operaciones y mejorar la visibilidad de las amenazas.

Proveedores de DNS gestionado de confianza

Los proveedores de DNS gestionado para empresas operan redes Anycast globales que distribuyen su archivo de zona autoritativo por cientos de ubicaciones periféricas. La infraestructura Anycast ofrece mitigación de DDoS integrada, lo que permite absorber ataques volumétricos masivos antes de que lleguen a su red central. Las plataformas gestionadas también automatizan la gestión de claves DNSSEC y el mantenimiento de los registros DNS.

Filtrado recursivo en la capa DNS (DNS protector)

Las soluciones de DNS protector (PDNS) funcionan en la capa del resolutor recursivo. En lugar de limitarse a responder a las consultas, las soluciones PDNS comparan cada solicitud con bases de datos dinámicas de inteligencia sobre amenazas.

Si un empleado hace clic en un enlace que conduce a un dominio de phishing recién registrado o si una carga útil infectada intenta conectarse a un servidor C2, el resolutor de protección bloquea la resolución en la capa de red.

Ni el DNS gestionado ni el filtrado de DNS sustituyen a las buenas prácticas de los registradores de dominios ni a una configuración adecuada de los registros. Ambos constituyen capas complementarias dentro de una arquitectura de seguridad «Zero Trust» más amplia.

Qué auditar primero: plan de acción prioritario

Si tu equipo de seguridad no puede poner en práctica los doce puntos de la lista de comprobación este trimestre, céntrate primero en los logros que tengan mayor impacto. Lleva a cabo estas cinco tareas en el orden indicado:

1. Activa la opción «clientTransferProhibited» y los bloqueos de registro en todos los dominios principales. Exige el uso de llaves de hardware FIDO2 a todos los usuarios de cuentas de registrador para eliminar los riesgos de apropiación de cuentas.
2. Restringe las transferencias de zona AXFR mediante la auditoría de los servidores de nombres autoritativos para bloquear de inmediato las transferencias de zona sin restricciones.
3. Realizar un inventario de todos los registros CNAME publicados, compararlos con los recursos en la nube activos y eliminar cualquier entrada huérfana.
4. Configura alertas automáticas de MX y NS estableciendo una supervisión continua de los registros de la zona raíz, de modo que tu equipo reciba alertas inmediatas ante cualquier modificación no autorizada.
5. Revisa las fuentes de correo activas, resuelve las discrepancias de alineación y actualiza tu política DMARC para rechazar los mensajes falsificados.

Preguntas frecuentes

¿Qué es la seguridad del DNS en términos sencillos?

La seguridad del DNS abarca los protocolos técnicos, los controles de acceso y las prácticas administrativas que se utilizan para proteger el sistema de resolución de nombres de dominio. Garantiza que, cuando los usuarios escriben tu nombre de dominio en un navegador, se conecten a tus servidores reales y no a un sitio malicioso creado por un atacante.

¿DNSSEC cifra el tráfico DNS?

No, DNSSEC no cifra las consultas ni las respuestas del DNS. Las consultas DNSSEC estándar se transmiten en texto sin cifrar. DNSSEC utiliza firmas digitales para verificar que los datos del DNS que recibes son auténticos y no han sido alterados durante la transmisión. Para cifrar el tráfico de consultas del DNS, debes implementar DNS sobre HTTPS (DoH), DNS sobre TLS (DoT) o DNS sobre QUIC (DoQ).

¿Cuál es la diferencia entre DNSSEC y DNS sobre HTTPS (DoH)?

DNSSEC verifica la integridad de los datos a nivel de zona, lo que garantiza que la respuesta procede del verdadero propietario del dominio y no ha sido modificada. DoH cifra la ruta de transporte entre el dispositivo del usuario final y el resolutor recursivo.

¿El secuestro de DNS es lo mismo que la suplantación de DNS?

No. El secuestro de DNS consiste en obtener acceso administrativo al registrador del dominio o al servidor de nombres para modificar la configuración oficial del DNS. La suplantación de DNS (o «envenenamiento de caché») engaña a un resolutor recursivo para que almacene direcciones IP falsas en su caché sin alterar la configuración oficial del registrador.

¿Cómo puedo saber si el DNS de mi dominio ha sido vulnerado?

Entre los indicadores más habituales se encuentran los redireccionamientos inesperados de la página web, las caídas repentinas en la entrega de correos electrónicos, la emisión de certificados TLS no autorizados para tu dominio o los cambios inesperados en tus registros NS, A o MX durante las auditorías rutinarias.

¿Se consideran SPF, DKIM y DMARC medidas de seguridad del DNS?

Sí. Los registros SPF, DKIM y DMARC se publican directamente en la zona DNS pública de tu dominio. Dado que los servidores de correo receptores consultan el DNS para validar la autenticidad del remitente de los mensajes, unos registros de autenticación de correo electrónico precisos son un componente esencial para reforzar la seguridad del DNS del dominio.

Conclusión

La seguridad del DNS no es un producto único que se compra e instala. Se trata de un conjunto de medidas en varias capas que abarca la administración del registrador de dominios, el refuerzo de la seguridad de los servidores de nombres autoritativos, el cifrado del transporte de consultas y las comprobaciones de integridad de los registros.

Dejar cualquier capa sin supervisar ofrece a los autores de amenazas la oportunidad de secuestrar el tráfico, llevar a cabo ataques de tipo «hombre en medio» o suplantar las comunicaciones corporativas.

Empieza hoy mismo a reforzar la infraestructura de tu dominio realizando un inventario completo de tus archivos de zona activos. Utiliza un servicio gratuito de búsqueda de registros DNS para auditar los registros publicados y comprueba tu dominio con una herramienta de verificación de registros DMARC para garantizar que tu marca siga estando protegida.

• Acerca de
• Últimas publicaciones

Milena Baghdasaryan

Especialista en contenidos en PowerDMARC

Milena es una hábil escritora y creadora de contenidos con más de 7 años de experiencia en la elaboración de contenidos atractivos sobre TI, ciberseguridad, eventos virtuales y mucho más. Tiene un historial probado de entrega de trabajos de alta calidad para revistas internacionales y se ha graduado en prestigiosas instituciones como la New York University Abu Dhabi, UWC China y el College of Europe.

Últimos mensajes de Milena Baghdasaryan (ver todos)

• Prácticas recomendadas de seguridad del DNS: una lista de comprobación completa para reforzar la seguridad - 7 de septiembre de 2026
• SPF dinámico, SPF automático y SPF alojado: ¿cuál de ellos corrige realmente tu registro SPF? - 25 de agosto de 2026
• «Responder» frente a «Responder a todos»: normas de etiqueta y riesgos de seguridad - 14 de agosto de 2026