Compartir a través de

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

  • Artículo

Puede usar Azure para hospedar soluciones de infraestructura como servicio (IaaS), plataforma como servicio (PaaS) e híbridas. Para facilitar la comunicación entre las máquinas virtuales (VM) y otros recursos implementados en una red virtual, es posible que sea 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 nombres correspondientes.

Las zonas de DNS privado de Azure son la solución preferida y le proporcionan flexibilidad para la administración de los registros y las zonas DNS. Para más información, consulte 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 bien 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 de DNS privado de Azure 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 de DNS privado de Azure, 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 desde una instancia 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 desde instancias de App Service Web Apps de una máquina virtual a 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 resolverlas. Consulte Resolución de nombres mediante su propio servidor DNS. Solo FQDN
DNS inverso para direcciones IP internas. Zonas de DNS privado de Azure, resolución de nombres proporcionada por Azure, Azure DNS Private Resolver o resolución de nombres mediante un servidor DNS propio. 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 las redes virtuales, puede usar zonas de DNS privado de Azure con servidores DNS administrados por el cliente o 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 es suficiente con el nombre de host. Pero en las redes virtuales implementadas con el modelo de implementación clásica, cada servicio en la nube tiene 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. Puede asignar nombres DNS 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 adecuada para todos los escenarios de implementación, como se ha descrito en la tabla anterior.

Nota:

Al usar roles web y de trabajo de Azure Cloud Services, también puede acceder a las direcciones IP internas de las instancias de rol mediante la API REST de Administración de servicios de Azure. Para más información, vea 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:

  • No es necesario configurar nada.
  • No es necesario crear ni administrar clústeres de servidores DNS propios debido a la alta disponibilidad.
  • Puede utilizar el servicio junto con servidores DNS propios 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 Resource Manager, sin necesidad de un nombre de dominio completo. En el modelo de implementación clásica, las redes virtuales necesitan 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

Al usar la resolución de nombres proporcionada por Azure, tenga en cuenta los siguientes puntos:

  • 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 se permite el registro manual de registros propios.
  • 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 deben usar solo caracteres del 0 a 9, de la a a la z y un guión (-). Los nombres no pueden comenzar ni terminar con guiones.
  • 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.
  • Se debe usar un nombre diferente para cada máquina virtual de una red virtual a fin de 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 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 DNS inverso

Se admite DNS inverso para las máquinas virtuales en todas las redes virtuales basadas en Resource Manager. Los registros con formato \[vmname\].internal.cloudapp.net de DNS inverso administrado por Azure, también conocidos como punteros (PTR), se agregan automáticamente al DNS al iniciar una máquina virtual. Se quitan cuando se detiene la máquina virtual (se 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 \[vmname\].internal.cloudapp.net se resuelve en la dirección IP asignada a la máquina virtual.

Si una zona de DNS privado de Azure 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 \[vmname\].[privatednszonename] y el otro el formato \[vmname\].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 se ha mostrado antes, la búsqueda directa de cualquier FQDN devuelve la dirección IP de la máquina virtual.

Las búsquedas de DNS inverso tienen el ámbito de una red virtual concreta, 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.

Los registros (PTR) de DNS inverso 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 de DNS inverso predeterminada asociada a una red virtual no se puede ver ni editar.

Puede deshabilitar la función de DNS inverso en una red virtual. Cree una zona de búsqueda inversa propia mediante zonas de DNS privado de Azure. Después, 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 quiera 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 las restricciones que permiten que solo se vincule una zona privada si el registro automático está habilitado. Para obtener información sobre cómo crear una zona DNS privada y vincularla a una red virtual, vea el inicio rápido de DNS privado de Azure.

Nota:

Como las zonas privadas de Azure DNS son globales, puede crear una búsqueda de DNS inversa que abarque varias redes virtuales. Debe crear una zona de DNS privado de Azure para búsquedas inversas (una zona in-addr.arpa) y después vincularla a las redes virtuales. Debe 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 lado cliente ayuda a reducir la latencia y mejorar la resistencia a la señalización visual de la red mediante la resolución de las consultas DNS periódicas desde una caché local. Los registros DNS contienen un mecanismo para contabilizar el período de vida, lo que permite a la caché almacenar el registro el máximo tiempo posible sin afectar a la actualización de los registros. El almacenamiento en caché del lado 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 es solo una de las muchas cachés de DNS disponibles para Linux. Antes de usarlo, compruebe su idoneidad para la necesidades concretas y que no haya instalada ninguna otra caché.

Reintentos del cliente

DNS es principalmente un protocolo de datagramas de usuario (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. Examine la línea options, por ejemplo:

options timeout:1 attempts:5

El archivo resolv.conf se genera de forma automática 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 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. La sección siguiente se proporciona si quiere usar una solución DNS basada en máquinas virtuales. Entre las muchas ventajas de usar Azure DNS Private Resolver se incluyen 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 Windows Server Active Directory para resolver nombres DNS entre redes virtuales. Para abarcar estos escenarios, puede usar servidores DNS propios.

Los servidores DNS dentro de una red virtual pueden reenviar consultas DNS a las resoluciones recursivas en Azure. Mediante este procedimiento, puede 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 Azure VPN Gateway se usa en esta configuración junto con la dirección IP del servidor DNS personalizado en una red virtual, la dirección IP de Azure DNS (168.63.129.16) se debe agregar 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 las máquinas locales resuelvan nombres de host proporcionados por Azure. Para resolver el nombre de host de una VM, la VM 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.

Dos redes virtuales y una red local usan este método para la resolución DNS entre redes virtuales, como se muestra en el diagrama siguiente. 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. Usa el FQDN, que consta del nombre de host de la máquina virtual y del sufijo de DNS internal.cloudapp.net. 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 mediante el sufijo internal.cloudapp.net) tienen que usar el método descrito en esta sección (reenvío de servidores DNS personalizados entre las dos redes virtuales).

Diagrama en el que se muestra el 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 nombre de host, ya que los registros de nombre de host están en la zona internal.cloudapp.net. Si utiliza una solución propia de resolución de nombres, este sufijo no se proporciona a las máquinas virtuales, ya que interfiere con otras arquitecturas de DNS (como en 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, puede determinar el sufijo DNS interno con PowerShell o la API.

En el caso de redes virtuales en modelos de implementación de Resource Manager, el sufijo está disponible desde la API REST de interfaz de red, el cmdlet Get-AzNetworkInterface de PowerShell y del comando az network nic show de la CLI de Azure.

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

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

  • Proporcione la resolución adecuada de nombres de host, por ejemplo, mediante DNS dinámico (DDNS). Si usa DDNS, puede necesitar deshabilitar la limpieza de registros DNS. Las concesiones DHCP de Azure son 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.
  • Protéjase contra el acceso desde Internet para mitigar las amenazas que suponen los agentes externos.

Para obtener un rendimiento óptimo, cuando use máquinas virtuales de Azure como servidores DNS, debe deshabilitar IPv6.

Los grupos de seguridad de red (NSG) actúan como firewalls para los puntos de conexión del solucionador del Sistema de nombres de dominio. Modifique o invalide 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 cliente de escucha DNS. Una vez que los servidores DNS personalizados se establecen en una red, el tráfico por el puerto 53 omite los NSG de la subred.

Importante

Si usa servidores DNS de Windows como servidores DNS personalizados que reenvían solicitudes DNS a servidores de Azure DNS, asegúrese de aumentar el valor de tiempo de espera de reenvío más de cuatro segundos para permitir que los servidores DNS recursivos de Azure realicen las 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.

Es posible que esta recomendación también se aplique a otras plataformas del servidor DNS con valores de tiempo de espera de reenvío de tres segundos o menos.

Si no lo hace, es posible que los registros de zona de DNS privado se resuelvan 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:

  • Si aún no lo ha hecho, habilite la integración de red virtual para la aplicación web, como se describe en Integración de la aplicación con una red virtual.
  • Si tiene que realizar la resolución de nombres desde una aplicación web vinculada a la red virtual (compilada mediante 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 al solucionador recursivo de Azure (la 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 a fin de vincular a la red virtual de origen, siguiendo las instrucciones de Integración de la aplicación con una red virtual.

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

Especificación de los servidores DNS

Cuando use servidores DNS propios, puede especificar varios servidores DNS para cada red virtual. También puede especificar varios servidores DNS para cada interfaz de red (para Resource Manager) o para cada 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 se deben editar directamente dentro de las máquinas virtuales. Es posible que se borren durante el servicio de reparación cuando se reemplaza el adaptador de la red virtual. Esta precaución se aplica a máquinas virtuales Windows y Linux.

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

Si opta por un servidor DNS personalizado para la red virtual, debe especificar al menos una dirección IP del servidor DNS. De lo contrario, la red virtual omite la configuración y, en su lugar, usa 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, escriba 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.

Contenido relacionado

Modelo de implementación de Azure Resource Manager: