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

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:

• Zonas privadas de Azure DNS

• Resolución de nombres de Azure

• Resolución de nombres con su propio servidor DNS (que puede reenviar consultas a los servidores DNS proporcionados por Azure)

• Azure DNS Private Resolver

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:

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.

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.

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.

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:

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:

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.

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.

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.

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:

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

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.

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.

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.

Pasos siguientes

Modelo de implementación de Azure Resource Manager:

• Administración de una red virtual

• Administración de una interfaz de red