Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
iDNS es una característica de red de Azure Stack Hub que permite resolver nombres DNS externos (por ejemplo, https://www.bing.com. También permite registrar nombres de red virtual internos. Al hacerlo, puede resolver máquinas virtuales (VM) en la misma red virtual por nombre en lugar de por dirección IP. Este enfoque elimina la necesidad de proporcionar entradas de servidor DNS personalizadas. Para más información sobre DNS, consulte Introducción a Azure DNS.
¿Qué hace iDNS?
Con iDNS en Azure Stack Hub, obtendrá las siguientes funcionalidades, sin tener que especificar entradas de servidor DNS personalizadas:
- Servicios de resolución de nombres DNS compartidos para cargas de trabajo de inquilino.
- Servicio DNS autoritativo para la resolución de nombres y el registro DNS dentro de la red virtual del inquilino.
- Servicio DNS recursivo para la resolución de nombres de Internet de máquinas virtuales de inquilinos. Los inquilinos ya no necesitan especificar entradas DNS personalizadas para resolver nombres de Internet (por ejemplo, www.bing.com).
Todavía puede traer su propio DNS y usar servidores DNS personalizados. Sin embargo, mediante iDNS, puede resolver nombres DNS de Internet y conectarse a otras máquinas virtuales de la misma red virtual sin necesidad de crear entradas DNS personalizadas.
¿Qué no hace iDNS?
iDNS no permite crear un registro DNS para un nombre que se pueda resolver desde fuera de la red virtual.
En Azure, tiene la opción de especificar una etiqueta de nombre DNS asociada a una dirección IP pública. Puede elegir la etiqueta (prefijo), pero Azure elige el sufijo, que se basa en la región en la que se crea la dirección IP pública.
Como se muestra en la imagen anterior, Azure creará un registro "A" en DNS para la etiqueta de nombre DNS especificada en la zona westus.cloudapp.azure.com. El prefijo y el sufijo se combinan para componer un nombre de dominio completo (FQDN) que se puede resolver desde cualquier lugar de la red pública de Internet.
Azure Stack Hub solo admite iDNS para el registro de nombres interno, por lo que no puede hacer lo siguiente:
- Cree un registro DNS en una zona DNS hospedada existente (por ejemplo, local.azurestack.external).
- Cree una zona DNS (por ejemplo, Contoso.com).
- Cree un registro en su propia zona DNS personalizada.
- Admitir la compra de nombres de dominio.
Demostración de cómo funciona iDNS
Todos los nombres de host de las máquinas virtuales de las redes virtuales se almacenan como registros de recursos DNS en la misma zona, pero bajo su propio compartimiento único definido como UN GUID que se correlaciona con el identificador de red virtual en la infraestructura de SDN en la que se implementó la máquina virtual. Los nombres de dominio completos (FQDN) de las máquinas virtuales de los inquilinos se componen del nombre del equipo y de la cadena del sufijo DNS de la red virtual, en formato GUID.
A continuación se muestra un laboratorio sencillo para demostrar cómo funciona esto. Hemos creado 3 máquinas virtuales en una red virtual y otra en una red virtual independiente:
| máquina virtual | Red virtual | Dirección IP privada | Dirección IP pública | Etiqueta DNS |
|---|---|---|---|---|
| VM-A1 | VNetA | 10.0.0.5 | 172.31.12.68 | VM-A1-Label.lnv1.cloudapp.azscss.external |
| VM-A2 | VNetA | 10.0.0.6 | 172.31.12.76 | VM-A2-Label.lnv1.cloudapp.azscss.external |
| VM-A3 | VNetA | 10.0.0.7 | 172.31.12.49 | VM-A3-Label.lnv1.cloudapp.azscss.external |
| VM-B1 | VNetB | 10.0.0.4 | 172.31.12.57 | VM-B1-Label.lnv1.cloudapp.azscss.external |
| Red virtual | Identificador Único Global (GUID) | Cadena de sufijo DNS |
|---|---|---|
| VNetA | e71e1db5-0a38-460d-8539-705457a4cf75 | e71e1db5-0a38-460d-8539-705457a4cf75.internal.lnv1.azurestack.local |
| VNetB | e8a6e386-bc7a-43e1-a640-61591b5c76dd | e8a6e386-bc7a-43e1-a640-61591b5c76dd.internal.lnv1.azurestack.local |
Puede realizar algunas pruebas de resolución de nombres para comprender mejor cómo funciona iDNS:
En VM-A1 (máquina virtual Linux): al buscar VM-A2, puede ver que se agrega el sufijo DNS para VNetA y el nombre se resuelve en la dirección IP privada:
carlos@VM-A1:~$ nslookup VM-A2
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: VM-A2.e71e1db5-0a38-460d-8539-705457a4cf75.internal.lnv1.azurestack.local
Address: 10.0.0.6
La búsqueda de la máquina virtual:A2-Label sin proporcionar el FQDN produce un error, como se esperaba:
carlos@VM-A1:~$ nslookup VM-A2-Label
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find VM-A2-Label: SERVFAIL
Si proporciona el FQDN para la etiqueta DNS, el nombre se resuelve en la dirección IP pública:
carlos@VM-A1:~$ nslookup VM-A2-Label.lnv1.cloudapp.azscss.external
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: VM-A2-Label.lnv1.cloudapp.azscss.external
Address: 172.31.12.76
Al intentar resolver VM-B1 (que procede de una red virtual diferente), se produce un error, ya que este registro no existe en esta zona.
carlos@caalcobi-vm4:~$ nslookup VM-B1
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find VM-B1: SERVFAIL
El uso del FQDN para VM-B1 no ayuda, ya que este registro procede de una zona diferente.
carlos@VM-A1:~$ nslookup VM-B1.e8a6e386-bc7a-43e1-a640-61591b5c76dd.internal.lnv1.azurestack.local
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find VM-B1.e8a6e386-bc7a-43e1-a640-61591b5c76dd.internal.lnv1.azurestack.local: SERVFAIL
Si usa el FQDN para la etiqueta DNS, se resuelve correctamente:
carlos@VM-A1:~$ nslookup VM-B1-Label.lnv1.cloudapp.azscss.external
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: VM-B1-Label.lnv1.cloudapp.azscss.external
Address: 172.31.12.57
Desde VM-A3 (máquina virtual Windows). Observe la diferencia entre las respuestas autoritativas y no autoritativas.
Registros internos:
C:\Users\carlos>nslookup
Default Server: UnKnown
Address: 168.63.129.16
> VM-A2
Server: UnKnown
Address: 168.63.129.16
Name: VM-A2.e71e1db5-0a38-460d-8539-705457ª4cf75.internal.lnv1.azurestack.local
Address: 10.0.0.6
Registros externos:
> VM-A2-Label.lnv1.cloudapp.azscss.external
Server: UnKnown
Address: 168.63.129.16
Non-authoritative answer:
Name: VM-A2-Label.lnv1.cloudapp.azscss.external
Address: 172.31.12.76
En resumen, puede ver desde lo anterior que:
- Cada red virtual tiene su propia zona, que contiene registros A para todas las direcciones IP privadas, que constan del nombre de la máquina virtual y el sufijo DNS de la red virtual (que es su GUID).
- <vmname>.<vnetGUID.internal>.<región>.<stackinternalFQDN>
- Esto se hace automáticamente
- Si usa direcciones IP públicas, también puede crear etiquetas DNS para ellas. Se resuelven como cualquier otra dirección externa.
- Los servidores de iDNS son los servidores autoritativos de sus zonas DNS internas y también actúan como una resolución de nombres públicos cuando las máquinas virtuales de los inquilinos intentan conectarse a recursos externos. Si hay una consulta para un recurso externo, los servidores iDNS reenvía la solicitud a los servidores DNS autoritativos para resolver.
Como puede ver en los resultados del laboratorio, tiene control sobre qué dirección IP se usa. Si usa el nombre de la máquina virtual, obtendrá la dirección IP privada y, si usa la etiqueta DNS, obtendrá la dirección IP pública.