Seguridad dns y resolución de nombres privados

En este artículo se explica cómo diseñar DNS para redes Azure mediante zonas DNS privadas, Azure DNS solucionador privado y controles de seguridad dns. Abarca patrones de resolución de nombres privados, reenvío híbrido de DNS, integración de DNS de puntos de conexión privados y protección contra amenazas en la capa de DNS.

Lo que trata este artículo

DNS es la base de la conectividad de red: cada conexión comienza con una consulta de resolución de nombres. En Azure, el diseño de DNS determina cómo las cargas de trabajo se descubren entre sí a través de redes virtuales, cómo los sistemas locales resuelven los nombres hospedados en Azure y cómo los puntos de conexión privados pasan a ser accesibles mediante sus nombres de dominio completos y plenamente cualificados (FQDN). Más allá de la resolución, DNS también es una superficie expuesta a ataques. La tunelización de DNS, la filtración y las consultas a dominios malintencionados representan amenazas reales que requieren controles de seguridad de capa DNS.

En este artículo se tratan tres problemas de DNS:

  • Resolución de nombres privados: Cómo las máquinas virtuales, los contenedores y los servicios de plataforma resuelven los nombres dentro de Azure sin exponer consultas DNS a la red pública de Internet.
  • Reenvío híbrido de DNS: Cómo las redes locales resuelven nombres privados de Azure y cómo las cargas de trabajo de Azure resuelven nombres del entorno local.
  • Seguridad dns: Cómo bloquear consultas DNS malintencionadas, evitar la filtración de DNS y habilitar el filtrado de red basado en FQDN.

Quién necesita este artículo

Lea este artículo si:

  • Implemente puntos de conexión privados (si procede en su caso) y necesite que las cargas de trabajo resuelvan privatelink.* las zonas DNS correctamente.
  • Administra entornos híbridos en los que los sistemas locales deben resolver nombres privados de Azure (o viceversa).
  • Utilice Azure Firewall y necesite filtrado basado en FQDN en las reglas de red.
  • Desee bloquear las consultas DNS a dominios maliciosos conocidos en la capa de resolución.
  • Administre entornos de varias redes virtuales en los que la resolución DNS centralizada simplifica las operaciones.
  • Planifique la arquitectura DNS para topologías de tipo hub-spoke con servicios compartidos.

Enfoque lift-and-shift: Mantenga el comportamiento de nomenclatura DNS existente durante la migración. Use el reenvío bidireccional entre el DNS local y Azure, configure reenviadores condicionales para la resolución de horizonte dividido y albergue los nombres privados de Azure en zonas de DNS privado para que las aplicaciones mantengan su configuración actual de DNS.

Enfoque de modernización: Centralice la resolución de nombres a medida que migra las cargas de trabajo a una nueva plataforma. Use Azure DNS Private Resolver con conjuntos de reglas de reenvío para la resolución híbrida, integre zonas DNS privadas con Private Endpoints para servicios PaaS y habilite el proxy DNS de Azure Firewall para que las reglas basadas en FQDN y la resolución DNS compartan una única ruta en caché.

Enfoque multinube: Planifique el cambio de DNS entre nubes antes de migrar las cargas de trabajo. Utiliza Azure DNS Private Resolver para la resolución de nombres entre nubes, configura el reenvío condicional con AWS Route 53 Resolver o Google Cloud DNS, y reduce los valores de TTL antes de la migración para minimizar el riesgo de caché obsoleta.

servicios y características de Azure

En la tabla siguiente se describen los servicios y características de Azure implicados en la seguridad dns y la resolución de nombres privados.

Servicio o característica propósito Funcionalidad clave Cuándo se deben usar
Azure DNS (zonas públicas) Hospedaje autoritativo para nombres de dominio públicos Red anycast global, integración de RBAC de Azure, registros de alias para recursos de Azure Posee un dominio público y quiere hospedar registros DNS en Azure con alta disponibilidad.
Zonas DNS privadas de Azure Resolución de nombres en redes virtuales sin exposición pública Vinculación de VNet, registro automático de nombres de host de las VM, alojamiento de zonas de Private Link Resolución de nombres interna para cargas de trabajo de Azure. Necesario para la integración de DNS de punto de conexión privado.
Resolución privada de Azure DNS Reenvío de DNS entre Azure y redes externas Punto de conexión de entrada (resolución de entorno local a Azure), punto de conexión de salida (reenvío de Azure al entorno local), conjuntos de reglas de reenvío Entornos híbridos que requieren resolución DNS bidireccional sin implementar máquinas virtuales DNS personalizadas.
proxy DNS de Azure Firewall Interceptación de DNS centralizada para el filtrado de FQDN Almacena en caché las respuestas DNS, habilita las reglas de red basadas en FQDN y proporciona un único punto de conexión DNS para las VNets radiales. Si has implementado Azure Firewall y necesitas filtrar nombres de dominio completos (FQDN) en las reglas de red. Es necesario para garantizar una resolución coherente de los FQDN.
Directiva de seguridad de DNS Protección contra amenazas en la capa DNS Bloquea la resolución de dominios maliciosos conocidos mediante la fuente de Microsoft Threat Intelligence. Desea evitar que las cargas de trabajo se conecten a dominios de mando y control o de distribución de malware.

Conceptos de las zonas DNS privadas

Las zonas DNS privadas proporcionan resolución de nombres para redes virtuales vinculadas sin exponer los registros a internet. Comportamientos clave:

  • Vinculación de red virtual: Puede vincular una zona DNS privada a varias redes virtuales. Todos los recursos de las VNet vinculadas pueden resolver registros de la zona.
  • Registro automático: Cuando se habilita en un vínculo de red virtual, Azure crea automáticamente registros A para las máquinas virtuales implementadas en esa red virtual. Azure quita los registros al desasignar o eliminar máquinas virtuales. El registro automático solo funciona para máquinas virtuales (solo NIC principal). Una red virtual solo puede registrarse automáticamente en una zona DNS privada, pero puede vincular varias redes virtuales a la misma zona.
  • DNS de punto de conexión privado: los servicios de Azure a los que se accede a través de puntos de conexión privados requieren zonas DNS de vínculo privado específicas (por ejemplo, privatelink.blob.core.windows.net para Azure Blob Storage). Sin la zona correcta, los clientes resuelven la IP pública en lugar de la dirección del punto de conexión privado.

Arquitectura de resolución privada de DNS

Azure DNS Private Resolver elimina la necesidad de máquinas virtuales de DNS personalizadas en escenarios de reenvío híbrido. El diagrama siguiente muestra el flujo de resolución de DNS híbrido desde el entorno local, a través de Azure DNS Private Resolver, hasta una dirección IP de un punto de conexión privado.

Diagrama que muestra el flujo de resolución DNS híbrida desde el entorno local, a través del punto de entrada de Azure DNS Private Resolver, hasta una zona DNS privada y la dirección IP del punto de conexión privado.

El solucionador usa dos tipos de punto de conexión:

  • Punto de conexión de entrada: Proporciona una dirección IP que los servidores DNS locales pueden tener como destino como reenviador condicional. Azure DNS resuelve las consultas enviadas a esta dirección IP (incluidas las zonas de DNS privado vinculadas). Requiere una subred dedicada delegada a Microsoft.Network/dnsResolvers.
  • Punto de conexión saliente: Permite Azure cargas de trabajo reenviar consultas DNS a servidores DNS locales, otros proveedores de nube o solucionadores externos. También requiere una subred dedicada. Los conjuntos de reglas de reenvío asociados al punto de conexión de salida definen qué sufijos de dominio reenviar y qué servidores DNS de destino se van a usar.

Importante

Cada uno de los puntos de conexión entrantes y salientes requiere su propia subred dedicada. No puede implementar otros recursos en estas subredes. No es necesario que una VNet vinculada a un conjunto de reglas de reenvío tenga un emparejamiento con la VNet del resolutor. Los vínculos de conjuntos de reglas funcionan independientemente del emparejamiento de VNet.

Cómo elegir

Use el siguiente árbol de decisión para seleccionar los componentes DNS adecuados para su entorno.

Árbol de decisión

  1. ¿Usa puntos de conexión privados?

    • Sí → Implemente zonas DNS privadas con los nombres de zona adecuados privatelink.* Vincula las zonas a las VNet que necesiten resolver direcciones de puntos de conexión privados.

  2. ¿Los sistemas locales deben resolver Azure nombres privados?

    • Sí → Implementar un resolvedor privado de DNS con un punto de conexión de entrada. Configure servidores DNS locales con reenviadores condicionales que apunten a la dirección IP del punto de conexión de entrada.

  3. ¿Necesitan las cargas de trabajo de Azure resolver nombres locales?

    • Sí → Implementar resolución privada de DNS con un punto de conexión de salida. Cree conjuntos de reglas de reenvío para sufijos de dominio locales (por ejemplo, corp.contoso.com).

  4. ¿Implementa Azure Firewall y necesita filtrado de FQDN en reglas de red?

    • Sí → Habilitar el proxy DNS del firewall. Configure las máquinas virtuales spoke para usar la IP privada del firewall como servidor DNS.

  5. ¿Desea bloquear las consultas DNS a dominios malintencionados conocidos?

    • Sí → Habilite la directiva de seguridad de DNS con la fuente de Microsoft Threat Intelligence en las VNet de destino.

Patrones comunes

Pattern Components Caso de uso
Resolución solo mediante punto de conexión privado zonas DNS privadas + vínculos de red virtual Cargas de trabajo solo en la nube que acceden a los servicios de PaaS a través de puntos de conexión privados. No hay conectividad híbrida.
Resolución bidireccional híbrida Zonas DNS privadas + resolutor DNS privado (entrante + saliente) El entorno local resuelve los nombres privados de Azure; Azure resuelve los nombres de Active Directory del entorno local.
DNS del centro centralizado Resolutor DNS privado en la VNet central + conjuntos de reglas de reenvío vinculados a las redes secundarias Topología de centro y radios en la que toda la resolución de DNS pasa por el centro para permitir el registro y el control centralizados.
DNS mediado por firewall Azure Firewall proxy DNS + zonas de DNS privado Entornos que usan firewall para el filtrado de FQDN. El firewall intercepta el tráfico DNS, lo que permite una resolución coherente de FQDN a IP para las reglas de red.
Pila de seguridad completa Todas las opciones anteriores, además de la directiva de seguridad de DNS Entornos empresariales que requieren resolución híbrida, filtrado de FQDN y protección contra amenazas de capa DNS.

Ejemplos de zona DNS de punto de conexión privado

En la tabla siguiente se enumeran los servicios de Azure comunes y sus nombres de zona de DNS privado necesarios.

Servicio de Azure Nombre de la zona DNS privada
Azure Blob Storage (Servicio de almacenamiento de blobs de Azure) privatelink.blob.core.windows.net
Azure SQL Database privatelink.database.windows.net
Azure Key Vault privatelink.vaultcore.azure.net
Archivos de Azure privatelink.file.core.windows.net
Azure Container Registry (Registro de Contenedores de Azure) privatelink.azurecr.io
Azure Cosmos DB (API de SQL) privatelink.documents.azure.com

Note

Para obtener la lista completa de nombres de zonas DNS privadas para todos los servicios de Azure, consulte Configuración de DNS de Azure Private Endpoint.

Prerequisites

Antes de implementar la seguridad dns y la resolución de nombres privados, asegúrese de que tiene:

  • Una red virtual: Todas las características de DNS funcionan dentro o entre redes virtuales. Consulte Redes virtuales y subredes para obtener instrucciones fundamentales. (F1)
  • Conectividad de red para escenarios híbridos: Los puntos de conexión de entrada del solucionador privado dns requieren la capacidad de acceso de red desde el entorno local (ExpressRoute o VPN) a la red virtual del solucionador.
  • Subredes dedicadas para la resolución privada dns: Cada punto de conexión (entrante y saliente) requiere su propia subred delegada en Microsoft.Network/dnsResolvers. Planifique al menos una /28 para cada subred de punto de conexión.
  • Puntos de conexión privados implementados (si se usan zonas privatelink): Las zonas DNS privadas para nombres privatelink.* solo tienen valor cuando existen puntos de conexión privados. Consulte Acceso de PaaS privado con puntos de conexión privados para obtener instrucciones de implementación. (C5)
  • Azure Firewall implementado (si se usa el proxy DNS): la característica de proxy DNS requiere una instancia de Azure Firewall existente. Consulte Azure Firewall y inspección del tráfico. (S1)
  • Permisos: Rol de colaborador de zona DNS para administrar zonas DNS privadas. Colaborador de red para la implementación de DNS Private Resolver.

Consideraciones de seguridad

DNS presenta vectores de ataque específicos que requieren controles dedicados. En las secciones siguientes se tratan los riesgos de filtración, el bloqueo basado en inteligencia sobre amenazas, el comportamiento del proxy DNS del firewall y las limitaciones de DNSSEC.

Riesgos de filtración de DNS

La tunelización DNS codifica los datos en las consultas DNS para filtrar la información a través de un protocolo sin restricciones. Dado que la mayoría de las redes permiten DNS saliente (UDP/TCP 53), los atacantes usan DNS como canal encubierto. Mitigue este riesgo por:

  • Habilitar Azure Firewall proxy DNS y enrutar todo el tráfico DNS a través del firewall. El firewall registra todas las consultas DNS, lo que hace que la tunelización se pueda detectar a través del análisis.
  • Aplicación de la directiva de seguridad de DNS para bloquear la resolución de dominios asociados a herramientas de exfiltración conocidas y a infraestructuras de comando y control.
  • Supervisar patrones de consulta DNS en Azure Monitor para detectar anomalías, como etiquetas de subdominios inusualmente largas, volúmenes de consultas elevados a un solo dominio o consultas a dominios registrados recientemente.

Directiva de seguridad de DNS

La directiva de seguridad de DNS con Microsoft Threat Intelligence bloquea la resolución de DNS a dominios maliciosos conocidos a nivel de VNet. Cuando una carga de trabajo intenta resolver un dominio marcado por Centro de respuestas de seguridad de Microsoft (MSRC), la directiva bloquea la resolución antes de que se produzca cualquier conexión de red. Este control funciona independientemente de Azure Firewall y no requiere cambios en configuraciones de cargas de trabajo individuales.

Características clave:

  • Usa la fuente de inteligencia sobre amenazas de Microsoft obtenida de MSRC.
  • Funciona en la capa de resolución DNS: bloquea la consulta, no el tráfico.
  • Se aplica por VNet: habilítelo en todas las VNet que contienen cargas de trabajo que acceden a Internet.
  • A diferencia del filtrado FQDN del firewall: la directiva de seguridad de DNS bloquea los dominios maliciosos a nivel global sin necesidad de desplegar un firewall.

Proxy DNS de firewall y filtrado de FQDN

El proxy DNS de Azure Firewall es necesario para el filtrado basado en FQDN en las reglas de red. Sin el proxy de DNS, las solicitudes DNS de las máquinas virtuales cliente pueden resolverse en momentos distintos de los de la resolución del firewall, lo que provoca una asignación incoherente de IP a FQDN y desajustes en las reglas.

Al habilitar el proxy DNS:

  • Configure las máquinas virtuales spoke para usar la dirección IP privada del firewall como servidor DNS.
  • El firewall resuelve las consultas en nombre de los clientes y almacena en caché los resultados (caché positiva hasta 1 hora, caché negativa hasta 30 minutos).
  • Las asociaciones de FQDN a IP se actualizan cada 15 segundos. El firewall quita las entradas obsoletas después de 15 minutos.
  • Las reglas de aplicación (L7) usan la indicación de nombre de servidor (SNI) para la coincidencia de FQDN y no requieren proxy DNS. Las reglas de red (L4) requieren proxy DNS para la resolución FQDN.
  • El filtrado de FQDN en reglas de red solo admite coincidencias exactas de dominio. Los patrones comodín no son compatibles con los nombres de dominio completos (FQDN) de las reglas de red. Utilice reglas de aplicación para la coincidencia de FQDN con comodines.

Note

Si todos los servidores DNS ascendentes configurados dejan de estar disponibles, el proxy DNS de Azure Firewall no recurre a un solucionador alternativo. La resolución de DNS falla hasta que se recupere al menos un servidor DNS superior. Planifique la redundancia de los servidores DNS en su configuración de upstream.

Caution

Si habilita el proxy DNS pero no configura las máquinas virtuales cliente para usar el firewall como servidor DNS, las reglas de red basadas en FQDN no funcionarán correctamente. Los clientes y el firewall pueden resolver direcciones IP diferentes para el mismo FQDN, lo que provoca caídas inesperadas del tráfico.

Limitaciones de DNSSEC

Azure DNS no admite actualmente la validación de DNSSEC para zonas privadas. Las zonas públicas hospedadas en Azure DNS admiten la firma DNSSEC para respuestas autoritativas, pero la resolución recursiva dentro de Azure redes virtuales no realiza la validación de DNSSEC. Si los requisitos de seguridad exigen la validación de DNSSEC, evalúe el uso de una resolución DNS personalizada que admita la validación o implemente la comprobación de capa de aplicación.

Consideraciones de diseño

Enfoque del diseño de DNS lift-and-shift

  • Configure el reenvío bidireccional de DNS entre servidores DNS locales y Azure DNS Private Resolver.
  • Use reenviadores condicionales para que las consultas del entorno local sobre nombres hospedados en Azure se resuelvan en Azure, y para que las consultas de Azure sobre nombres del entorno local se resuelvan mediante su infraestructura DNS existente.
  • Cree zonas DNS privado para cada servicio Azure que usan las cargas de trabajo migradas, especialmente los servicios respaldados por puntos de conexión privados.
  • Mantenga el comportamiento DNS de la aplicación durante la migración mediante registros de alias o asociaciones CNAME, en lugar de cambiar la configuración del resolvedor del cliente.

Modernización del foco de diseño de DNS

  • Centraliza la resolución de DNS en el nodo central mediante Azure DNS Private Resolver con conjuntos de reglas de reenvío compartidos entre las redes virtuales de los nodos periféricos.
  • Vincula las zonas de DNS privadas de cada servicio PaaS respaldado por un punto de conexión privado, de modo que las cargas de trabajo migradas resuelvan automáticamente los nombres de Privatelink.
  • Habilite el proxy de DNS de Azure Firewall para que las reglas de red basadas en FQDN y la resolución DNS de las cargas de trabajo usen una ruta de resolución coherente y en caché.
  • Use el registro automático y Azure RBAC en las zonas DNS privadas para reducir la administración manual de los registros al adoptar la infraestructura como código.

Enfoque de diseño de DNS entre nubes

  • Utiliza Azure DNS Private Resolver como punto de control de reenvío para la resolución de nombres entre nubes.
  • Configure el reenvío condicional entre Azure Private DNS, AWS Route 53 Resolver y Google Cloud DNS para cada espacio de nombres privado que deba resolverse en todos los entornos.
  • Planifique el cambio de DNS por fases: reduzca los valores de TTL, valide las rutas de reenvío, cambie los registros CNAME o A y supervise la latencia de las consultas y el comportamiento de la caché.
  • Aplique DNSSEC en las zonas autoritativas donde las plataformas conectadas lo permitan y documente dónde las rutas de resolución privadas no validan DNSSEC.

Aprende más

Pasos siguientes

Sugerencia

¿Explorando por su cuenta? Vuelva al navegador de información general para encontrar el siguiente artículo por funcionalidad.

Siguiente paso en su proceso de lift-and-shift:

Controlar el tráfico saliente de Internet: centralice toda la comunicación saliente a través de Azure Firewall y desactive el acceso de salida predeterminado.

A continuación en su proceso de modernización:

Configure la supervisión de producción: habilite Network Watcher y Network Monitor de rendimiento para que el entorno de producción esté listo desde el primer día.

Próximo paso en su proceso de migración entre nubes:

Proteja su ruta de tránsito entre nubes: implemente Azure Firewall en su hub virtual seguro para inspeccionar todo el tráfico entre nubes, de sucursales y con destino a Internet.

  • Last updated on