La identidad del resolver .2 de VPC - Relación entre el DNS interno de AWS y Route 53 Resolver
Explicamos qué es el resolver DNS de VPC (dirección CIDR+2), la integración con zonas alojadas privadas, el DNS híbrido con endpoints de Route 53 Resolver y el uso de logs de consultas DNS.
Qué hay en la dirección CIDR+2 de VPC
Al crear una VPC, la segunda dirección del bloque CIDR (10.0.0.2 para 10.0.0.0/16) se reserva como resolver DNS. Si se verifica el archivo /etc/resolv.conf de una instancia EC2, esta dirección aparece configurada como nameserver. Este resolver .2 es un servicio DNS gestionado de AWS llamado Route 53 Resolver. Las consultas DNS de las instancias se envían a este resolver .2, y Route 53 Resolver realiza la resolución de nombres. Route 53 Resolver realiza diferentes procesamientos según el contenido de la consulta. Si el dominio pertenece a una zona alojada privada asociada a la VPC, devuelve los registros de la zona alojada privada. Si es un endpoint de servicio interno de AWS (como ec2.ap-northeast-1.amazonaws.com), lo resuelve con el DNS interno de AWS. Para cualquier otro dominio, lo resuelve con DNS público (zonas alojadas públicas de Route 53 o DNS de Internet). Esta distribución se realiza automáticamente sin necesidad de configuración por parte del usuario.
Zonas alojadas privadas - DNS válido solo dentro de la VPC
Las zonas alojadas privadas de Route 53 son zonas DNS que solo pueden resolverse desde dentro de la VPC. Por ejemplo, si se crea una zona alojada privada internal.example.com y se configura un registro que resuelve api.internal.example.com a 10.0.1.100, las instancias dentro de la VPC pueden acceder al servicio interno mediante api.internal.example.com, pero no se puede resolver desde Internet. Las zonas alojadas privadas pueden asociarse a múltiples VPCs. Si se asocia la misma zona alojada privada a las VPCs de desarrollo, staging y producción, se pueden usar nombres DNS internos unificados entre entornos. Sin embargo, si se desea resolver a diferentes direcciones IP en cada entorno, es necesario crear zonas alojadas privadas separadas por entorno. Una característica interesante de las zonas alojadas privadas es que pueden usar el mismo nombre de dominio que una zona alojada pública. Si existen tanto una zona alojada pública como privada para example.com, las consultas desde dentro de la VPC priorizan la zona alojada privada. Esto se denomina DNS de horizonte dividido (split-horizon DNS).
Endpoints de Route 53 Resolver - Implementación de DNS híbrido
Cuando se conecta una red on-premises con una VPC mediante Direct Connect o VPN, la resolución de nombres DNS se convierte en un desafío. Surge la necesidad de resolver dominios de zonas alojadas privadas de la VPC desde servidores on-premises, y viceversa, resolver dominios de Active Directory on-premises desde instancias dentro de la VPC. Los endpoints de Route 53 Resolver resuelven este desafío. El endpoint de entrada acepta consultas de servidores DNS on-premises y las reenvía al resolver .2 de la VPC. Se configura un reenviador condicional en el servidor DNS on-premises para los dominios privados de la VPC, apuntando a las direcciones IP del endpoint de entrada. El endpoint de salida reenvía consultas desde dentro de la VPC a servidores DNS on-premises. Se configuran reglas de Route 53 Resolver para reenviar consultas de dominios específicos (por ejemplo, corp.internal) a los servidores DNS on-premises. Los endpoints crean ENIs en cada AZ, asegurando redundancia multi-AZ. El precio es de 0,125 USD por hora por ENI + 0,40 USD por millón de consultas DNS.
Logs de consultas DNS - Visualización de la actividad DNS en la VPC
Los logs de consultas DNS de Route 53 Resolver son una función que registra todas las consultas DNS dentro de la VPC. Se registra qué instancia intentó resolver qué dominio y cuándo. Desde la perspectiva de seguridad, los logs de consultas DNS son extremadamente útiles. El malware a veces utiliza DNS para comunicarse con servidores C2 (Command and Control) mediante túneles DNS. Analizando los logs de consultas DNS, se pueden detectar consultas a dominios sospechosos. Por ejemplo, grandes cantidades de consultas a subdominios con cadenas aleatorias (a1b2c3d4.evil.com) son indicios de túneles DNS. Los destinos de los logs pueden ser CloudWatch Logs, S3 o Kinesis Data Firehose. CloudWatch Logs es adecuado para análisis en tiempo real, S3 + Athena para almacenamiento a largo plazo y análisis a gran escala, y Kinesis para análisis de streaming. GuardDuty analiza automáticamente los logs de consultas DNS y detecta amenazas como minería de criptomonedas, comunicaciones C2 y exfiltración de datos. Si GuardDuty está habilitado, casi no es necesario analizar manualmente los logs de consultas DNS.
Trampas del DNS - enableDnsSupport y enableDnsHostnames
La VPC tiene dos configuraciones relacionadas con DNS, y si se configuran incorrectamente, la resolución DNS no funcionará. enableDnsSupport (predeterminado: true) es la configuración que habilita el resolver .2 de la VPC. Si se establece en false, las instancias dentro de la VPC no podrán usar el resolver .2 y no podrán resolver nombres a menos que se configure un servidor DNS personalizado. enableDnsHostnames (predeterminado: false; true en la VPC predeterminada) es la configuración que asigna automáticamente un nombre de host DNS (ec2-1-2-3-4.compute-1.amazonaws.com) a las instancias con dirección IP pública. Si esta configuración es false, la asociación de zonas alojadas privadas no funcionará. Para usar zonas alojadas privadas, tanto enableDnsSupport como enableDnsHostnames deben ser true. Otra trampa es el conjunto de opciones DHCP. La dirección del servidor DNS distribuida a las instancias de la VPC se controla mediante el conjunto de opciones DHCP. Si se cambia el servidor DNS a un DNS on-premises con un conjunto de opciones DHCP personalizado, el resolver .2 dejará de usarse y las zonas alojadas privadas no podrán resolverse. Para aprender sistemáticamente el diseño DNS de VPC, puede consultar libros especializados (Amazon).