Microsoft AZ-700: Azure DNS y Resolución de Nombres — Guía de estudio

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Forma parte de la Microsoft Azure Network Engineer AZ-700 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Azure DNS: zonas públicas, zonas privadas y contrapartidas

Azure proporciona tanto alojamiento de DNS público como resolución de DNS privado estrechamente integrados con el plano de red virtual, y elegir entre ellos es una cuestión de alcance, control, costo y sobrecarga operativa. Las zonas públicas de Azure DNS (alojadas en Azure DNS) son apropiadas para nombres orientados a internet y se benefician de puntos de conexión anycast globales, una gestión predecible a través de API y una escalabilidad por consulta. Las zonas de DNS privado le permiten crear zonas autoritativas para nombres que solo se resuelven a direcciones IP privadas dentro de las VNets vinculadas; eliminan la necesidad de ejecutar y mantener máquinas virtuales de DNS para la resolución de nombres dentro de Azure y admiten la gestión automática de registros cuando se integran con ciertos puntos de conexión privados de PaaS. La principal contrapartida es el control: los servidores DNS personalizados (Windows DNS, BIND) ofrecen una flexibilidad absoluta —reenvío condicional, políticas avanzadas y comportamiento de SRV/CNAME integrado con AD— a costa de la sobrecarga de gestión de máquinas virtuales y la responsabilidad de la resiliencia. Las decisiones de rendimiento se reducen a latencia frente a costo: los servicios de DNS gestionados de Azure reducen el mantenimiento y proporcionan velocidad de resolución global para consultas públicas, mientras que los reenviadores de DNS o dispositivos de resolución residentes en el hub pueden mejorar el rendimiento híbrido y aplicar políticas, pero añaden costo de computación y disponibilidad. Errores comunes incluyen olvidar vincular una zona de DNS privado a cada VNet que necesita resolución, no migrar las delegaciones al mover nombres desde el entorno local (on-prem) a Azure, y esperar un comportamiento automático de horizonte dividido (split-horizon) de público a privado sin registros DNS explícitos o reenvío.

Azure DNS (Público): anycast global, API gestionada, facturación por zona/consulta.
Zonas de DNS privado: resolución acotada a la VNet, creación automática de registros privados para PaaS compatibles.
App Gateway WAF_v2: recomendado por sus características de WAF modernas y su modelo de escalado v2.
Azure Firewall (Standard/Policy): opción de proxy DNS central; añade costo pero centraliza la política.
DNS personalizado (basado en VM): control máximo, mayores costos de operaciones y disponibilidad.

Zonas de DNS privado, registros de puntos de conexión privados y estrategias de nomenclatura

Cuando convierte servicios alojados públicamente a puntos de conexión privados o migra servidores a Azure, el DNS se convierte en el punto de coordinación. Los puntos de conexión privados registran registros A a nivel de NIC en zonas de DNS privado que deben coincidir con el FQDN público que desea que usen los clientes; el patrón correcto es crear zonas privadas que reflejen el espacio de nombres público (por ejemplo, contoso.com) o usar zonas privatelink específicas del servicio (para servicios de plataforma) y luego habilitar el registro automático o crear registros A/CNAME manuales que mapeen el FQDN a la IP privada del punto de conexión. El alcance importa: vincular una zona privada a una única VNet limita la resolución a esa VNet; los diseños hub-and-spoke requieren vincular la zona a todos los spokes o usar el reenvío de DNS desde los spokes a un resolutor en el hub. Un error de migración típico es dejar el DNS público apuntando a la antigua IP local (on-prem) mientras los clientes de Azure resuelven a una IP privada; para evitar la confusión de cerebro dividido (split-brain), planifique pasos de transición limpios: actualice los registros públicos solo después de que se validen el DNS privado y el reenvío, o use un esquema de nombres de horizonte dividido con una zona privada explícita para el mismo nombre. Los certificados y las cabeceras de host deben coincidir: si espera que Application Gateway realice TLS de extremo a extremo hacia un backend privado, asegúrese de que el CN/SAN del certificado del backend coincida con el nombre de host que la puerta de enlace envía como cabecera Host; de lo contrario, el TLS del backend fallará.

Azure Private Resolver y patrones de resolución de nombres híbridos

Azure Private Resolver permite el reenvío de DNS gestionado y escalable entre las VNets de Azure y las redes locales (on-premises) sin necesidad de poseer máquinas virtuales de DNS. Los patrones de diseño suelen colocar los puntos de conexión del resolutor en una VNet de tipo hub: los puntos de conexión de entrada reciben consultas desde el entorno local (a través de VPN/ExpressRoute) para zonas privadas de Azure, mientras que los puntos de conexión de salida reenvían las consultas de Azure a los servidores DNS locales para nombres de uso exclusivamente interno. Los conjuntos de reglas del resolutor definen el reenvío condicional para espacios de nombres específicos (por ejemplo, contoso.internal → IPs de DNS local) y se pueden asociar con VNets; para implementaciones empresariales globales, se centraliza la gestión de reglas en el hub y se enruta o se hace peering del tráfico desde los spokes hacia el resolutor del hub. Las contrapartidas entre rendimiento y costo incluyen el aprovisionamiento de múltiples puntos de conexión de entrada en varias regiones para obtener resiliencia y baja latencia (lo que añade costo) o aceptar puntos de conexión de resolutor en una sola región con peering pero con una mayor latencia entre regiones. Errores comunes: no actualizar los reenviadores condicionales locales para que apunten a las IPs de entrada del resolutor, configurar incorrectamente las reglas del grupo de seguridad de red (NSG) que bloquean el tráfico DNS TCP/UDP por el puerto 53 hacia los puntos de conexión del resolutor, y asumir que el DNS proporcionado por Azure (168.63.129.16) reenviará al entorno local; se requiere una configuración explícita del resolutor para el reenvío condicional.

Puertos DNS: se deben permitir los puertos 53 UDP y 53 TCP para la resolución típica y las transferencias de zona.
Puntos de conexión del resolutor: desplegar en VNets de tipo hub; asegurar que los NSG y el firewall permitan el DNS entrante.

Servidores DNS personalizados, proxy de DNS y trampas operativas

Los servidores DNS personalizados (controladores de dominio de Windows DNS o BIND en Linux) siguen teniendo sentido cuando se requiere integración con Active Directory, reenvío condicional complejo o políticas de DNS avanzadas; sin embargo, introducen responsabilidades operativas: aplicación de parches, clústeres de alta disponibilidad (HA), copias de seguridad y escalado. Las alternativas que reducen las operaciones (Ops) son las zonas de Azure Private DNS para la resolución dentro de Azure y Azure Private Resolver o el proxy de DNS de Azure Firewall para centralizar las políticas de reenvío. Los proxies de DNS (la característica de proxy de DNS de Azure Firewall o NVA de terceros) pueden interceptar y reenviar las consultas de DNS a resolutores seleccionados, lo que simplifica las políticas y el registro, pero puede añadir puntos únicos de fallo y latencia adicional. Las decisiones clave de diseño incluyen si usar reenviadores basados en VM en un hub (menor costo, mayor mantenimiento) frente a Azure Private Resolver (gestionado, mejor escalabilidad), cuántos puntos de conexión de resolutor desplegar entre regiones para latencia/resiliencia, y si habilitar el registro automático de DNS para los private endpoints. Los errores frecuentes de los ingenieros son depender únicamente del emparejamiento de VNet (VNet peering) para la resolución de DNS (el emparejamiento no comparte automáticamente las zonas de Azure Private DNS), olvidar conceder al Private Endpoint el permiso para registrar automáticamente los registros DNS y no validar las cadenas de certificados al implementar TLS de extremo a extremo a través de una puerta de enlace; todo esto interrumpe la resolución de nombres o las conexiones seguras en producción.

Problema práctico: Escenario de caso de uso

Escenario: Fabrikam Inc. opera una red hub-and-spoke multirregional en Azure. El hub en East US contiene un Azure Firewall (Standard) y un perfil de Traffic Manager enruta a los usuarios de internet a instancias de Application Gateway WAF_v2 en dos regiones. Dos instancias de App Service alojan www.fabrikam.com, cada una migrada desde el entorno local (on-prem) con private endpoints en sus spokes regionales.

Desafío: Los clientes locales (on-prem) y los spokes de Azure deben resolver www.fabrikam.com a los private endpoints de App Service después de la migración, Application Gateway debe preservar las cabeceras de host para habilitar el TLS de extremo a extremo, y la resolución de DNS debe ser resiliente entre regiones.

Enfoque recomendado:

Despliegue una zona de Azure Private DNS llamada fabrikam.com en el hub y vincúlela tanto a las VNet de los spokes regionales como a la VNet del hub; añada registros A para www.fabrikam.com que apunten a las IP de los private endpoints (o habilite el registro automático para los private endpoints de App Service).
Despliegue puntos de conexión de entrada (inbound endpoints) de Azure Private Resolver en el hub (uno por región para resiliencia si es necesario) y configure reenviadores condicionales locales (on-prem) para reenviar las consultas de fabrikam.com a las IP de entrada del resolutor.
Configure los ajustes HTTP de Application Gateway WAF_v2 para usar HTTPS en el puerto 443, establezca la cabecera de host del backend en www.fabrikam.com y asegúrese de que los sondeos de estado del backend (health probes) usen HTTPS con una cabecera de host que coincida con el CN/SAN del certificado.
Valide ejecutando consultas de DNS desde el entorno local (on-prem) y desde los spokes para asegurarse de que devuelven IP privadas, y verifique el TLS de extremo a extremo de Application Gateway comprobando el CN/SAN del certificado y el éxito del sondeo.

Justificación: Centralizar la funcionalidad de DNS privado y de resolutor en el hub proporciona una única fuente de verdad y simplifica el reenvío condicional híbrido; vincular la zona privada a todas las VNet y asegurar que la puerta de enlace use la cabecera de host correcta preserva la validación de certificados para el TLS de extremo a extremo, equilibrando la gestionabilidad operativa, el rendimiento y la resiliencia.

← Redes Híbridas · Todos los dominios · Seguridad de Red →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →