Utforma en Domain Name System-hybridlösning med Azure

Den här referensarkitekturen visar hur du utformar en DNS-hybridlösning (Domain Name System) för att matcha namn för arbetsbelastningar som finns lokalt och i Microsoft Azure. Den här arkitekturen fungerar för användare och andra system som ansluter från lokalt och offentligt Internet.

Arkitektur

Ladda ned en Visio-fil med den här arkitekturen.

Arbetsflöde

Arkitekturen består av följande komponenter:

• Lokalt nätverk. Det lokala nätverket representerar ett enda datacenter som är anslutet till Azure via en Azure ExpressRoute- eller VPN-anslutning (Virtual Private Network). I det här scenariot utgör följande komponenter det lokala nätverket:
  • DNS-servrar . Dessa servrar representerar två servrar med DNS-tjänsten installerad som fungerar som matchare/vidarebefordrare. Dessa DNS-servrar används för alla datorer i det lokala nätverket som DNS-servrar. Poster måste skapas på dessa servrar för alla slutpunkter i Azure och lokalt.
  • Gateway. Gatewayen representerar antingen en VPN-enhet eller en ExpressRoute-anslutning som används för att ansluta till Azure.
• Hubbprenumeration. Hubbprenumerationen representerar en Azure-prenumeration som används som värd för anslutnings-, hanterings- och nätverksresurser som delas mellan flera Azure-värdbaserade arbetsbelastningar. Dessa resurser kan delas upp i flera prenumerationer enligt beskrivningen i arkitekturen i företagsskala.

  Kommentar

  Det virtuella hubbnätverket kan ersättas med en WAN-hubb (Virtual Wide Area Network), i vilket fall DNS-servrarna måste finnas i ett annat virtuellt Azure-nätverk (VNet). I arkitekturen i företagsskala underhålls det virtuella nätverket i en egen prenumeration med titeln Identitetsprenumeration.

  • Azure Bastion-undernät. Azure Bastion-tjänsten i det virtuella hubbnätverket används för fjärrkommunikation till virtuella datorer (VM) i de virtuella hubb- och ekernätverken från det offentliga Internet i underhållssyfte.
  • Privat slutpunktsundernät. Det privata slutpunktsundernätet är värd för privata slutpunkter för Azure-värdbaserade arbetsbelastningar i virtuella nätverk som inte är peer-kopplade till hubben. Med den här typen av frånkopplat VNet kan ip-adresserna krocka med andra IP-adresser som används i Azure och lokalt.
  • Gateway-undernät. Gateway-undernätet är värd för den Azure VPN- eller ExpressRoute-gateway som används för att tillhandahålla anslutning tillbaka till det lokala datacentret.
  • Undernät för delade tjänster. Undernätet för delade tjänster är värd för tjänster som delas mellan flera Azure-arbetsbelastningar. I det här scenariot är det här undernätet värd för virtuella datorer som kör Windows eller Linux som också används som DNS-servrar. Dessa DNS-servrar är värdar för samma DNS-zoner som de lokala servrarna.
• Anslut prenumeration. Den anslutna prenumerationen representerar en samling arbetsbelastningar som kräver ett virtuellt nätverk och anslutning tillbaka till det lokala nätverket.
  • VNET-peering. Den här komponenten är en peering-anslutning tillbaka till det virtuella hubbnätverket. Den här anslutningen tillåter anslutning från det lokala nätverket till ekern och tillbaka via det virtuella hubbnätverket.
  • Standardundernät. Standardundernätet innehåller en exempelarbetsbelastning.
    • web-vmss. Den här exempeluppsättningen för vm-skalning är värd för en arbetsbelastning i Azure som kan nås från lokalt, Azure och det offentliga Internet.
    • Lastbalanserare. Lastbalanseraren ger åtkomst till en arbetsbelastning som en serie virtuella datorer är värd för. IP-adressen för den här lastbalanseraren i standardundernätet måste användas för att komma åt arbetsbelastningen från Azure och från det lokala datacentret.
  • AppGateway-undernät. Det här undernätet är det nödvändiga undernätet för Azure Application Gateway-tjänsten.
    • AppGateway. Application Gateway ger åtkomst till exempelarbetsbelastningen i standardundernätet till användare från det offentliga Internet.
    • wkld1-pip. Den här adressen är den offentliga IP-adress som används för att komma åt exempelarbetsbelastningen från det offentliga Internet.
• Frånkopplad prenumeration. Den frånkopplade prenumerationen representerar en samling arbetsbelastningar som inte kräver anslutning tillbaka till det lokala datacentret och som använder tjänsten private link.
  • PLSSubnet. Undernätet för privat länktjänst (PLSSubnet) innehåller en eller flera privata länktjänstresurser som ger anslutning till arbetsbelastningar som finns i den Anslut prenumerationen.
  • Standardundernät. Standardundernätet innehåller en exempelarbetsbelastning.
    • web-vmss. Den här exempeluppsättningen för vm-skalning är värd för en arbetsbelastning i Azure som kan nås från lokalt, Azure och det offentliga Internet.
    • Lastbalanserare. Lastbalanseraren ger åtkomst till en arbetsbelastning som en serie virtuella datorer är värd för. Den här lastbalanseraren är ansluten till tjänsten private link för att ge åtkomst till användare som kommer från Azure och det lokala datacentret.
  • AppGateway-undernät. Det här undernätet är det nödvändiga undernätet för Application Gateway-tjänsten.
    • AppGateway. Application Gateway ger åtkomst till exempelarbetsbelastningen i standardundernätet till användare från det offentliga Internet.
    • wkld2-pip. Den här adressen är den offentliga IP-adress som används för att komma åt exempelarbetsbelastningen från det offentliga Internet.
  • Azure Bastion-undernät. Azure Bastion-tjänsten i det frånkopplade virtuella nätverket används för fjärrkommunikation till virtuella datorer i de virtuella hubb- och ekernätverken från det offentliga Internet i underhållssyfte.

Komponenter

• Virtuellt nätverk. Azure Virtual Network (virtuellt nätverk) utgör grunden för ditt privata nätverk i Azure. Med VNet kan många typer av Azure-resurser, till exempel Virtuella Azure-datorer (VM), kommunicera säkert med varandra, Internet och lokala nätverk.

• Azure Bastion. Azure Bastion är en fullständigt hanterad tjänst som ger säkrare och smidigare åtkomst, via Remote Desktop Protocol (RDP) och Secure Shell Protocol (SSH), till virtuella datorer utan exponering via offentliga IP-adresser.

• VPN Gateway. VPN Gateway skickar krypterad trafik mellan ett virtuellt Azure-nätverk och en lokal plats via det offentliga Internet. Du kan också använda VPN Gateway för att skicka krypterad trafik mellan virtuella Azure-nätverk via Microsoft-nätverket. En VPN-gateway är en specifik typ av virtuell nätverksgateway.

• Private Link. Azure Private Link tillhandahåller en privat anslutning från ett virtuellt nätverk till Azure PaaS-tjänster (Platform as a Service), kundägda tjänster eller Microsoft-partnertjänster. Det förenklar nätverksarkitekturen och skyddar anslutningen mellan slutpunkter i Azure så att inte data exponeras för det offentliga Internet.

• Application Gateway. Azure Application Gateway är en lastbalanserare för webbtrafik som gör det möjligt för dig att hantera trafik till dina webbappar. Traditionella lastbalanserare fungerar med transportlagret (OSI lager 4 – TCP och UDP) och dirigera trafik baserat på källans IP-adress och port till en mål-IP-adress och -port.

Rekommendationer

Följande rekommendationer gäller för de flesta scenarier. Följ dessa rekommendationer om du inte har ett visst krav som åsidosätter dem.

Utöka AD DS till Azure (valfritt)

Använd integrerade DNS-zoner i AD DS som värd för DNS-poster för ditt lokala datacenter och Azure. I det här scenariot finns det två uppsättningar AD DS DNS-servrar: en lokalt och en i det virtuella hubbnätverket.

Vi rekommenderar att du utökar AD DS-domänen till Azure. Vi rekommenderar också att du konfigurerar de virtuella hubb- och ekernätverken för att använda AD DS DNS-servrarna i det virtuella hubbnätverket för alla virtuella datorer i Azure.

Konfigurera DNS för delad hjärna

Kontrollera att split-brain DNS finns på plats för att tillåta Azure-system, lokala användare och Internetanvändare att få åtkomst till arbetsbelastningar baserat på var de ansluter från.

För både anslutna och frånkopplade arbetsbelastningar rekommenderar vi följande komponenter för DNS-matchning:

• Azure DNS-zoner för Internetanvändare.
• DNS-servrar för lokala användare och Azure-system.
• Privata DNS-zoner i Azure för lösning mellan virtuella Azure-nätverk.

För att bättre förstå den här rekommendationen om delad hjärna bör du överväga arbetsbelastning 1, för vilken vi använder det wkld1.contoso.com fullständigt kvalificerade domännamnet (FQDN).

I det här scenariot måste Internetanvändare matcha det namnet med den offentliga IP-adress som Application Gateway exponerar via Wkld1-pip. Den här lösningen görs genom att skapa en adresspost (A-post) i Azure DNS för den anslutna prenumerationen.

Lokala användare måste matcha samma namn med den interna IP-adressen för lastbalanseraren i den anslutna prenumerationen. Den här lösningen görs genom att skapa en A-post i DNS-servrarna i hubbprenumerationen.

Azure-system kan matcha samma namn med en intern IP-adress för lastbalanseraren i den anslutna prenumerationen, antingen genom att skapa en A-post på DNS-servern i hubbprenumerationen eller med hjälp av privata DNS-zoner. När du använder privata DNS-zoner skapar du antingen en A-post manuellt i den privata DNS-zonen eller aktiverar automatisk registrering.

Använda privata DNS-zoner för en privat länk

I vårt scenario finns arbetsbelastning 2 i en frånkopplad prenumeration, och åtkomst till den här arbetsbelastningen för lokala användare och anslutna Azure-system är möjlig via en privat slutpunkt i det virtuella hubbnätverket. Det finns dock en tredje anslutningsmöjlighet för den här arbetsbelastningen: Azure-system i samma virtuella nätverk som arbetsbelastning 2.

För att bättre förstå DNS-rekommendationerna för arbetsbelastning 2 använder vi wkld2.contoso.com FQDN och diskuterar de enskilda rekommendationerna.

I det här scenariot måste Internetanvändare matcha det namnet med den offentliga IP-adress som Application Gateway exponerar via Wkld2-pip. Den här lösningen görs genom att skapa en A-post i Azure DNS för den anslutna prenumerationen.

Lokala användare och Azure-system som är anslutna till det virtuella hubbnätverket och eker-VNet måste matcha samma namn med den interna IP-adressen för den privata slutpunkten i det virtuella hubbnätverket. Den här lösningen görs genom att skapa en A-post i DNS-servrarna i hubbprenumerationen.

Azure-system i samma virtuella nätverk som arbetsbelastning 2 måste matcha namnet på IP-adressen för lastbalanseraren i den frånkopplade prenumerationen. Den här lösningen görs med hjälp av en privat DNS-zon i Azure DNS i den prenumerationen.

Azure-system i olika virtuella nätverk kan fortfarande matcha IP-adressen för arbetsbelastning 2 om du länkar de virtuella nätverken med den privata DNS-zonen som är värd för A-posten för arbetsbelastning 2.

Aktivera automatisk registrering

När du konfigurerar en VNet-länk med en privat DNS-zon kan du välja att konfigurera automatisk registrering för alla virtuella datorer.

Om du använder AD DS DNS-servern kan konfigurera virtuella Windows-datorer använda dynamiska uppdateringar för Windows-datorer för att hålla dina egna DNS-poster uppdaterade på AD DS DNS-servrarna. Vi rekommenderar att du aktiverar dynamiska uppdateringar och konfigurerar DNS-servrarna så att endast säkra uppdateringar tillåts.

Virtuella Linux-datorer stöder inte säkra dynamiska uppdateringar. För lokala Linux-datorer använder du DHCP (Dynamic Host Configuration Protocol) för att registrera DNS-poster till AD DS DNS-servrarna.

För virtuella Linux-datorer i Azure använder du en automatiserad process.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Skalbarhet

• Överväg att använda minst två DNS-servrar vardera per Azure-region eller lokala datacenter.
• Observera hur det går till i föregående scenario, med DNS-servrar lokalt och i det virtuella hubbnätverket.

Tillgänglighet

• Överväg att placera DNS-servrar. Enligt beskrivningen i avsnittet skalbarhetsöverväganden bör DNS-servrar placeras nära de användare och system som behöver åtkomst till dem.
  • Per Azure-region. Varje Azure-region har ett eget virtuellt hubbnätverk eller en vWAN-hubb. Det är här dns-servrarna måste distribueras.
  • Per lokalt datacenter. Du bör också ha ett par DNS-servrar per lokalt datacenter för användare och system på dessa platser.
  • För isolerade (frånkopplade) arbetsbelastningar är du värd för en privat DNS-zon och en offentlig DNS-zon för varje prenumeration för att hantera DNS-poster med delad hjärna.

Hanterbarhet

• Överväg behovet av DNS-poster för PaaS-tjänster (plattform som en tjänst).
• Du måste också överväga DNS-matchning för PaaS-tjänster som använder en privat slutpunkt. Använd en privat DNS-zon för det och använd DevOps-pipelinen för att skapa poster i DNS-servrarna.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.

• Om du behöver använda DNSSEC bör du tänka på att Azure DNS för närvarande inte stöder det.
• För DNSSEC-validering distribuerar du en anpassad DNS-server och aktiverar DNSEC-verifiering.
• Azure DDoS Protection, kombinerat med metodtips för programdesign, ger förbättrade DDoS-åtgärdsfunktioner för att ge mer skydd mot DDoS-attacker. Du bör aktivera Azure DDOS Protection i alla virtuella perimeternätverk.

DevOps

• Automatisera konfigurationen av den här arkitekturen genom att kombinera Azure Resource Manager-mallar för konfiguration av alla resurser. Både privata och offentliga DNS-zoner stöder fullständig hantering från Azure CLI, PowerShell, .NET och REST API.
• Om du använder en CI/CD-pipeline (kontinuerlig integrering och kontinuerlig utveckling) för att distribuera och underhålla arbetsbelastningar i Azure och lokalt kan du även konfigurera automatisk registrering av DNS-poster.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

• Kostnaderna för Azure DNS-zonen baseras på antalet DNS-zoner som finns i Azure och antalet mottagna DNS-frågor.
• Normalt beräknar du kostnader med hjälp av priskalkylatorn för Azure. Prismodeller för Azure DNS beskrivs här.
• Faktureringsmodellen för Azure ExpressRoute baseras antingen på data som mäts, som debiterar dig per gigabyte för utgående dataöverföring eller obegränsade data, som tar ut en månatlig avgift inklusive all dataöverföring.
• Om du använder VPN, i stället för ExpressRoute, är kostnaden beroende av SKU:n för den virtuella nätverksgatewayen och debiteras per timme.

Nästa steg

Läs mer om komponentteknikerna:

• Vad är Azure DNS?
• Vad är Azure Virtual Network?
• Vad är Azure ExpressRoute?
• Vad är Azure Bastion?

Relaterade resurser

Utforska relaterade arkitekturer:

• Azure Enterprise-molnfilresurs
• N-nivåprogram med Apache Cassandra
• SaaS för flera klientorganisationer i Azure
• Utöka ett lokalt nätverk med ExpressRoute