Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
iDNS est une fonctionnalité de mise en réseau Azure Stack Hub qui vous permet de résoudre les noms DNS externes (par exemple, https://www.bing.com.) Il vous permet également d’inscrire des noms de réseau virtuel interne. En procédant ainsi, vous pouvez résoudre les machines virtuelles sur le même réseau virtuel par nom plutôt que par adresse IP. Cette approche supprime la nécessité de fournir des entrées de serveur DNS personnalisées. Pour plus d’informations sur DNS, consultez la vue d’ensemble d’Azure DNS.
Que fait iDNS ?
Avec iDNS dans Azure Stack Hub, vous obtenez les fonctionnalités suivantes, sans avoir à spécifier d’entrées de serveur DNS personnalisées :
- Services de résolution de noms DNS partagés pour les charges de travail de locataire.
- Service DNS faisant autorité pour la résolution de noms et l’inscription DNS au sein du réseau virtuel du locataire.
- Service DNS récursif pour la résolution des noms Internet à partir de machines virtuelles clientes. Les locataires n’ont plus besoin de spécifier des entrées DNS personnalisées pour résoudre les noms Internet (par exemple, www.bing.com.)
Vous pouvez toujours apporter votre propre DNS et utiliser des serveurs DNS personnalisés. Toutefois, à l’aide d’iDNS, vous pouvez résoudre les noms DNS Internet et vous connecter à d’autres machines virtuelles du même réseau virtuel sans avoir à créer d’entrées DNS personnalisées.
Que ne fait pas iDNS ?
IDNS ne vous permet pas de créer un enregistrement DNS pour un nom pouvant être résolu en dehors du réseau virtuel.
Dans Azure, vous avez la possibilité de spécifier une étiquette de nom DNS associée à une adresse IP publique. Vous pouvez choisir l’étiquette (préfixe), mais Azure choisit le suffixe, qui est basé sur la région dans laquelle vous créez l’adresse IP publique.
Comme l’illustre l’image précédente, Azure crée un enregistrement « A » dans DNS pour l’étiquette de nom DNS spécifiée sous la zone westus.cloudapp.azure.com. Le préfixe et le suffixe sont combinés pour composer un nom de domaine complet (FQDN) qui peut être résolu n’importe où sur l’Internet public.
Azure Stack Hub prend uniquement en charge iDNS pour l’inscription de noms interne. Il ne peut donc pas effectuer les opérations suivantes :
- Créez un enregistrement DNS sous une zone DNS hébergée existante (par exemple, local.azurestack.external.)
- Créez une zone DNS (par exemple, Contoso.com.)
- Créez un enregistrement sous votre propre zone DNS personnalisée.
- Prendre en charge l’achat de noms de domaine.
Démonstration du fonctionnement d’iDNS
Tous les noms d’hôte des machines virtuelles sur les réseaux virtuels sont stockés en tant qu’enregistrements de ressources DNS sous la même zone, mais sous leur propre compartiment unique défini comme GUID qui correspond à l’ID de réseau virtuel dans l’infrastructure SDN sur laquelle la machine virtuelle a été déployée. Les noms de domaine complets (FQDN) des machines virtuelles de locataire comprennent le nom d’ordinateur et la chaîne de suffixe DNS du réseau virtuel, au format GUID.
Voici un laboratoire simple pour montrer comment cela fonctionne. Nous avons créé 3 machines virtuelles sur un réseau virtuel et une autre machine virtuelle sur un réseau virtuel distinct :
| VM | réseau virtuel | IP privée | Adresse IP publique | Étiquette DNS |
|---|---|---|---|---|
| VM-A1 | Réseau virtuel | 10.0.0.5 | 172.31.12.68 | VM-A1-Label.lnv1.cloudapp.azscss.external |
| VM-A2 | Réseau virtuel | 10.0.0.6 | 172.31.12.76 | VM-A2-Label.lnv1.cloudapp.azscss.external |
| VM-A3 | Réseau virtuel | 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 |
| Réseau virtuel | Identifiant Unique Global (GUID) | Chaîne de suffixe DNS |
|---|---|---|
| Réseau virtuel | e71e1db5-0a38-460d-8539-705457a4cf75 | e71e1db5-0a38-460d-8539-705457a4cf75.internal.lnv1.azurestack.local |
| VNetB | e8a6e386-bc7a-43e1-a640-61591b5c76ddd | e8a6e386-bc7a-43e1-a640-61591b5c76dd.internal.lnv1.azurestack.local |
Vous pouvez effectuer des tests de résolution de noms pour mieux comprendre le fonctionnement d’iDNS :
À partir de VM-A1 (machine virtuelle Linux) : recherchez vm-A2, vous pouvez voir que le suffixe DNS pour VNetA est ajouté et que le nom est résolu sur l’adresse IP privée :
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 recherche de la machine virtuelleA2-Label sans fournir le nom de domaine complet échoue, comme prévu :
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 vous fournissez le nom de domaine complet pour l’étiquette DNS, le nom est résolu sur l’adresse IP publique :
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
La tentative de résolution de VM-B1 (qui provient d’un autre réseau virtuel) échoue, car cet enregistrement n’existe pas sur cette zone.
carlos@caalcobi-vm4:~$ nslookup VM-B1
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find VM-B1: SERVFAIL
L’utilisation du nom de domaine complet pour VM-B1 n’aide pas, car cet enregistrement provient d’une autre zone.
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 vous utilisez le nom de domaine complet pour l’étiquette DNS, il se résout correctement :
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
À partir de VM-A3 (machine virtuelle Windows). Notez la différence entre les réponses faisant autorité et non faisant autorité.
Enregistrements internes :
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
Enregistrements externes :
> 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 bref, vous pouvez voir à partir de ce qui précède :
- Chaque réseau virtuel possède sa propre zone, contenant des enregistrements A pour toutes les adresses IP privées, composées du nom de la machine virtuelle et du suffixe DNS du réseau virtuel (qui est son GUID).
- <vmname>.<vnetGUID.internal>.<région>.<stackinternalFQDN>
- Cette opération est effectuée automatiquement
- Si vous utilisez des adresses IP publiques, vous pouvez également créer des étiquettes DNS pour celles-ci. Celles-ci sont résolues comme n’importe quelle autre adresse externe.
- Les serveurs iDNS sont les serveurs faisant autorité pour leurs zones DNS internes. Ils servent également de programme de résolution pour les noms publics quand des machines virtuelles de locataire tentent de se connecter à des ressources externes. S’il existe une requête pour une ressource externe, les serveurs iDNS transfèrent la requête aux serveurs DNS faisant autorité à résoudre.
Comme vous pouvez le voir à partir des résultats du labo, vous avez le contrôle sur l’adresse IP utilisée. Si vous utilisez le nom de la machine virtuelle, vous obtenez l’adresse IP privée et si vous utilisez l’étiquette DNS que vous obtenez l’adresse IP publique.