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 (VM) 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 sparas 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:

• Azure DNS privata zoner
• Namnmatchning från Azure
• Namnmatchning som använder din egen DNS-server (som kan vidarebefordra frågor till Azure-tillhandahållna DNS-servrar)

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 namnmatchningslösningar:

Namnmatchning från Azure

Namnmatchning från Azure ger endast grundläggande auktoritativa DNS-funktioner. Om du använder det här alternativet hanteras DNS-zonnamn och -poster automatiskt av Azure och du kommer inte att kunna styra DNS-zonnamnen eller livscykeln för DNS-poster. Om du behöver en komplett DNS-lösning för dina virtuella nätverk måste du använda Azure DNS zoner eller Kund-hanterade DNS-servrar.

Tillsammans med en lösning 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 så fall behöver du FQDN för att matcha namn mellan olika molntjänster. I virtuella nätverk som distribueras med Azure Resource Manager-distributionsmodellen är DNS-suffixet konsekvent över 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 azure-tillhandahållen namnmatchning inte kräver någon konfiguration, är det inte det rätta valet för alla distributionsscenarier, enligt beskrivningen i föregående tabell.

Funktioner

Namnmatchning från 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 matcha både lokala värdnamn och Azure-värdnamn.
• Du kan använda namnmatchning mellan virtuella datorer och rollinstanser i samma molntjänst, utan att behöva ett FQDN.
• Du kan använda namnmatchning mellan virtuella datorer i virtuella nätverk som använder Azure Resource Manager distributionsmodellen, utan att behöva ett FQDN. 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.

Överväganden

Saker att tänka på när du använder namnmatchning från Azure:

• Det azure-skapade DNS-suffixet kan inte ändras.
• 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 Windows Explorer.
• Värdnamn måste vara DNS-kompatibla. Namn får bara använda 0–9, a–z och "-" och får inte börja eller sluta med "-".
• DNS-frågetrafiken begränsas för varje virtuell dator. Begränsningen bör inte påverka de flesta program. Om begränsning av förfrågningar observeras ser du till att cachelagring på klientsidan är aktiverat. Mer information finns i DNS-klientkonfiguration.
• 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 Azure DNS adressen är 168.63.129.16. Det här är en statisk IP-adress som inte ändras.

Överväganden för omvänd DNS

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:er med formen [ vmname ] .internal.cloudapp.net
• Forward lookup on FQDN of form [ vmname ] .internal.cloudapp.net matchar IP-adressen som tilldelats den virtuella datorn.
• Om det virtuella nätverket är länkat till Azure DNS privata zoner som ett virtuellt registreringsnätverk returnerar omvända DNS-frågor två poster. En post har formen [ vmname ] .[ privatednszonename] och den andra ska ha formen [ vmname ] .internal.cloudapp.net
• Omvänd DNS-sökning är begränsad till ett visst virtuellt nätverk även om det är peerkopplat till andra virtuella nätverk. Omvända DNS-frågor (PTR-frågor) för IP-adresser för virtuella datorer som finns i peer-baserade 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 zon för omvänd sökning med hjälp av Azure DNS privata zoner och 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. 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.

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 i nätverket. Cachelagring på klientsidan hjälper till att minska svarstiden och förbättra återhämtningsförmågan för nätverkslyckan genom att matcha återkommande DNS-frågor från en lokal cache. DNS-poster innehåller en TTL-mekanism (Time-to-Live) som gör att cachen kan lagra posten så länge som möjligt utan att påverka postens freshness. Cachelagring på klientsidan lämpar sig därför för de flesta situationer.

Standardvärdet 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 (till exempel dnsmasq). Så här installerar du dnsmasq på de vanligaste distributionerna:

• Ubuntu (använder resolvconf):
  • Installera dnsmasq-paketet med sudo apt-get install dnsmasq .
• SUSE (använder netconf):
  • Installera dnsmasq-paketet med sudo zypper install dnsmasq .
  • Aktivera tjänsten dnsmasq med systemctl enable dnsmasq.service .
  • Starta tjänsten dnsmasq med systemctl start dnsmasq.service .
  • Redigera /etc/sysconfig/network/config och ändra NETCONFIG_DNS_FORWARDER="" till dnsmasq.
  • Uppdatera resolve.conf med netconfig update för att ange cachen som den lokala DNS-matcharen.
• CentOS (använder NetworkManager):
  • Installera dnsmasq-paketet med sudo yum install dnsmasq .
  • Aktivera tjänsten dnsmasq med systemctl enable dnsmasq.service .
  • Starta tjänsten dnsmasq 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 restart för att ange cachen som den lokala DNS-matcharen.

Återförsök på klientsidan

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

• Windows återförsök efter en sekund och sedan igen efter ytterligare två sekunder, fyra sekunder och ytterligare fyra sekunder.
• Linux-standardinstallationen 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 resolv.conf genereras vanligtvis automatiskt och bör inte redigeras. De specifika stegen för att lägga till alternativlinjen varierar beroende på distribution:

• Ubuntu (använder resolvconf):
  1. Lägg till alternativraden i /etc/resolvconf/resolv.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" i 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

Dina namnmatchningsbehov kan gå längre än de funktioner som tillhandahålls av Azure. Du kan till exempel behöva använda Microsoft Windows Server Active Directory domäner, 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 de rekursiva matcharna 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 azure-tillhandahållna värdnamn (via vidarebefordraren). Åtkomst till rekursiva matchare i Azure tillhandahålls via den virtuella IP-adressen 168.63.129.16.

DNS-vidarebefordran möjliggör även DNS-upplösning 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 är olika 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-upplösning mellan virtuella nätverk med hjälp av den här metoden. Ett exempel på en DNS-vidarebefordrare finns i galleriet Azure-snabbstartsmallar och GitHub.

När du använder namnmatchning från Azure tillhandahåller Azure Dynamic Host Configuration Protocol (DHCP) ett internt DNS-suffix (.internal.cloudapp.net) till varje virtuell dator. Det här suffixet möjliggör värdnamnmatchning eftersom värdnamnsposterna finns i internal.cloudapp.net zonen. När du använder en egen namnmatchningslösning tillhandahålls inte det här suffixet till virtuella datorer eftersom det stör andra DNS-arkitekturer (till exempel domän-ansluten scenarier). I stället tillhandahåller Azure en platshållare som inte fungerar (reddog.microsoft.com).

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

• För virtuella nätverk i Azure Resource Manager-distributionsmodeller är suffixet tillgängligt via nätverksgränssnittet REST API, PowerShell-cmdleten Get-AzNetworkInterface och kommandot az network nic show Azure CLI.
• I klassiska distributionsmodeller är suffixet tillgängligt via api-anropet Get Deployment eller cmdleten Get-AzureVM -Debug.

Om vidarebefordran av frågor till Azure inte passar dina behov bör du tillhandahålla en egen DNS-lösning. Din DNS-lösning måste:

• Ange lämplig värdnamnsmatchning, till exempel via DDNS. Om du använder DDNS kan du behöva inaktivera DNS-postrallring. 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 fungerar och ha åtkomst till Internet.
• Skyddas mot åtkomst från Internet för att minimera hot från externa agenter.

Webbappar

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

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

2. I Azure Portal väljer du För App Service plan som är värd för webbappen Synkronisera nätverk under Nätverk , Virtual Network Integration.

   

Om du behöver utföra namnmatchning från din webbapp som skapats med hjälp av App Service, länkad till ett virtuellt nätverk, till virtuella datorer i ett annat virtuellt nätverk, måste du använda anpassade DNS-servrar på båda virtuella nätverken på följande sätt:

• Konfigurera en DNS-server i det virtuella målnätverket 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å en 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 det virtuella målnätverket.
• Konfigurera DNS-källservern i inställningarna för det virtuella källnätverket.
• Aktivera integrering av virtuellt nätverk för din webbapp 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 väljer du För App Service plan som är värd för webbappen Synkronisera nätverk under Nätverk , Virtual Network Integration.

Ange DNS-servrar

När du använder dina egna DNS-servrar ger Azure dig 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 DNS-servrar som anges för det virtuella nätverket.

När du använder distributionsmodellen 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.

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.

Nästa steg

Azure Resource Manager distributionsmodell:

• Hantera ett virtuellt nätverk
• Hantera ett nätverksgränssnitt

Klassisk distributionsmodell:

• Konfigurationsschema för Azure-tjänsten
• Virtual Network konfigurationsschema
• Konfigurera en Virtual Network med hjälp av en nätverkskonfigurationsfil