Dela via


Använda iDNS i Azure Stack Hub

iDNS är en Azure Stack Hub-nätverksfunktion som gör att du kan matcha externa DNS-namn (till exempel https://www.bing.com.) Kan du också registrera interna namn på virtuella nätverk. På så sätt kan du matcha virtuella datorer (VM) i samma virtuella nätverk efter namn i stället för IP-adress. Den här metoden tar bort behovet av att ange anpassade DNS-serverposter. Mer information om DNS finns i Översikt över Azure DNS.

Vad gör iDNS?

Med iDNS i Azure Stack Hub får du följande funktioner utan att behöva ange anpassade DNS-serverposter:

  • Delade DNS-namnmatchningstjänster för klientarbetsbelastningar.
  • Auktoritativ DNS-tjänst för namnmatchning och DNS-registrering i det virtuella klientnätverket.
  • Rekursiv DNS-tjänst för matchning av Internetnamn från virtuella klientdatorer. Klienter behöver inte längre ange anpassade DNS-poster för att matcha Internetnamn (till exempel www.bing.com.)

Du kan fortfarande använda din egen DNS och använda anpassade DNS-servrar. Men genom att använda iDNS kan du matcha INTERNET-DNS-namn och ansluta till andra virtuella datorer i samma virtuella nätverk utan att behöva skapa anpassade DNS-poster.

Vad gör inte iDNS?

Med iDNS kan du inte skapa en DNS-post för ett namn som kan matchas utanför det virtuella nätverket.

I Azure kan du välja att ange en DNS-namnetikett som är associerad med en offentlig IP-adress. Du kan välja etiketten (prefixet), men Azure väljer suffixet, som baseras på den region där du skapar den offentliga IP-adressen.

Exempel på en DNS-namnetikett

Som föregående bild visar skapar Azure en "A"-post i DNS för DNS-namnetiketten som anges under zonen westus.cloudapp.azure.com. Prefixet och suffixet kombineras för att skapa ett fullständigt kvalificerat domännamn (FQDN) som kan matchas var som helst på det offentliga Internet.

Azure Stack Hub stöder endast iDNS för intern namnregistrering, så det kan inte göra följande:

  • Skapa en DNS-post under en befintlig värdbaserad DNS-zon (till exempel local.azurestack.external.)
  • Skapa en DNS-zon (till exempel Contoso.com.)
  • Skapa en post under din egen anpassade DNS-zon.
  • Stöd för köp av domännamn.

Demo av hur iDNS fungerar

Alla värdnamn för virtuella datorer på virtuella nätverk lagras som DNS-resursposter under samma zon, men under sitt eget unika fack definieras som ett GUID som korrelerar med det virtuella nätverks-ID:t i SDN-infrastrukturen som den virtuella datorn distribuerades mot. Den virtuella klientdatorns fullständigt kvalificerade domännamn (FQDN) består av datornamnet och DNS-suffixsträngen för Virtual Network, i GUID-format.

Följande är ett enkelt labb som visar hur detta fungerar. Vi har skapat tre virtuella datorer på ett virtuellt nätverk och en annan virtuell dator i ett separat virtuellt nätverk:

Virtuell dator vNet Privat IP Offentlig IP-adress DNS-etikett
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
Virtuellt nätverk GUID DNS-suffixsträng
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

Du kan göra några namnmatchningstester för att bättre förstå hur iDNS fungerar:

Från VM-A1 (virtuell Linux-dator): Leta upp VM-A2. Du kan se att DNS-suffixet för VNetA har lagts till och att namnet matchas till den privata IP-adressen:

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

Att leta upp VM-A2-Label utan att ange FQDN misslyckas som förväntat:

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

Om du anger FQDN för DNS-etiketten matchas namnet till den offentliga IP-adressen:

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

Det går inte att lösa VM-B1 (som kommer från ett annat virtuellt nätverk) eftersom den här posten inte finns i den här zonen.

carlos@caalcobi-vm4:~$ nslookup VM-B1
Server:         127.0.0.53
Address:        127.0.0.53#53
 
** server can't find VM-B1: SERVFAIL

Det hjälper inte att använda FQDN för VM-B1 eftersom den här posten kommer från en annan zon.

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

Om du använder FQDN för DNS-etiketten matchar det:

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

Från VM-A3 (Windows VM). Observera skillnaden mellan auktoritativa och icke-auktoritativa svar.

Interna poster:

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

Externa poster:

> 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

Kort och kort kan du se från ovanstående att:

  • Varje virtuellt nätverk har en egen zon som innehåller A-poster för alla privata IP-adresser, som består av vm-namn och DNS-suffixet för det virtuella nätverket (som är dess GUID).
    • <vmname>.<vnetGUID.internal>.<region>.<stackinternalFQDN>
    • Detta görs automatiskt
  • Om du använder offentliga IP-adresser kan du också skapa DNS-etiketter för dem. Dessa matchas på samma sätt som andra externa adresser.
  • iDNS-servrar är auktoritativa servrar för sina interna DNS-zoner och fungerar även som en matchare för offentliga namn när virtuella klientdatorer försöker ansluta till externa resurser. Om det finns en fråga för en extern resurs vidarebefordrar iDNS-servrar begäran till auktoritativa DNS-servrar som ska matchas.

Som du ser i labbresultaten har du kontroll över vilken IP-adress som används. Om du använder namnet på den virtuella datorn får du den privata IP-adressen och om du använder DNS-etiketten får du den offentliga IP-adressen.

Nästa steg

Använda DNS i Azure Stack Hub