iDNS gebruiken in Azure Stack Hub
iDNS is een Azure Stack Hub-netwerkfunctie waarmee u externe DNS-namen kunt omzetten (zo https://www.bing.com.) kunt u ook interne namen van virtuele netwerken registreren. Als u dit doet, kunt u virtuele machines (VM's) in hetzelfde virtuele netwerk op naam omzetten in plaats van ip-adres. Deze methode verwijdert de noodzaak om aangepaste DNS-serververmeldingen op te geven. Zie het Overzicht van Azure DNS voor meer informatie over DNS.
Wat doet iDNS?
Met iDNS in Azure Stack Hub krijgt u 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 in 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 om internetnamen op te lossen (bijvoorbeeld www.bing.com.)
U kunt nog steeds uw eigen DNS gebruiken en aangepaste DNS-servers gebruiken. Met iDNS kunt u echter 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 kan worden omgezet van buiten het virtuele netwerk.
In Azure kunt u een DNS-naamlabel opgeven 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 ) op te stellen die vanaf elke locatie op het openbare internet kan worden omgezet.
Azure Stack Hub biedt alleen ondersteuning voor iDNS voor interne naamregistratie, zodat het niet de volgende dingen kan doen:
- 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 hoe iDNS werkt
Alle hostnamen voor VM's in virtuele netwerken worden opgeslagen als DNS-resourcerecords in dezelfde zone, maar onder hun eigen unieke compartiment gedefinieerd als een GUID die overeenkomt 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-achtervoegseltekenreeks voor de Virtual Network, in GUID-indeling.
Hieronder volgt een eenvoudig lab om te laten zien hoe dit werkt. We hebben drie VM's gemaakt op het ene 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:
Vanuit VM-A1 (Linux-VM): VM-A2 opzoeken. U kunt zien dat het DNS-achtervoegsel voor VNetA is toegevoegd en dat de naam is 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 dat de FQDN 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 (dat 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 zich in een andere zone bevindt.
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 omgezet:
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
Vanaf VM-A3 (Windows VM). Let op het verschil tussen gezaghebbende en niet-gezaghebbende 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 het volgende zien in het bovenstaande:
- Elk VNet heeft een eigen zone, met A-records voor alle privé-IP-adressen, bestaande uit de NAAM van de VIRTUELE machine en het DNS-achtervoegsel van het VNet (dat de GUID is).
- <vmname>.< vnetGUID.internal>.< regio>.< stackinternalFQDN>
- Dit wordt automatisch gedaan
- Als u openbare IP-adressen gebruikt, kunt u er ook DNS-labels voor maken. Deze worden opgelost zoals elk ander extern adres.
- 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 die moeten worden omgezet.
Zoals u kunt zien in de resultaten van het lab, hebt u controle over welk IP-adres wordt gebruikt. Als u de naam van de VIRTUELE machine gebruikt, krijgt u het privé-IP-adres en als u het DNS-label gebruikt, krijgt u het openbare IP-adres.