Compartir vía

Resolución de nombres de recursos en redes virtuales de Azure

  • Artículo

Azure se puede usar para hospedar soluciones híbridas, IaaS. y PaaS. Para facilitar la comunicación entre las máquinas virtuales (VM) y otros recursos implementados en una red virtual, puede ser necesario permitirles comunicarse entre sí. El uso de nombres inmutables y que se pueden recordar fácilmente simplifica el proceso de comunicación, en lugar de depender de direcciones IP.

Si los recursos implementados en redes virtuales necesitan resolver nombres de dominio en direcciones IP internas, pueden usar uno de cuatro métodos:

El tipo de resolución de nombres que tenga que usar dependerá de cómo se comuniquen los recursos entre sí. En la siguiente tabla se muestran los escenarios y las soluciones de resolución de nombre correspondientes:

Nota:

Las zonas privadas de Azure DNS son la solución preferida y proporcionan flexibilidad para la administración de los registros y las zonas DNS. Para obtener más información, vea Uso de Azure DNS para dominios privados.

Nota:

Si usa un DNS proporcionado por Azure, el sufijo DNS adecuado se aplicará automáticamente a las máquinas virtuales. Para todas las demás opciones, debe usar nombres de dominio completos (FQDN) o aplicar manualmente el sufijo DNS adecuado a las máquinas virtuales.

Escenario Solución Sufijo DNS
Resolución de nombres entre máquinas virtuales ubicadas en la misma red virtual, o instancias de rol de Azure Cloud Services en el mismo servicio en la nube. Zonas privadas de Azure DNS o resolución de nombres proporcionada por Azure Nombre de host o FQDN
Resolución de nombres entre máquinas virtuales en redes virtuales diferentes o instancias de rol en diferentes servicios en la nube. Zonas privadas de Azure DNS, Azure DNS Private Resolver, o servidores DNS administrados por el cliente que reenvían consultas entre las redes virtuales para la resolución mediante Azure (proxy DNS). Consulte Resolución de nombres mediante su propio servidor DNS. Solo FQDN
Resolución de nombres de Azure App Service (aplicación web, función o bot) mediante la integración de red virtual con instancias de rol o máquinas virtuales en la misma red virtual. Azure DNS Private Resolver o servidores DNS administrados por el cliente que reenvían consultas entre redes virtuales para la resolución mediante Azure (proxy DNS). Consulte Resolución de nombres mediante su propio servidor DNS. Solo FQDN
Resolución de nombres entre instancias de App Service Web Apps en máquinas virtuales en la misma red virtual. Azure DNS Private Resolver o servidores DNS administrados por el cliente que reenvían consultas entre redes virtuales para la resolución mediante Azure (proxy DNS). Consulte Resolución de nombres mediante su propio servidor DNS. Solo FQDN
Resolución de nombres de App Service Web Apps de una máquina virtual a las máquinas virtuales de otra red virtual. Azure DNS Private Resolver o servidores DNS administrados por el cliente que reenvían consultas entre redes virtuales para la resolución mediante Azure (proxy DNS). Consulte Resolución de nombres mediante su propio servidor DNS. Solo FQDN
Resolución de nombres de servicios y de equipos locales de máquinas virtuales o instancias de rol en Azure. Azure DNS Private Resolver o servidores DNS administrados por el cliente (controlador de dominio local, controlador de dominio de solo lectura local o un DNS secundario sincronizado mediante transferencias de zona, por ejemplo). Consulte Resolución de nombres mediante su propio servidor DNS. Solo FQDN
Resolución de nombres de host de Azure desde equipos locales. Reenvío de consultas a un servidor proxy DNS administrado por el cliente en la red virtual correspondiente: el servidor proxy reenvía consultas a Azure para su resolución. Consulte Resolución de nombres mediante su propio servidor DNS. Solo FQDN
DNS inverso para direcciones IP internas. Zonas privadas de Azure DNS, resolución de nombres proporcionada por Azure, Azure DNS Private Resolver, o resolución de nombres mediante su propio servidor DNS. No aplicable
Resolución de nombres entre máquinas virtuales o instancias de rol ubicadas en diferentes servicios en la nube y no en una red virtual. No aplicable. La conectividad entre máquinas virtuales e instancias de rol de diferentes servicios en la nube no se admite fuera de una red virtual. No aplicable

Resolución de nombres de Azure

La resolución de nombres proporcionada por Azure solo ofrece las funcionalidades autoritativas básicas de DNS. Azure administra los nombres y registros de la zona DNS si usa el DNS proporcionado por Azure. No puede controlar los nombres de zona DNS ni el ciclo de vida de los registros DNS. Si necesita una solución de DNS completa para sus redes virtuales, puede usar zonas privadas de Azure DNS con servidores DNS administrados por el cliente o una instancia de Azure DNS Private Resolver.

Junto con la resolución de nombres DNS públicos, Azure proporciona una resolución de nombres interna para máquinas virtuales e instancias de rol que residen dentro de la misma red virtual o servicio en la nube. Las máquinas virtuales y las instancias en un servicio en la nube comparten el mismo sufijo DNS (por lo que el nombre de host por sí solo es suficiente). No obstante, en las redes virtuales implementadas con el modelo de implementación clásica, diferentes servicios en la nube tienen distintos sufijos DNS. En esta situación, es necesario el FQDN para resolver los nombres entre diferentes servicios en la nube. En las redes virtuales implementadas con el modelo de implementación de Azure Resource Manager, el sufijo DNS es coherente entre todas las máquinas virtuales de una red virtual, de modo que no es necesario el FQDN. Los nombres DNS se pueden asignar a máquinas virtuales y a interfaces de red. Aunque la resolución de nombres que proporciona Azure no necesita ningún tipo de configuración, no es la opción más adecuada para todos los escenarios de implementación, como se detalla en la tabla anterior.

Nota:

En el caso de los roles web y de trabajo de servicios en la nube, puede acceder a las direcciones IP internas de las instancias de rol mediante la API de REST de administración de servicios de Azure. Para obtener más información, consulte la Referencia de la API REST de administración de servicios. La dirección se basa en el nombre de rol y el número de instancia.

Características

La resolución de nombres proporcionada por Azure incluye las siguientes características:

  • Facilidad de uso. No se requiere ninguna configuración.

  • Alta disponibilidad. No es necesario crear clústeres de sus propios servidores DNS ni administrarlos.

  • Puede utilizar el servicio junto con sus propios servidores DNS para resolver nombres de host de Azure y locales.

  • Puede usar la resolución de nombres entre las máquinas virtuales y las instancias de rol del mismo servicio en la nube, sin necesidad de un nombre de dominio completo.

  • Puede usar la resolución de nombres entre las máquinas virtuales en redes virtuales que usan el modelo de implementación de Azure Resource Manager, sin necesidad de un nombre de dominio completo. En el modelo de implementación clásica, las redes virtuales requieren un FQDN cuando se resuelven nombres en diferentes servicios en la nube.

  • Puede usar los nombres de host que describan mejor las implementaciones, en lugar de trabajar con nombres generados automáticamente.

Consideraciones

Puntos que deben tenerse en cuenta cuando se utiliza la resolución de nombres de Azure:

  • El sufijo DNS creado por Azure no se puede modificar.

  • La búsqueda de DNS está en el ámbito de una red virtual. Los nombres DNS creados para una red virtual no se pueden resolver desde otras redes virtuales.

  • No puede registrar manualmente sus propios registros.

  • No se admiten ni WINS ni NetBIOS. No puede ver sus máquinas virtuales en el Explorador de Windows.

  • Los nombres de host deben ser compatibles con DNS. Los nombres solo pueden contener los caracteres 0-9, a-z y "-", y no pueden empezar ni terminar por "-".

  • El tráfico de consultas de DNS está limitado por cada máquina virtual. La limitación no debería afectar a la mayoría de las aplicaciones. Si se observa una limitación de solicitudes, asegúrese de que está habilitado el almacenamiento en caché del lado cliente. Para más información, consulte Configuración de cliente DNS.

  • Use un nombre diferente para cada máquina virtual de una red virtual para evitar problemas de resolución de DNS.

  • En un modelo de implementación clásico, solo se registran las máquinas virtuales de los 180 primeros servicios en la nube para cada red virtual clásica. Este límite no se aplica a las redes virtuales en Azure Resource Manager.

  • La dirección IP de Azure DNS es 168.63.129.16. Esta dirección es una dirección IP estática y no cambia.

Consideraciones sobre el DNS inverso

Se admite DNS inverso para las máquinas virtuales en todas las redes virtuales basadas en Azure Resource Manager. Los registros de DNS inverso (PTR) administrados por Azure con el formato [nombre_de_vm].internal.cloudapp.net se agregan automáticamente al DNS al iniciar una máquina virtual y se quitan cuando la máquina virtual se detiene (desasigna). Observe el ejemplo siguiente:

C:\>nslookup -type=ptr 10.11.0.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.0.11.10.in-addr.arpa  name = myeastspokevm1.internal.cloudapp.net

Azure administra la zona DNS inversa internal.cloudapp.net y no se puede ver ni editar directamente. La búsqueda directa por FQDN con el formato [nombre_de_vm].internal.cloudapp.net también se resuelve con la dirección IP asignada a la máquina virtual.

Si una zona privada de Azure DNS está vinculada a la red virtual con un vínculo de red virtual y el registro automático está habilitado en ese vínculo, las consultas de DNS inverso devuelven dos registros. Un registro tiene el formato [nombre_de_vm].[nombre_de_zona_dns_privada] y el otro tiene el formato [nombre_de_vm].internal.cloudapp.net. Observe el ejemplo siguiente:

C:\>nslookup -type=ptr 10.20.2.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.2.20.10.in-addr.arpa  name = mywestvm1.internal.cloudapp.net
4.2.20.10.in-addr.arpa  name = mywestvm1.azure.contoso.com

Cuando se devuelven dos registros PTR como hemos visto antes, la búsqueda directa de cualquier FQDN devuelve la dirección IP de la máquina virtual.

La búsqueda de DNS inverso tiene el ámbito de una red virtual determinada, aunque esté emparejada con otras redes virtuales. Las consultas de DNS inverso para direcciones IP de máquinas virtuales que se encuentran en redes virtuales emparejadas devuelven NXDOMAIN.

Nota

Los registros de DNS inverso (PTR) no se almacenan en una zona DNS privada de reenvío. Los registros de DNS inverso se almacenan en una zona DNS inversa (in-addr.arpa). La zona DNS inversa predeterminada asociada a una red virtual no se puede ver ni editar.

Si desea desactivar la función de DNS inverso en una red virtual, cree su propia zona de búsqueda inversa con zonas privadas de Azure DNS y vincule esta zona a la red virtual. Por ejemplo, si el espacio de direcciones IP de la red virtual es 10.20.0.0/16, puede crear una zona DNS privada vacía 20.10.in-addr.arpa y vincularla a la red virtual. Esta zona invalida las zonas de búsqueda inversa predeterminadas para la red virtual. Esta zona está vacía. DNS inverso devuelve NXDOMAIN a menos que cree manualmente estas entradas.

No se admite el registro automático de registros PTR. Si desea crear entradas, escríbalas manualmente. Debe deshabilitar el registro automático en la red virtual si está habilitado para otras zonas. Esta limitación se debe a restricciones que permiten que solo se vincule una zona privada si el registro automático está habilitado. Consulte Inicio rápido: Creación de una zona DNS privada de Azure con Azure Portal para obtener más información sobre cómo crear una zona DNS privada y vincularla a una red virtual.

Nota

Dado que las zonas privadas de Azure DNS son globales, puede crear una búsqueda de DNS inversa que abarque varias redes virtuales. Para ello, cree una zona privada de Azure DNS para búsquedas inversas (una zona in-addr.arpa) y vincúlela a las redes virtuales. Deberá administrar manualmente los registros de DNS inverso para las máquinas virtuales.

Configuración del cliente DNS

Esta sección trata los intentos del lado cliente y el almacenamiento en caché del cliente.

Almacenamiento en caché del lado cliente

No todas las consultas DNS deben enviarse a través de la red. El almacenamiento en caché del cliente ayuda a reducir la latencia y a mejorar la resistencia a la señalización visual de la red mediante la resolución de las consultas DNS periódicas desde una memoria caché local. Los registros DNS contienen un mecanismo para contabilizar el período de vida (TTL), lo que permite a la memoria caché almacenar el registro el máximo tiempo posible sin afectar a la actualización de registros. Por ello, el almacenamiento en caché del cliente es adecuado para la mayoría de las situaciones.

El cliente DNS de Windows predeterminado tiene una memoria caché DNS integrada. Algunas distribuciones de Linux no incluyen el almacenamiento en caché de forma predeterminada. Si comprueba que aún no hay una memoria caché local, agregue una memoria caché DNS a cada máquina virtual Linux.

Hay muchos paquetes de almacenamiento en caché de DNS disponibles; por ejemplo, dnsmasq. Aquí se indica cómo instalar dnsmasq en las distribuciones más habituales:

RHEL (usa NetworkManager):

  1. Instale el paquete dnsmasq con el siguiente comando:

    sudo yum install dnsmasq

  2. Habilite el servicio dnsmasq con el siguiente comando:

    systemctl enable dnsmasq.service

  3. Inicie el servicio dnsmasq con el siguiente comando:

    systemctl start dnsmasq.service

  4. Use un editor de texto para agregar prepend domain-name-servers 127.0.0.1; a /etc/dhclient-eth0.conf:

  5. Use el siguiente comando para reiniciar el servicio de red:

    service network restart

Nota:

El paquete dnsmasq constituye solo una de las muchas memorias cachés DNS disponibles para Linux. Antes de usarlo, compruebe su idoneidad para sus necesidades concretas y que no esté instalada ninguna otra memoria caché.

Reintentos del cliente

DNS es principalmente un protocolo UDP. Como el protocolo UDP no garantiza la entrega de mensajes, la lógica de reintento se controla en el mismo protocolo DNS. Cada cliente DNS (sistema operativo) puede presentar una lógica de reintento diferente en función de la preferencia del creador:

  • Los sistemas operativos Windows realizan un reintento tras un segundo y después tras otros dos, cuatro y otros cuatro segundos.
  • El programa de instalación predeterminado de Linux lo intenta después de cinco segundos. Se recomienda cambiar las especificaciones de reintento a cinco veces, en intervalos de un segundo.

Compruebe la configuración actual en una VM de Linux con cat /etc/resolv.conf. Mire la línea options, por ejemplo:

options timeout:1 attempts:5

El archivo resolv.conf se genera automáticamente y no se debe editar. Los pasos específicos para agregar la línea options varían según la distribución:

RHEL (usa NetworkManager):

  1. Use un editor de texto para agregar la línea RES_OPTIONS="options timeout:1 attempts:5" al archivo /etc/sysconfig/network-scripts/ifcfg-eth0.

  2. Use el siguiente comando para reiniciar el servicio de NetworkManager:

    systemctl restart NetworkManager.service

Resolución de nombres con su propio servidor DNS

En esta sección se tratan las máquinas virtuales, las instancias de rol y las aplicaciones web.

Nota

Azure DNS Private Resolver reemplaza la necesidad de usar servidores DNS basados en máquinas virtuales en una red virtual. En la sección siguiente se proporciona si quiere usar una solución DNS basada en máquinas virtuales, pero hay muchas ventajas para usar Azure DNS Private Resolver, incluida la reducción de costos, la alta disponibilidad integrada, la escalabilidad y la flexibilidad.

Máquinas virtuales e instancias de rol

Puede que sus necesidades de resolución de nombres superen las posibilidades de las características de Azure. Por ejemplo, es posible que necesite utilizar dominios de Microsoft Windows Server Active Directory y resolver nombres DNS entre redes virtuales. Para admitir estos escenarios, Azure le permite usar sus propios servidores DNS.

Los servidores DNS dentro de una red virtual pueden reenviar consultas DNS a las resoluciones recursivas en Azure. Este procedimiento le permite resolver los nombres de host dentro de esa red virtual. Por ejemplo, un controlador de dominio (DC) que se ejecute en Azure puede responder a las consultas DNS referidas a sus dominios y reenviar todas las demás consultas a Azure. El reenvío de consultas permite que las máquinas virtuales vean sus recursos locales (mediante el controlador de dominio) y los nombres de host proporcionados por Azure (mediante el reenviador). El acceso a las resoluciones recursivas de Azure se proporciona mediante la IP virtual 168.63.129.16.

Importante

Si VPN Gateway se usa en esta configuración junto con la dirección IP del servidor DNS personalizada en la red virtual, la dirección IP de Azure DNS (168.63.129.16) debe agregarse también en la lista para mantener el servicio sin interrumpir.

El reenvío de DNS también habilita la resolución de DNS entre redes virtuales y permite que los equipos locales resuelvan nombres de host proporcionados por Azure. Para resolver el nombre de host de una máquina virtual, la máquina virtual del servidor DNS debe residir en la misma red virtual y debe configurarse para reenviar consultas de nombre de host a Azure. Dado que el sufijo DNS es diferente en cada red virtual, puede usar las reglas de desvío condicional para enviar consultas de DNS a la red virtual correcta para su resolución. En la imagen siguiente se muestran dos redes virtuales y una red local que está realizando resolución DNS entre redes virtuales con este método. Puede encontrar un reenviador DNS de ejemplo disponible en la galería de plantillas de inicio rápido de Azure y en GitHub.

Nota:

Una instancia de rol puede realizar la resolución de nombres de máquinas virtuales dentro de la misma red virtual. Para ello, use el FQDN, que consta del nombre de host de la máquina virtual y el sufijo DNS internal.cloudapp.net. Sin embargo, en este caso, la resolución de nombres solo es correcta si la instancia de rol tiene el nombre de máquina virtual definido en el esquema Role (archivo .cscfg). <Role name="<role-name>" vmName="<vm-name>">

Las instancias de rol que tienen que realizar la resolución de nombres de máquinas virtuales en otra red virtual (FQDN utilizando el sufijo internal.cloudapp.net) tienen que hacerlo con el método descrito en esta sección (reenvío de servidores DNS personalizados entre las dos redes virtuales).

Diagrama de DNS entre redes virtuales

Cuando se utiliza la resolución de nombres proporcionada por Azure, el Protocolo de configuración dinámica de host (DHCP) de Azure proporciona un sufijo DNS interno (.internal.cloudapp.net) a cada máquina virtual. Este sufijo permite la resolución de nombres de host, dado que los registros de nombre de host están en la zona internal.cloudapp.net. Si utiliza su propia solución de resolución de nombres, no se proporciona este sufijo a las máquinas virtuales, ya que interfiere con otras arquitecturas DNS (como en el caso de los escenarios con unión a un dominio). En su lugar, Azure proporciona un marcador de posición no funcional (reddog.microsoft.com).

Si es necesario, el sufijo DNS interno se puede determinar con PowerShell o la API:

Si el reenvío de consultas a Azure no se ajusta a sus necesidades, proporcione su propia solución de DNS o implemente una instancia de Azure DNS Private Resolver.

Si proporciona su propia solución de DNS, debe:

  • Proporcionar la resolución adecuada de nombres de host, por ejemplo, mediante DDNS. Si utiliza DDNS, puede que tenga que deshabilitar la limpieza de registros de DNS. Las concesiones DHCP de Azure son muy largas y la limpieza puede eliminar registros DNS de forma prematura.

  • Proporcionar la resolución recursiva adecuada para permitir la resolución de nombres de dominio externos.

  • Estar accesible (TCP y UDP en el puerto 53) desde los clientes a los que sirve y poder acceder a Internet.

  • Tener protección contra el acceso desde Internet para mitigar las amenazas que suponen los agentes externos.

Nota:

  • Para obtener un rendimiento óptimo, cuando se usan máquinas virtuales de Azure como servidores DNS, debe deshabilitarse IPv6.
  • Los NSG actúan como firewalls para los puntos de conexión de resolución DNS. Debe modificar o invalidar las reglas de seguridad de NSG para permitir el acceso del puerto UDP 53 (y, opcionalmente, el puerto TCP 53) a los puntos de conexión del agente de escucha DNS. Una vez que los servidores DNS personalizados se establecen en una red, el tráfico a través del puerto 53 omitirá los NSG de la subred.

Importante

Si usa servidores DNS de Windows como servidores DNS personalizados que reenvía solicitudes DNS a servidores de Azure DNS, asegúrese de aumentar el valor de tiempo de espera de reenvío más de 4 segundos para permitir que los servidores DNS recursivos de Azure realicen operaciones de recursión adecuadas.

Para más información sobre este problema, vea Reenviadores y tiempos de espera de resolución de reenviadores condicionales.

Esta recomendación también se puede aplicar a otras plataformas del servidor DNS con el valor de tiempo de espera de reenvío de 3 segundos o menos.

Si no lo hace, los registros de zona de DNS privado se resuelven con direcciones IP públicas.

Aplicaciones web

Supongamos que necesita realizar la resolución de nombres de una aplicación web integrada con App Service y vinculada a una red virtual, a las máquinas virtuales en la misma red virtual. Además de configurar un servidor DNS personalizado que tenga un reenviador DNS que reenvíe las consultas a Azure (dirección IP virtual 168.63.129.16), realice los pasos siguientes:

Habilite la integración de red virtual de la aplicación web, si aún no lo ha hecho, tal y como se describe en Integración de su aplicación con una instancia de Azure Virtual Network.

Si necesita llevar a cabo la resolución de nombres desde una aplicación web vinculada a la red virtual (creada con App Service) en máquinas virtuales de otra red virtual que no está vinculada a la misma zona privada, use servidores DNS personalizados o Azure DNS Private Resolver en las dos redes virtuales.

Para usar servidores DNS personalizados:

  • Configure un servidor DNS en la red virtual de destino en una máquina virtual que también pueda reenviar consultas a la resolución recursiva de Azure (dirección IP virtual 168.63.129.16). Puede encontrar un reenviador DNS de ejemplo disponible en la galería de plantillas de inicio rápido de Azure y en GitHub.

  • Configure un reenviador DNS en la red virtual de origen en una máquina virtual. Configure este reenviador DNS para que reenvíe consultas al servidor DNS de la red virtual de destino.

  • Configure el servidor DNS de origen en la configuración de su red virtual de origen.

  • Habilite la integración de red virtual para la aplicación web para vincular a la red virtual de origen, siguiendo las instrucciones de Integración de su aplicación con una instancia de Azure Virtual Network.

Para usar Azure DNS Private Resolver, consulte Vínculos del conjunto de reglas.

Especificación de los servidores DNS

Si usa sus propios servidores DNS, Azure permite especificar varios servidores DNS por cada red virtual. También puede especificar varios servidores DNS por interfaz de red (para Azure Resource Manager) o por servicio en la nube (para el modelo de implementación clásica). Los servidores DNS especificados para una interfaz de red o un servicio en la nube tienen prioridad sobre los servidores DNS especificados para la red virtual.

Nota:

Las propiedades de conexión de red, como las direcciones IP del servidor DNS, no deben editarse directamente dentro de las máquinas virtuales. Esto se debe a que podrían borrarse durante el servicio de reparación cuando se reemplaza el adaptador de la red virtual. Esto se aplica a las máquinas virtuales Windows y Linux.

Si utiliza el modelo de implementación de Azure Resource Manager, puede especificar servidores DNS para una red virtual y una interfaz de red. Para obtener más información, consulte Administración de una red virtual y Administración de una interfaz de red.

Nota:

Si opta por el servidor DNS personalizado para la red virtual, debe especificar al menos una dirección IP de servidor DNS; en caso contrario, la red virtual omitirá la configuración y usará en su lugar el DNS proporcionado por Azure.

Nota:

Si cambia la configuración de DNS de una máquina o red virtual que ya está implementada, para que la nueva configuración de DNS surta efecto, debe realizar una renovación de la concesión de DHCP en todas las máquinas virtuales afectadas de la red virtual. En el caso de las máquinas virtuales que ejecutan el sistema operativo Windows, puede hacerlo escribiendo ipconfig /renew directamente en la máquina virtual. Los pasos varían en función del sistema operativo. Consulte la documentación correspondiente para su tipo de sistema operativo.

Pasos siguientes

Modelo de implementación de Azure Resource Manager: