Dela via

Namnmatchning för resurser i virtuella nätverk i Azure

  • Artikel

Azure kan användas som värd för IaaS-, PaaS- och hybridlösningar. För att underlätta kommunikationen mellan de virtuella datorerna och andra resurser som distribueras i ett virtuellt nätverk kan det vara nödvändigt att låta dem kommunicera med varandra. Användningen av lätt ihågkomna och oförändrade namn förenklar kommunikationsprocessen i stället för att förlita sig på IP-adresser.

När resurser som distribueras i virtuella nätverk behöver matcha domännamn till interna IP-adresser kan de använda någon av fyra metoder:

Vilken typ av namnmatchning du använder beror på hur dina resurser behöver kommunicera med varandra. I följande tabell visas scenarier och motsvarande lösningar för namnmatchning:

Kommentar

Privata Azure DNS-zoner är den bästa lösningen och ger dig flexibilitet när det gäller att hantera dina DNS-zoner och -poster. Mer information finns på sidan om att använda Azure DNS för privata domäner.

Kommentar

Om du använder Azure Provided DNS tillämpas lämpligt DNS-suffix automatiskt på dina virtuella datorer. För alla andra alternativ måste du antingen använda fullständigt kvalificerade domännamn (FQDN) eller manuellt tillämpa lämpligt DNS-suffix på dina virtuella datorer.

Scenario Lösning DNS-suffix
Namnmatchning mellan virtuella datorer som finns i samma virtuella nätverk eller Azure Cloud Services-rollinstanser i samma molntjänst. Privata Azure DNS-zoner eller namnmatchning som tillhandahålls av Azure Värdnamn eller FQDN
Namnmatchning mellan virtuella datorer i olika virtuella nätverk eller rollinstanser i olika molntjänster. Privata Azure DNS-zoner, Azure DNS Private Resolver eller kundhanterade DNS-servrar vidarebefordrar frågor mellan virtuella nätverk för lösning av Azure (DNS-proxy). Se Namnmatchning med din egen DNS-server. Endast FQDN
Namnmatchning från en Azure App Service (webbapp, funktion eller robot) med hjälp av integrering av virtuella nätverk till rollinstanser eller virtuella datorer i samma virtuella nätverk. Azure DNS Private Resolver eller kundhanterade DNS-servrar vidarebefordrar frågor mellan virtuella nätverk för lösning av Azure (DNS-proxy). Se Namnmatchning med din egen DNS-server. Endast FQDN
Namnmatchning från App Service Web Apps till virtuella datorer i samma virtuella nätverk. Azure DNS Private Resolver eller kundhanterade DNS-servrar vidarebefordrar frågor mellan virtuella nätverk för lösning av Azure (DNS-proxy). Se Namnmatchning med din egen DNS-server. Endast FQDN
Namnmatchning från App Service Web Apps i ett virtuellt nätverk till virtuella datorer i ett annat virtuellt nätverk. Azure DNS Private Resolver eller kundhanterade DNS-servrar vidarebefordrar frågor mellan virtuella nätverk för lösning av Azure (DNS-proxy). Se Namnmatchning med din egen DNS-server. Endast FQDN
Lösning av lokala dator- och tjänstnamn från virtuella datorer eller rollinstanser i Azure. Azure DNS Private Resolver eller kundhanterade DNS-servrar (lokal domänkontrollant, lokal skrivskyddad domänkontrollant eller en sekundär DNS-synkronisering med zonöverföringar, till exempel). Se Namnmatchning med din egen DNS-server. Endast FQDN
Lösning av Azure-värdnamn från lokala datorer. Vidarebefordra frågor till en kundhanterad DNS-proxyserver i motsvarande virtuella nätverk, proxyservern vidarebefordrar frågor till Azure för lösning. Se Namnmatchning med din egen DNS-server. Endast FQDN
Omvänd DNS för interna IP-adresser. Privata Azure DNS-zoner, Namnmatchning som tillhandahålls av Azure, Azure DNS Private Resolver eller Namnmatchning med din egen DNS-server. Inte tillämpligt
Namnmatchning mellan virtuella datorer eller rollinstanser som finns i olika molntjänster, inte i ett virtuellt nätverk. Ej tillämpbart. Anslutning mellan virtuella datorer och rollinstanser i olika molntjänster stöds inte utanför ett virtuellt nätverk. Inte tillämpligt

Namnmatchning som tillhandahålls av Azure

Namnmatchning som tillhandahålls av Azure tillhandahåller endast grundläggande auktoritativa DNS-funktioner. Azure hanterar DNS-zonnamn och -poster om du använder DNS som tillhandahålls av Azure. Du kan inte styra DNS-zonnamnen eller livscykeln för DNS-poster. Om du behöver en fullständigt aktuell DNS-lösning för dina virtuella nätverk kan du använda privata Azure DNS-zoner med kundhanterade DNS-servrar eller en privat Lösning för Azure DNS.

Tillsammans med matchning av offentliga DNS-namn tillhandahåller Azure intern namnmatchning för virtuella datorer och rollinstanser som finns i samma virtuella nätverk eller molntjänst. Virtuella datorer och instanser i en molntjänst delar samma DNS-suffix, så enbart värdnamnet räcker. Men i virtuella nätverk som distribueras med den klassiska distributionsmodellen har olika molntjänster olika DNS-suffix. I den här situationen behöver du FQDN för att lösa namn mellan olika molntjänster. I virtuella nätverk som distribueras med hjälp av Azure Resource Manager-distributionsmodellen är DNS-suffixet konsekvent för alla virtuella datorer i ett virtuellt nätverk, så FQDN behövs inte. DNS-namn kan tilldelas till både virtuella datorer och nätverksgränssnitt. Även om namnmatchning som tillhandahålls av Azure inte kräver någon konfiguration är det inte rätt val för alla distributionsscenarier, enligt beskrivningen i föregående tabell.

Kommentar

När du använder webb- och arbetsroller för molntjänster kan du också komma åt de interna IP-adresserna för rollinstanser med hjälp av REST-API:et för Azure Service Management. Mer information finns i REST API-referensen för Service Management. Adressen baseras på rollnamnet och instansnumret.

Funktioner

Namnmatchning som tillhandahålls av Azure innehåller följande funktioner:

  • Användarvänlighet. Ingen konfiguration krävs.

  • Hög tillgänglighet. Du behöver inte skapa och hantera kluster av dina egna DNS-servrar.

  • Du kan använda tjänsten med dina egna DNS-servrar för att lösa både lokala och Azure-värdnamn.

  • Du kan använda namnmatchning mellan virtuella datorer och rollinstanser i samma molntjänst, utan att behöva ett fullständigt domännamn.

  • Du kan använda namnmatchning mellan virtuella datorer i virtuella nätverk som använder Azure Resource Manager-distributionsmodellen utan att behöva ett fullständigt domännamn. Virtuella nätverk i den klassiska distributionsmodellen kräver ett FQDN när du löser namn i olika molntjänster.

  • Du kan använda värdnamn som bäst beskriver dina distributioner i stället för att arbeta med automatiskt genererade namn.

Att tänka på

Saker att tänka på när du använder namnmatchning som tillhandahålls av Azure:

  • Det går inte att ändra DNS-suffixet som skapats av Azure.

  • DNS-sökning är begränsad till ett virtuellt nätverk. DNS-namn som skapats för ett virtuellt nätverk kan inte matchas från andra virtuella nätverk.

  • Du kan inte registrera dina egna poster manuellt.

  • WINS och NetBIOS stöds inte. Du kan inte se dina virtuella datorer i Utforskaren.

  • Värdnamn måste vara DNS-kompatibla. Namn får endast använda 0-9, a-z och "-", och kan inte starta eller sluta med "-".

  • DNS-frågetrafik begränsas för varje virtuell dator. Begränsning bör inte påverka de flesta program. Om begränsning av begäran observeras kontrollerar du att cachelagring på klientsidan är aktiverat. Mer information finns i DNS-klientkonfiguration.

  • Använd ett annat namn för varje virtuell dator i ett virtuellt nätverk för att undvika DNS-matchningsproblem.

  • Endast virtuella datorer i de första 180 molntjänsterna registreras för varje virtuellt nätverk i en klassisk distributionsmodell. Den här gränsen gäller inte för virtuella nätverk i Azure Resource Manager.

  • Ip-adressen för Azure DNS är 168.63.129.16. Den här adressen är en statisk IP-adress och ändras inte.

Omvända DNS-överväganden

Omvänd DNS för virtuella datorer stöds i alla Azure Resource Manager-baserade virtuella nätverk. Azure-hanterade posterna för omvänd DNS (PTR) i formatet [vmname].internal.cloudapp.net läggs automatiskt till i DNS när du startar en virtuell dator och tas bort när den virtuella datorn stoppas (frigörs). Se följande exempel:

C:\>nslookup -type=ptr 10.11.0.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.0.11.10.in-addr.arpa  name = myeastspokevm1.internal.cloudapp.net

Den internal.cloudapp.net omvända DNS-zonen är Azure-hanterad och kan inte visas eller redigeras direkt. Framåtsökning på formulärets fullständiga domännamn [vmname].internal.cloudapp.net matchar ip-adressen som tilldelats den virtuella datorn.

Om en privat Azure DNS-zon är länkad till det virtuella nätverket med en länk för virtuellt nätverk och automatisk registrering är aktiverad på den länken returnerar omvända DNS-frågor två poster. En post är av formatet [vmname].[ privatednszonename] och det andra är av formatet [vmname].internal.cloudapp.net. Se följande exempel:

C:\>nslookup -type=ptr 10.20.2.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.2.20.10.in-addr.arpa  name = mywestvm1.internal.cloudapp.net
4.2.20.10.in-addr.arpa  name = mywestvm1.azure.contoso.com

När två PTR-poster returneras som tidigare, returnerar vidarebefordran av antingen FQDN IP-adressen för den virtuella datorn.

Omvända DNS-sökningar är begränsade till ett visst virtuellt nätverk, även om det är peer-kopplat till andra virtuella nätverk. Omvända DNS-frågor för IP-adresser för virtuella datorer som finns i peer-kopplade virtuella nätverk returnerar NXDOMAIN.

Kommentar

Posterna för omvänd DNS (PTR) lagras inte i en privat DNS-zon. Omvända DNS-poster lagras i en omvänd DNS-zon (in-addr.arpa). Den omvända DNS-standardzonen som är associerad med ett virtuellt nätverk kan inte visas eller redigeras.

Du kan inaktivera den omvända DNS-funktionen i ett virtuellt nätverk genom att skapa en egen zon för omvänd sökning med hjälp av privata Azure DNS-zoner och sedan länka den här zonen till ditt virtuella nätverk. Om IP-adressutrymmet för det virtuella nätverket till exempel är 10.20.0.0/16 kan du skapa en tom privat DNS-zon 20.10.in-addr.arpa och länka den till det virtuella nätverket. Den här zonen åsidosätter standardzonerna för omvänd sökning för det virtuella nätverket. Den här zonen är tom. Omvänd DNS returnerar NXDOMAIN om du inte skapar dessa poster manuellt.

Automatisk registrering av PTR-poster stöds inte. Om du vill skapa poster anger du dem manuellt. Du måste inaktivera automatisk registrering i det virtuella nätverket om det är aktiverat för andra zoner. Den här begränsningen beror på begränsningar som tillåter att endast en privat zon länkas om automatisk registrering är aktiverad. Mer information om hur du skapar en privat DNS-zon och länkar den till ett virtuellt nätverk finns i snabbstartsguiden för privat DNS.

Kommentar

Eftersom privata Azure DNS-zoner är globala kan du skapa en omvänd DNS-sökning som sträcker sig över flera virtuella nätverk. Det gör du genom att skapa en privat Azure DNS-zon för omvända sökningar (en in-addr.arpa-zon ) och länka den till de virtuella nätverken. Du måste hantera omvända DNS-poster manuellt för de virtuella datorerna.

DNS-klientkonfiguration

Det här avsnittet beskriver cachelagring på klientsidan och återförsök på klientsidan.

Cachelagring på klientsidan

Alla DNS-frågor behöver inte skickas över nätverket. Cachelagring på klientsidan hjälper till att minska svarstiden och förbättra motståndskraften mot nätverksblips genom att lösa återkommande DNS-frågor från en lokal cache. DNS-poster innehåller en TTL-mekanism (time-to-live), som gör att cacheminnet kan lagra posten så länge som möjligt utan att påverka postens färskhet. Cachelagring på klientsidan är därför lämplig för de flesta situationer.

Standardklienten för Windows DNS har en inbyggd DNS-cache. Vissa Linux-distributioner inkluderar inte cachelagring som standard. Om du upptäcker att det inte redan finns en lokal cache lägger du till en DNS-cache i varje virtuell Linux-dator.

Det finns många olika DNS-cachelagringspaket tillgängliga (till exempel dnsmasq). Så här installerar du dnsmasq på de vanligaste distributionerna:

RHEL (använder NetworkManager):

  1. Installera dnsmasq-paketet med följande kommando:

    sudo yum install dnsmasq

  2. Aktivera dnsmasq-tjänsten med följande kommando:

    systemctl enable dnsmasq.service

  3. Starta dnsmasq-tjänsten med följande kommando:

    systemctl start dnsmasq.service

  4. Använd en textredigerare för att lägga prepend domain-name-servers 127.0.0.1; till i /etc/dhclient-eth0.conf:

  5. Använd följande kommando för att starta om nätverkstjänsten:

    service network restart

Kommentar

Dnsmasq-paketet är bara en av många DNS-cacheminnen som är tillgängliga för Linux. Innan du använder den kontrollerar du dess lämplighet för dina specifika behov och kontrollerar att ingen annan cache är installerad.

Återförsök på klientsidan

DNS är främst ett UDP-protokoll. Eftersom UDP-protokollet inte garanterar meddelandeleverans hanteras logik för återförsök i själva DNS-protokollet. Varje DNS-klient (operativsystem) kan uppvisa olika logik för återförsök, beroende på skaparens önskemål:

  • Windows-operativsystem försöker igen efter en sekund och sedan igen efter ytterligare två sekunder, fyra sekunder och ytterligare fyra sekunder.
  • Standardinställningen för Linux försöker igen efter fem sekunder. Vi rekommenderar att du ändrar specifikationerna för återförsök till fem gånger med en sekunds intervall.

Kontrollera de aktuella inställningarna på en virtuell Linux-dator med cat /etc/resolv.conf. Titta på alternativraden, till exempel:

options timeout:1 attempts:5

Filen resolve.conf genereras automatiskt och bör inte redigeras. De specifika stegen för att lägga till alternativraden varierar beroende på distribution:

RHEL (använder NetworkManager):

  1. Använd en textredigerare för att lägga till raden RES_OPTIONS="options timeout:1 attempts:5" i filen /etc/sysconfig/network-scripts/ifcfg-eth0.

  2. Använd följande kommando för att starta om NetworkManager-tjänsten:

    systemctl restart NetworkManager.service

Namnmatchning som använder din egen DNS-server

Det här avsnittet beskriver virtuella datorer, rollinstanser och webbappar.

Kommentar

Azure DNS Private Resolver ersätter behovet av att använda VM-baserade DNS-servrar i ett virtuellt nätverk. Följande avsnitt tillhandahålls om du vill använda en VM-baserad DNS-lösning, men det finns många fördelar med att använda Azure DNS Private Resolver, inklusive kostnadsminskning, inbyggd hög tillgänglighet, skalbarhet och flexibilitet.

Virtuella datorer och rollinstanser

Namnmatchningsbehoven kan gå utöver de funktioner som tillhandahålls av Azure. Du kan till exempel behöva använda Microsoft Windows Server Active Directory-domäner för att matcha DNS-namn mellan virtuella nätverk. För att täcka dessa scenarier kan du använda dina egna DNS-servrar i Azure.

DNS-servrar i ett virtuellt nätverk kan vidarebefordra DNS-frågor till rekursiva matchare i Azure. Med den här proceduren kan du matcha värdnamn i det virtuella nätverket. En domänkontrollant (DC) som körs i Azure kan till exempel svara på DNS-frågor för sina domäner och vidarebefordra alla andra frågor till Azure. Med vidarebefordran av frågor kan virtuella datorer se både dina lokala resurser (via domänkontrollanten) och Värdnamn som tillhandahålls av Azure (via vidarebefordraren). Åtkomst till de rekursiva matcharna i Azure tillhandahålls vid den virtuella IP-adressen 168.63.129.16.

Viktigt!

Om VPN Gateway används i den här konfigurationen tillsammans med anpassade DNS Server-IP-adresser på det virtuella nätverket måste Även Azure DNS IP (168.63.129.16) läggas till i listan för att upprätthålla en oupptäckt tjänst.

DNS-vidarebefordran möjliggör även DNS-matchning mellan virtuella nätverk och gör att dina lokala datorer kan matcha värdnamn som tillhandahålls av Azure. För att kunna matcha en virtuell dators värdnamn måste den virtuella DNS-servern finnas i samma virtuella nätverk och konfigureras för att vidarebefordra värdnamnsfrågor till Azure. Eftersom DNS-suffixet skiljer sig åt i varje virtuellt nätverk kan du använda regler för villkorlig vidarebefordran för att skicka DNS-frågor till rätt virtuellt nätverk för lösning. Följande bild visar två virtuella nätverk och ett lokalt nätverk som utför DNS-matchning mellan virtuella nätverk med hjälp av den här metoden. Ett exempel på DNS-vidarebefordrare finns i galleriet Azure Snabbstartsmallar och GitHub.

Kommentar

En rollinstans kan utföra namnmatchning av virtuella datorer i samma virtuella nätverk. Det gör det med hjälp av FQDN, som består av den virtuella datorns värdnamn och internal.cloudapp.net DNS-suffix. I det här fallet lyckas dock namnmatchningen bara om rollinstansen har det VM-namn som definierats i rollschemat (.cscfg-filen). <Role name="<role-name>" vmName="<vm-name>">

Rollinstanser som behöver utföra namnmatchning av virtuella datorer i ett annat virtuellt nätverk (FQDN med hjälp av internal.cloudapp.net suffixet) måste göra det med hjälp av den metod som beskrivs i det här avsnittet (anpassad DNS-servrar vidarebefordran mellan de två virtuella nätverken).

Diagram över DNS mellan virtuella nätverk

När du använder Namnmatchning som tillhandahålls av Azure tillhandahåller Azure Dynamic Host Configuration Protocol (DHCP) ett internt DNS-suffix (.internal.cloudapp.net) till varje virtuell dator. Det här suffixet aktiverar värdnamnsmatchning eftersom värdnamnsposterna finns i internal.cloudapp.net-zonen. När du använder en lösning för egen namnmatchning tillhandahålls inte det här suffixet till virtuella datorer eftersom det stör andra DNS-arkitekturer (till exempel domänanslutna scenarier). I stället tillhandahåller Azure en icke-fungerande platshållare (reddog.microsoft.com).

Om det behövs kan du fastställa det interna DNS-suffixet med hjälp av PowerShell eller API:et:

Om vidarebefordran av frågor till Azure inte passar dina behov anger du en egen DNS-lösning eller distribuerar en privat Lösning för Azure DNS.

Om du tillhandahåller en egen DNS-lösning måste den:

  • Ange lämplig värdnamnsmatchning, till exempel via DDNS. Om du använder DDNS kan du behöva inaktivera rensning av DNS-poster. Azure DHCP-lån är långa och rensning kan ta bort DNS-poster i förtid.

  • Ange lämplig rekursiv lösning för att tillåta lösning av externa domännamn.

  • Vara tillgänglig (TCP och UDP på port 53) från de klienter som den betjänar och kunna komma åt Internet.

  • Skyddas mot åtkomst från Internet för att minimera hot från externa agenter.

Kommentar

  • För bästa prestanda bör IPv6 inaktiveras när du använder virtuella Azure-datorer som DNS-servrar.
  • NSG:er fungerar som brandväggar för dina DNS-matchningsslutpunkter. Du bör ändra eller åsidosätta dina NSG-säkerhetsregler för att tillåta åtkomst för UDP-port 53 (och eventuellt TCP-port 53) till dns-lyssnarens slutpunkter. När anpassade DNS-servrar har angetts i ett nätverk kringgår trafiken via port 53 NSG:erna för undernätet.

Viktigt!

Om du använder Windows DNS-servrar som anpassade DNS-servrar som vidarebefordrar DNS-begäranden till Azure DNS-servrar ska du öka tidsgränsvärdet för vidarebefordran mer än 4 sekunder så att Azure Rekursiva DNS-servrar kan utföra korrekta rekursionsåtgärder.

Mer information om det här problemet finns i Timeouter för vidarebefordrare och villkorliga vidarebefordrare.

Den här rekommendationen kan också gälla för andra DNS Server-plattformar med timeoutvärdet för vidarebefordran på 3 sekunder eller mindre.

Om du inte gör det kan det leda till att privata DNS-zonposter löses med offentliga IP-adresser.

Webbappar

Anta att du behöver utföra namnmatchning från din webbapp som skapats med hjälp av App Service, som är länkad till ett virtuellt nätverk, till virtuella datorer i samma virtuella nätverk. Förutom att konfigurera en anpassad DNS-server som har en DNS-vidarebefordrare som vidarebefordrar frågor till Azure (virtuell IP 168.63.129.16) utför du följande steg:

Aktivera integrering av virtuella nätverk för webbappen, om den inte redan är klar, enligt beskrivningen i Integrera din app med ett virtuellt nätverk.

Om du behöver utföra namnmatchning från din vnet-länkade webbapp (skapad med App Service) till virtuella datorer i ett annat virtuellt nätverk som inte är länkat till samma privata zon använder du anpassade DNS-servrar eller privata Azure DNS-matchare på båda virtuella nätverken.

Så här använder du anpassade DNS-servrar:

  • Konfigurera en DNS-server i ditt virtuella målnätverk på en virtuell dator som också kan vidarebefordra frågor till den rekursiva matcharen i Azure (virtuell IP 168.63.129.16). Ett exempel på DNS-vidarebefordrare finns i galleriet Azure Snabbstartsmallar och GitHub.

  • Konfigurera en DNS-vidarebefordrare i det virtuella källnätverket på en virtuell dator. Konfigurera dns-vidarebefordraren för att vidarebefordra frågor till DNS-servern i ditt virtuella målnätverk.

  • Konfigurera käll-DNS-servern i inställningarna för det virtuella källnätverket.

  • Aktivera integrering av virtuella nätverk för webbappen för att länka till det virtuella källnätverket genom att följa anvisningarna i Integrera din app med ett virtuellt nätverk.

Information om hur du använder en privat Lösning för Azure DNS finns i Regeluppsättningslänkar.

Ange DNS-servrar

När du använder dina egna DNS-servrar kan du i Azure ange flera DNS-servrar per virtuellt nätverk. Du kan också ange flera DNS-servrar per nätverksgränssnitt (för Azure Resource Manager) eller per molntjänst (för den klassiska distributionsmodellen). DNS-servrar som anges för ett nätverksgränssnitt eller en molntjänst får företräde framför DE DNS-servrar som angetts för det virtuella nätverket.

Kommentar

Nätverksanslutningsegenskaper, till exempel DNS-server-IP-adresser, bör inte redigeras direkt i virtuella datorer. Det beror på att de kan raderas under tjänstens återställning när den virtuella nätverksadaptern ersätts. Detta gäller både virtuella Windows- och Linux-datorer.

När du använder Azure Resource Manager-distributionsmodellen kan du ange DNS-servrar för ett virtuellt nätverk och ett nätverksgränssnitt. Mer information finns i Hantera ett virtuellt nätverk och Hantera ett nätverksgränssnitt.

Kommentar

Om du väljer anpassad DNS-server för ditt virtuella nätverk måste du ange minst en DNS-server-IP-adress. Annars ignorerar det virtuella nätverket konfigurationen och använder Azure-tillhandahållen DNS i stället.

Kommentar

Om du ändrar DNS-inställningarna för ett virtuellt nätverk eller en virtuell dator som redan har distribuerats måste du utföra en förnyelse av DHCP-lån på alla berörda virtuella datorer i det virtuella nätverket för att de nya DNS-inställningarna ska börja gälla. För virtuella datorer som kör Windows-operativsystemet kan du göra detta genom att ipconfig /renew skriva direkt i den virtuella datorn. Stegen varierar beroende på operativsystemet. Se relevant dokumentation för din operativsystemtyp.

Nästa steg

Distributionsmodell för Azure Resource Manager: