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

Beroende på hur du använder Azure som värd för IaaS-, PaaS- och hybridlösningar kan du behöva tillåta att de virtuella datorerna och andra resurser som distribueras i ett virtuellt nätverk kommunicerar med varandra. Även om du kan aktivera kommunikation med hjälp av IP-adresser är det mycket enklare att använda namn som enkelt kan kommas ihåg och inte ändras.

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 tre 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:

Anteckning

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

Anteckning

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 eller kundhanterade DNS-servrar som 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. 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. 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. 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. 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 eller Namnmatchning som tillhandahålls av Azure 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. Inte tillämpligt. 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 ger endast grundläggande auktoritativa DNS-funktioner. Om du använder det här alternativet hanteras DNS-zonnamnen och posterna automatiskt av Azure och du kommer inte att kunna 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 måste du använda privata Azure DNS-zoner eller kundhanterade DNS-servrar.

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 matcha namn mellan olika molntjänster. I virtuella nätverk som distribueras med hjälp av Azure Resource Manager-distributionsmodellen är DNS-suffixet konsekvent på 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, som beskrivs i föregående tabell.

Anteckning

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 tillsammans 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 fullständigt domännamn 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.

Överväganden

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ökningen ä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 Windows Explorer.
  • 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änsningen 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.
  • Azure DNS-IP-adressen är 168.63.129.16. Det här är en statisk IP-adress och ändras inte.

Omvända DNS-överväganden

Omvänd DNS stöds i alla ARM-baserade virtuella nätverk. Du kan utfärda omvända DNS-frågor (PTR-frågor) för att mappa IP-adresser för virtuella datorer till FQDN för virtuella datorer.

  • Alla PTR-frågor för IP-adresser för virtuella datorer returnerar FQDN för formatet [vmname].internal.cloudapp.net
  • Vidarebefordra sökning på FQDN för formuläret [vmname].internal.cloudapp.net matchar IP-adressen som tilldelats till den virtuella datorn.
  • Om det virtuella nätverket är länkat till en privat Azure DNS-zon som ett virtuellt registreringsnätverk returnerar de omvända DNS-frågorna två poster. En post kommer att ha formatet [vmname]. [privatednszonename] och det andra kommer att ha formatet [vmname].internal.cloudapp.net
  • Omvänd DNS-sökning är begränsad till ett visst virtuellt nätverk även om det är peer-kopplat till andra virtuella nätverk. Omvända DNS-frågor (PTR-frågor) för IP-adresser för virtuella datorer som finns i peerkopplade virtuella nätverk returnerar NXDOMAIN.
  • Om du vill inaktivera omvänd DNS-funktion i ett virtuellt nätverk kan du göra det genom att skapa en omvänd uppslagszon med hjälp av privata Azure DNS-zoner och länka den här zonen till ditt virtuella nätverk. Om IP-adressutrymmet för ditt virtuella nätverk 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. När du länkar zonen till ditt virtuella nätverk bör du inaktivera automatisk registrering på länken. Den här zonen åsidosätter standardzonerna för omvänd sökning för det virtuella nätverket och eftersom den här zonen är tom får du NXDOMAIN för dina omvända DNS-frågor. Se vår snabbstartsguide för information om hur du skapar en privat DNS-zon och länkar den till ett virtuellt nätverk.

Anteckning

Om du vill att omvänd DNS-sökning ska sträcka sig över ett virtuellt nätverk kan du skapa en omvänd uppslagszon (in-addr.arpa) privata Azure DNS-zoner och länka den till flera virtuella nätverk. Du måste dock 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 bidrar 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.

Standard Windows DNS-klienten 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 på varje virtuell Linux-dator.

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

  • Ubuntu (använder resolveconf):
    • Installera dnsmasq-paketet med sudo apt-get install dnsmasq.
  • SUSE (använder netconf):
    • Installera dnsmasq-paketet med sudo zypper install dnsmasq.
    • Aktivera dnsmasq-tjänsten med systemctl enable dnsmasq.service.
    • Starta dnsmasq-tjänsten med systemctl start dnsmasq.service.
    • Redigera /etc/sysconfig/network/config och ändra NETCONFIG_DNS_FORWARDER="" till dnsmasq.
    • Uppdatera resolve.conf med netconfig updateför att ange cacheminnet som den lokala DNS-matcharen.
  • CentOS (använder NetworkManager):
    • Installera dnsmasq-paketet med sudo yum install dnsmasq.
    • Aktivera dnsmasq-tjänsten med systemctl enable dnsmasq.service.
    • Starta dnsmasq-tjänsten med systemctl start dnsmasq.service.
    • Lägg till prepend domain-name-servers 127.0.0.1 till/etc/dhclient-eth0.conf.
    • Starta om nätverkstjänsten med service network restartför att ange cacheminnet som den lokala DNS-matcharen.

Anteckning

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 återförsök 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 vanligtvis automatiskt och bör inte redigeras. De specifika stegen för att lägga till alternativraden varierar beroende på distribution:

  • Ubuntu (använder resolveconf):
    1. Lägg till alternativraden i /etc/resolveconf/resolve.conf.d/tail.
    2. Kör resolvconf -u för att uppdatera.
  • SUSE (använder netconf):
    1. Lägg till timeout:1-försök:5 till parametern NETCONFIG_DNS_RESOLVER_OPTIONS="" i /etc/sysconfig/network/config.
    2. Kör netconfig update för att uppdatera.
  • CentOS (använder NetworkManager):
    1. Lägg till raden RES_OPTIONS="options timeout:1 attempts:5" till filen /etc/sysconfig/network-scripts/ifcfg-eth0.
    2. Uppdatera med systemctl restart NetworkManager.service.

Namnmatchning som använder din egen DNS-server

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

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 och matcha DNS-namn mellan virtuella nätverk. För att täcka dessa scenarier ger Azure dig möjlighet att använda dina egna DNS-servrar.

DNS-servrar i ett virtuellt nätverk kan vidarebefordra DNS-frågor till rekursiva matchare i Azure. På så sätt 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.

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 matchning. 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.

Anteckning

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 bara namnmatchningen 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 som vidarebefordrar mellan de två virtuella nätverken).

Diagram of DNS between virtual networks

När du använder azure-tillhandahållen namnmatchning 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 din egen lösning för namnmatchning tillhandahålls inte det här suffixet till virtuella datorer eftersom det stör andra DNS-arkitekturer (till exempel domänanslutna scenarier). Azure tillhandahåller i stället 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 bör du ange en egen DNS-lösning. DNS-lösningen måste:

  • 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.

Anteckning

  • 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 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.

Webbappar

Anta att du behöver utföra namnmatchning från din webbapp som skapats med hjälp av App Service, länkade 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:

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

  2. I Azure Portal går du till App Service-plan som är värd för webbappen och väljer Synkronisera nätverk under NätverkVirtual Network Integration.

    Screenshot of virtual network name resolution

Om 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 ett annat virtuellt nätverk, måste du använda anpassade DNS-servrar i båda virtuella nätverken på följande sätt:

  • 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-adress 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 den här 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 virtuellt 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.
  • I Azure Portal går du till App Service-plan som är värd för webbappen och väljer Synkronisera nätverk under NätverkVirtual Network Integration.

Ange DNS-servrar

När du använder dina egna DNS-servrar ger Azure möjlighet att 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 har angetts för det virtuella nätverket.

Anteckning

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

När du använder Distributionsmodellen för Azure Resource Manager 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.

Anteckning

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

När du använder den klassiska distributionsmodellen kan du ange DNS-servrar för det virtuella nätverket i Azure Portal- eller nätverkskonfigurationsfilen. För molntjänster kan du ange DNS-servrar via tjänstkonfigurationsfilen eller med hjälp av PowerShell med New-AzureVM.

Anteckning

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 os-typ.

Nästa steg

Distributionsmodell för Azure Resource Manager:

Klassisk distributionsmodell: