iDNS gebruiken in Azure Stack Hub
iDNS is een Azure Stack Hub-netwerkfunctie waarmee u externe DNS-namen kunt omzetten (bijvoorbeeld, https://www.bing.com.) hiermee kunt u ook namen van interne virtuele netwerken registreren. Hiermee kunt u virtuele machines (VM's) in hetzelfde virtuele netwerk oplossen op naam in plaats van IP-adres. Met deze aanpak hoeft u geen aangepaste DNS-serververmeldingen op te geven. Zie overzicht van Azure DNS voor meer informatie over DNS.
Wat doet iDNS?
Met iDNS in Azure Stack Hub beschikt u over de volgende mogelijkheden, zonder dat u aangepaste DNS-serververmeldingen hoeft op te geven:
- Gedeelde DNS-naamomzettingsservices voor tenantworkloads.
- Gezaghebbende DNS-service voor naamomzetting en DNS-registratie binnen het virtuele tenantnetwerk.
- Recursieve DNS-service voor het omzetten van internetnamen van tenant-VM's. Tenants hoeven geen aangepaste DNS-vermeldingen meer op te geven voor het omzetten van internetnamen (bijvoorbeeld www.bing.com.)
U kunt nog steeds uw eigen DNS gebruiken en aangepaste DNS-servers gebruiken. Met behulp van iDNS kunt u internet-DNS-namen omzetten en verbinding maken met andere VM's in hetzelfde virtuele netwerk zonder dat u aangepaste DNS-vermeldingen hoeft te maken.
Wat doet iDNS niet?
Met iDNS kunt u geen DNS-record maken voor een naam die van buiten het virtuele netwerk kan worden omgezet.
In Azure hebt u de mogelijkheid om een DNS-naamlabel op te geven dat is gekoppeld aan een openbaar IP-adres. U kunt het label (voorvoegsel) kiezen, maar Azure kiest het achtervoegsel, dat is gebaseerd op de regio waarin u het openbare IP-adres maakt.
Zoals in de vorige afbeelding wordt weergegeven, maakt Azure een A-record in DNS voor het DNS-naamlabel dat is opgegeven onder de zone westus.cloudapp.azure.com. Het voorvoegsel en het achtervoegsel worden gecombineerd om een FQDN ( Fully Qualified Domain Name ) samen te stellen die overal op het openbare internet kan worden omgezet.
Azure Stack Hub biedt alleen ondersteuning voor iDNS voor interne naamregistratie, dus de volgende dingen kunnen niet worden uitgevoerd:
- Maak een DNS-record onder een bestaande gehoste DNS-zone (bijvoorbeeld local.azurestack.external).)
- Maak een DNS-zone (zoals Contoso.com.)
- Maak een record onder uw eigen aangepaste DNS-zone.
- Ondersteuning voor de aankoop van domeinnamen.
Demo van de werking van iDNS
Alle hostnamen voor virtuele machines in virtuele netwerken worden opgeslagen als DNS-resourcerecords in dezelfde zone, maar in hun eigen unieke compartiment dat is gedefinieerd als een GUID die correleert met de VNET-id in de SDN-infrastructuur waarop de VM is geïmplementeerd. FQDN's (Fully Qualified Domain Names) van tenant-VM's bestaan uit de computernaam en de DNS-achtervoegselreeks voor de Virtual Network, in GUID-indeling.
Hieronder volgt een eenvoudig lab om te laten zien hoe dit werkt. We hebben 3 VM's gemaakt op één VNet en een andere VM op een afzonderlijk VNet:
| VM | vNet | Privé IP-adres | Openbare IP | DNS-label |
|---|---|---|---|---|
| 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 |
| VNet | GUID | DNS-achtervoegseltekenreeks |
|---|---|---|
| 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 |
U kunt enkele naamomzettingstests uitvoeren om beter te begrijpen hoe iDNS werkt:
Van VM-A1 (Linux-VM): VM-A2 opzoeken. U ziet dat het DNS-achtervoegsel voor VNetA is toegevoegd en dat de naam wordt omgezet in het privé-IP-adres:
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
Het opzoeken van VM-A2-Label zonder de FQDN op te geven mislukt, zoals verwacht:
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
Als u de FQDN voor het DNS-label opgeeft, wordt de naam omgezet in het openbare IP-adres:
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
Het oplossen van VM-B1 (die afkomstig is van een ander VNet) mislukt omdat deze record niet bestaat in deze 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
Het gebruik van de FQDN voor VM-B1 helpt niet, omdat deze record afkomstig is uit een andere 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
Als u de FQDN voor het DNS-label gebruikt, wordt het probleem opgelost:
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
Van VM-A3 (Windows-VM). Let op het verschil tussen gezaghebbende en niet-bindende antwoorden.
Interne records:
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
Externe records:
> 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
Kortom, u kunt aan het bovenstaande zien dat:
- Elk VNet heeft een eigen zone, met A-records voor alle privé-IP-adressen, bestaande uit de VM-naam en het DNS-achtervoegsel van het VNet (wat de GUID is).
- <vmname>.<vnetGUID.internal>.<regio>.<stackinternalFQDN>
- Dit wordt automatisch uitgevoerd
- Als u openbare IP-adressen gebruikt, kunt u er ook DNS-labels voor maken. Deze worden net als elk ander extern adres omgezet.
- iDNS-servers zijn de gezaghebbende servers voor hun interne DNS-zones en fungeren ook als een resolver voor openbare namen wanneer tenant-VM's verbinding proberen te maken met externe resources. Als er een query voor een externe resource is, sturen iDNS-servers de aanvraag door naar gezaghebbende DNS-servers om deze op te lossen.
Zoals u kunt zien in de labresultaten, hebt u controle over welk IP-adres wordt gebruikt. Als u de vm-naam gebruikt, krijgt u het privé-IP-adres en als u het DNS-label gebruikt, krijgt u het openbare IP-adres.