Deze referentiearchitectuur laat zien hoe u een hybride DNS-oplossing (Domain Name System) ontwerpt om namen op te lossen voor workloads die on-premises en in Microsoft Azure worden gehost. Deze architectuur werkt voor gebruikers en andere systemen die verbinding maken vanaf on-premises en het openbare internet.
Architectuur
Een Visio-bestand van deze architectuur downloaden.
Workflow
De architectuur bestaat uit de volgende onderdelen:
- On-premises netwerk. Het on-premises netwerk vertegenwoordigt één datacenter dat is verbonden met Azure via een Azure ExpressRoute- of VPN-verbinding (Virtual Private Network). In dit scenario vormen de volgende onderdelen het on-premises netwerk:
- DNS-servers . Deze servers vertegenwoordigen twee servers waarop de DNS-service is geïnstalleerd die fungeren als resolver/doorstuurserver. Deze DNS-servers worden gebruikt voor alle computers in het on-premises netwerk als DNS-servers. Records moeten op deze servers worden gemaakt voor alle eindpunten in Azure en on-premises.
- Gateway. De gateway vertegenwoordigt een VPN-apparaat of een ExpressRoute-verbinding die wordt gebruikt om verbinding te maken met Azure.
- Hub-abonnement. Het hubabonnement vertegenwoordigt een Azure-abonnement dat wordt gebruikt voor het hosten van connectiviteit, beheer en netwerkresources die worden gedeeld over meerdere door Azure gehoste workloads. Deze resources kunnen worden onderverdeeld in meerdere abonnementen, zoals beschreven in de architectuur op ondernemingsniveau.
Notitie
Het virtuele hubnetwerk kan worden vervangen door een WAN-hub (Virtual Wide Area Network). In dat geval moeten de DNS-servers worden gehost in een ander virtueel Azure-netwerk (VNet). In de architectuur op ondernemingsniveau wordt dat VNet onderhouden in een eigen abonnement met de naam Identiteitsabonnement.
- Azure Bastion-subnet. De Azure Bastion-service in het virtuele hubnetwerk wordt gebruikt voor externe communicatie naar virtuele machines (VM's) in de hub en spoke-VNets van het openbare internet voor onderhoudsdoeleinden.
- Subnet van privé-eindpunt. Het subnet van het privé-eindpunt host privé-eindpunten voor door Azure gehoste workloads in VNets die niet zijn gekoppeld aan de hub. Met dit type niet-verbonden VNet kunnen de IP-adressen ervan botsen met andere IP-adressen die worden gebruikt in Azure en on-premises.
- Gatewaysubnet. Het gatewaysubnet fungeert als host voor de Azure VPN- of ExpressRoute-gateway die wordt gebruikt om verbinding te maken met het on-premises datacenter.
- Subnet voor gedeelde services. Het subnet gedeelde services host services die worden gedeeld tussen meerdere Azure-workloads. In dit scenario host dit subnet virtuele machines met Windows of Linux die ook worden gebruikt als DNS-servers. Deze DNS-servers hosten dezelfde DNS-zones als de on-premises servers.
- Verbinding maken ed abonnement. Het verbonden abonnement vertegenwoordigt een verzameling workloads waarvoor een virtueel netwerk en een verbinding met het on-premises netwerk zijn vereist.
- VNet-peering. Dit onderdeel is een peeringverbinding met het hub-VNet. Met deze verbinding kunt u verbinding maken vanuit het on-premises netwerk naar de spoke en terug via het hub-VNet.
- Standaardsubnet. Het standaardsubnet bevat een voorbeeldworkload.
- web-vmss. Deze voorbeeldschaalset voor virtuele machines fungeert als host voor een workload in Azure die toegankelijk is vanuit on-premises, Azure en het openbare internet.
- Load balancer. De load balancer biedt toegang tot een workload die wordt gehost door een reeks VM's. Het IP-adres van deze load balancer in het standaardsubnet moet worden gebruikt voor toegang tot de workload vanuit Azure en vanuit het on-premises datacenter.
- AppGateway-subnet. Dit subnet is het vereiste subnet voor de Azure-toepassing Gateway-service.
- AppGateway. Application Gateway biedt toegang tot de voorbeeldworkload in het standaardsubnet voor gebruikers van het openbare internet.
- wkld1-pip. Dit adres is het openbare IP-adres dat wordt gebruikt voor toegang tot de voorbeeldworkload vanaf het openbare internet.
- Abonnement is verbroken. Het niet-verbonden abonnement vertegenwoordigt een verzameling workloads waarvoor geen verbinding met het on-premises datacenter is vereist en die gebruikmaken van de Private Link-service.
- PLSSubnet. Het subnet van de Private Link-service (PLSSubnet) bevat een of meer private link-serviceresources die connectiviteit bieden met workloads die worden gehost in het Verbinding maken ed-abonnement.
- Standaardsubnet. Het standaardsubnet bevat een voorbeeldworkload.
- web-vmss. Deze voorbeeldschaalset voor virtuele machines fungeert als host voor een workload in Azure die toegankelijk is vanuit on-premises, Azure en het openbare internet.
- Load balancer. De load balancer biedt toegang tot een workload die wordt gehost door een reeks VM's. Deze load balancer is verbonden met de Private Link-service om toegang te bieden voor gebruikers die afkomstig zijn van Azure en het on-premises datacenter.
- AppGateway-subnet. Dit subnet is het vereiste subnet voor de Application Gateway-service.
- AppGateway. Application Gateway biedt toegang tot de voorbeeldworkload in het standaardsubnet voor gebruikers van het openbare internet.
- wkld2-pip. Dit adres is het openbare IP-adres dat wordt gebruikt voor toegang tot de voorbeeldworkload vanaf het openbare internet.
- Azure Bastion-subnet. De Azure Bastion-service in het niet-verbonden virtuele netwerk wordt gebruikt voor externe communicatie met VM's in de hub en spoke-VNets van het openbare internet voor onderhoudsdoeleinden.
Onderdelen
Virtueel netwerk. Azure Virtual Network (VNet) is de basisbouwsteen voor uw privénetwerk in Azure. Via VNet kunnen veel soorten Azure-resources, zoals virtuele Azure-machines, veilig communiceren met elkaar, internet en on-premises netwerken.
Azure Bastion. Azure Bastion is een volledig beheerde service die veiligere en naadloze toegang tot virtuele machines biedt via RDP (Remote Desktop Protocol) en SSH (Secure Shell Protocol) (VM's) zonder blootstelling via openbare IP-adressen.
VPN-gateway. VPN Gateway verzendt versleuteld verkeer tussen een virtueel Azure-netwerk en een on-premises locatie via het openbare internet. U kunt VPN Gateway ook gebruiken om versleuteld verkeer tussen virtuele Azure-netwerken via het Microsoft-netwerk te verzenden. Een VPN-gateway is een specifiek type virtuele netwerkgateway.
Private Link. Azure Private Link biedt een privéverbinding vanaf een virtueel netwerk naar Azure Platform as a Service (PaaS), eigen service van de klant of services van Microsoft-partners. Het vereenvoudigt de netwerkarchitectuur en beveiligt de verbinding tussen eindpunten in Azure door de blootstelling van gegevens aan het openbare internet te elimineren.
Application Gateway Azure Application Gateway is een load balancer voor webverkeer waarmee u het verkeer naar uw webapps kunt beheren. Traditionele load balancers werken op de transportlaag (OSI-laag 4 - TCP en UDP) en routeren verkeer op basis van IP-bronadres en een bronpoort naar een IP-doeladres en doelpoort.
Aanbevelingen
De volgende aanbevelingen gelden voor de meeste scenario's. Volg deze aanbevelingen tenzij er een specifieke vereiste is die iets anders voorschrijft.
Notitie
Voor de volgende aanbevelingen verwijzen we naar Workload 1 als een verbonden workload en Workload 2 als een niet-verbonden workload. We verwijzen ook naar gebruikers en systemen die toegang hebben tot deze workloads als on-premises gebruikers, internetgebruikers en Azure-systemen.
AD DS uitbreiden naar Azure (optioneel)
Gebruik geïntegreerde DNS-zones in AD DS om DNS-records te hosten voor uw on-premises datacenter en Azure. In dit scenario zijn er twee sets AD DS DNS-servers: één on-premises en één in het hub-VNet.
Het is raadzaam om uw AD DS-domein uit te breiden naar Azure. U wordt ook aangeraden de hub- en spoke-VNets te configureren voor het gebruik van de AD DS DNS-servers in het hub-VNet voor alle VM's in Azure.
Notitie
Deze aanbeveling is alleen van toepassing voor organisaties die gebruikmaken van de geïntegreerde DNS-zone van Active Directory voor naamomzetting. Anderen kunnen overwegen DNS-servers te implementeren die fungeren als resolver/doorstuurserver.
Split-brain DNS configureren
Zorg ervoor dat split-brain DNS is ingesteld om Azure-systemen, on-premises gebruikers en internetgebruikers toegang te geven tot workloads op basis van waar ze verbinding maken.
Voor zowel verbonden als niet-verbonden workloads raden we de volgende onderdelen aan voor DNS-omzetting:
- Azure DNS-zones voor internetgebruikers.
- DNS-servers voor on-premises gebruikers en Azure-systemen.
- Privé-DNS-zones van Azure voor omzetting tussen Azure VNets.
Als u deze split-brain-aanbeveling beter wilt begrijpen, kunt u Workload 1 overwegen, waarvoor we de wkld1.contoso.com FQDN (Fully Qualified Domain Name) gebruiken.
In dit scenario moeten internetgebruikers die naam omgezet in het openbare IP-adres dat Application Gateway beschikbaar maakt via Wkld1-pip. Deze oplossing wordt uitgevoerd door een adresrecord (A-record) te maken in Azure DNS voor het verbonden abonnement.
On-premises gebruikers moeten dezelfde naam oplossen met het interne IP-adres voor de load balancer in het verbonden abonnement. Deze oplossing wordt uitgevoerd door een A-record te maken op de DNS-servers in het hub-abonnement.
Azure-systemen kunnen dezelfde naam oplossen met een intern IP-adres voor de load balancer in het verbonden abonnement door een A-record te maken in de DNS-server in het hubabonnement of door privé-DNS-zones te gebruiken. Wanneer u privé-DNS-zones gebruikt, maakt u handmatig een A-record in de privé-DNS-zone of schakelt u automatische registratie in.
Privé-DNS-zones gebruiken voor een privékoppeling
In ons scenario wordt Workload 2 gehost in een niet-verbonden abonnement en is toegang tot deze workload voor on-premises gebruikers en verbonden Azure-systemen mogelijk via een privé-eindpunt in het hub-VNet. Er is echter een derde verbindingsmogelijkheid voor deze workload: Azure-systemen in hetzelfde VNet als Workload 2.
Om de DNS-aanbevelingen voor Workload 2 beter te begrijpen, gebruiken we de wkld2.contoso.com FQDN en bespreken we de afzonderlijke aanbevelingen.
In dit scenario moeten internetgebruikers die naam oplossen met het openbare IP-adres dat Application Gateway beschikbaar maakt via Wkld2-pip. Deze oplossing wordt uitgevoerd door een A-record te maken in Azure DNS voor het verbonden abonnement.
On-premises gebruikers en Azure-systemen die zijn verbonden met het hub-VNet en spoke-VNets, moeten dezelfde naam omzetten in het interne IP-adres voor het privé-eindpunt in het Hub-VNet. Deze oplossing wordt uitgevoerd door een A-record te maken op de DNS-servers in het hub-abonnement.
Azure-systemen in hetzelfde VNet als Workload 2 moeten de naam omzetten in het IP-adres van de load balancer in het niet-verbonden abonnement. Deze oplossing wordt uitgevoerd met behulp van een privé-DNS-zone in Azure DNS in dat abonnement.
Azure-systemen in verschillende VNets kunnen het IP-adres van workload 2 nog steeds omzetten als u deze VNets koppelt aan een privé-DNS-zone die als host fungeert voor de A-record voor Workload 2.
Automatische registratie inschakelen
Wanneer u een VNet-koppeling met een privé-DNS-zone configureert, kunt u optioneel automatische registratie voor alle virtuele machines configureren.
Notitie
Automatische registratie werkt alleen voor virtuele machines. Voor alle andere resources die zijn geconfigureerd met IP-adres van het VNet, moet u handmatig DNS-records maken in de privé-DNS-zone.
Als u AD DS DNS-server gebruikt, kunt u windows-VM's configureren met dynamische updates voor Windows-computers om uw eigen DNS-records up-to-date te houden op de AD DS DNS-servers. U wordt aangeraden dynamische updates in te schakelen en de DNS-servers zo te configureren dat alleen beveiligde updates worden toegestaan.
Linux-VM's bieden geen ondersteuning voor beveiligde dynamische updates. Voor on-premises Linux-computers gebruikt u DHCP (Dynamic Host Configuration Protocol) om DNS-records te registreren bij de AD DS DNS-servers.
Gebruik een geautomatiseerd proces voor Virtuele Linux-machines in Azure.
Overwegingen
Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.
Schaalbaarheid
- U kunt per Azure-regio of on-premises datacentrums ten minste twee DNS-servers gebruiken.
- U ziet hoe dat in het vorige scenario wordt gedaan, met on-premises DNS-servers en in het virtuele hubnetwerk.
Beschikbaarheid
- Overweeg de plaatsing van DNS-servers. Zoals beschreven in de sectie overwegingen voor schaalbaarheid, moeten DNS-servers dicht bij de gebruikers en systemen worden geplaatst die toegang tot deze servers nodig hebben.
- Per Azure-regio. Elke Azure-regio heeft een eigen hub-VNet of vWAN-hub. Hier moeten uw DNS-servers worden geïmplementeerd.
- Per on-premises datacenter. U moet ook een paar DNS-servers per on-premises datacenter hebben voor gebruikers en systemen op die locaties.
- Voor geïsoleerde (niet-verbonden) workloads host u een privé-DNS-zone en een openbare DNS-zone voor elk abonnement voor het beheren van split-brain DNS-records.
Beheerbaarheid
- Houd rekening met de noodzaak van DNS-records voor PaaS-services (Platform as a Service).
- U moet ook rekening houden met DNS-omzetting voor PaaS-services die gebruikmaken van een privé-eindpunt. Gebruik hiervoor een privé-DNS-zone en gebruik uw DevOps-pijplijn om records op de DNS-servers te maken.
Beveiliging
Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.
- Als u het gebruik van DNSSEC nodig hebt, moet u er rekening mee houden dat Azure DNS dit momenteel niet ondersteunt.
- Implementeer voor DNSSEC-validatie een aangepaste DNS-server en schakel DNSEC-validatie in.
- Azure DDoS Protection, gecombineerd met best practices voor toepassingsontwerp, biedt verbeterde DDoS-risicobeperkingsfuncties om meer bescherming te bieden tegen DDoS-aanvallen. Schakel Azure DDOS Protection in voor elk virtueel perimeternetwerk.
DevOps
- Automatiseer de configuratie van deze architectuur door Azure Resource Manager-sjablonen te combineren voor de configuratie van alle resources. Zowel privé- als openbare DNS-zones ondersteunen volledig beheer vanuit Azure CLI, PowerShell, .NET en REST API.
- Als u een pijplijn voor continue integratie en continue ontwikkeling (CI/CD) gebruikt om workloads in Azure en on-premises te implementeren en te onderhouden, kunt u ook automatische registratie van DNS-records configureren.
Kostenoptimalisatie
Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.
- Azure DNS-zonekosten zijn gebaseerd op het aantal DNS-zones dat wordt gehost in Azure en het aantal ontvangen DNS-query's.
- Gebruik de Azure-prijscalculator om een schatting van de kosten te maken. Prijsmodellen voor Azure DNS worden hier uitgelegd.
- Het factureringsmodel voor Azure ExpressRoute is gebaseerd op datalimiet, die u per gigabyte in rekening brengt voor uitgaande gegevensoverdracht of onbeperkte gegevens, waarvoor maandelijkse kosten in rekening worden gebracht, inclusief alle gegevensoverdracht.
- Als u VPN gebruikt in plaats van ExpressRoute, zijn de kosten afhankelijk van de SKU van de gateway van het virtuele netwerk en worden er kosten in rekening gebracht per uur.
Volgende stappen
Meer informatie over de onderdeeltechnologieën:
Verwante resources
Gerelateerde architecturen verkennen: