Microsoft AZ-700: Azure DNS en naamresolutie — Studiegids

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Onderdeel van de Microsoft Azure Network Engineer AZ-700 — Studiegids. Oefen met geverifieerde antwoorden in het Microsoft-examencentrum, of doe getimede oefentests op ExamRoll.io.

Azure DNS: publieke zones, privézones en de afwegingen

Azure biedt zowel publieke DNS-hosting als private DNS-resolutie die nauw geïntegreerd zijn met het virtuele netwerkvlak. De keuze hiertussen is een kwestie van scope, controle, kosten en operationeel beheer. Publieke Azure DNS-zones (gehost in Azure DNS) zijn geschikt voor namen die naar het internet gericht zijn en profiteren van wereldwijde anycast-eindpunten, voorspelbaar API-gestuurd beheer en schaalbaarheid per query. Met Private DNS-zones kunt u zonenamen beheren die alleen worden omgezet naar privé-IP-adressen binnen gekoppelde VNets; ze elimineren de noodzaak om DNS-VM’s te draaien en te onderhouden voor naamresolutie binnen Azure en ondersteunen automatisch recordbeheer bij integratie met bepaalde PaaS private endpoints. De belangrijkste afweging is controle: aangepaste DNS-servers (Windows DNS, BIND) bieden absolute flexibiliteit—conditional forwarding, geavanceerde policies en AD-geïntegreerd SRV/CNAME-gedrag—ten koste van VM-/beheeroverhead en de verantwoordelijkheid voor de veerkracht. Prestatiekeuzes komen neer op latentie versus kosten: beheerde Azure DNS-services verminderen het onderhoud en bieden wereldwijde resolutiesnelheid voor publieke query’s, terwijl DNS-forwarders of resolver-appliances in een hub de hybride prestaties kunnen verbeteren en policies kunnen afdwingen, maar extra compute- en beschikbaarheidskosten met zich meebrengen. Veelvoorkomende valkuilen zijn het vergeten te koppelen van een Private DNS-zone aan elk VNet dat resolutie nodig heeft, het niet migreren van delegaties bij het verplaatsen van namen van on-prem naar Azure, en het verwachten van automatisch public-to-private split-horizon-gedrag zonder expliciete DNS-records of forwarding.

Azure DNS (Public): wereldwijde anycast, beheerde API, facturering per zone/query.
Private DNS zones: VNet-scoped resolutie, automatische aanmaak van private records voor ondersteunde PaaS.
App Gateway WAF_v2: aanbevolen voor moderne WAF-functies en het v2-schaalmodel.
Azure Firewall (Standard/Policy): centrale DNS-proxyoptie; voegt kosten toe maar centraliseert policybeheer.
Custom DNS (VM-gebaseerd): maximale controle, hogere operationele en beschikbaarheidskosten.

Private DNS-zones, private endpoint-records en naamgevingsstrategieën

Wanneer u publiek gehoste services omzet naar private endpoints of servers naar Azure migreert, wordt DNS het coördinatiepunt. Private endpoints registreren A-records op NIC-niveau in private DNS-zones die moeten overeenkomen met de publieke FQDN die clients moeten gebruiken; het juiste patroon is om privézones te creëren die de publieke namespace spiegelen (bijvoorbeeld contoso.com) of servicespecifieke privatelink-zones te gebruiken (voor platformservices) en vervolgens automatische registratie in te schakelen of handmatig A/CNAME-records aan te maken die de FQDN mappen naar het privé-IP-adres van het endpoint. Scope is belangrijk: het koppelen van een privézone aan één VNet beperkt de resolutie tot dat VNet; hub-and-spoke-ontwerpen vereisen dat de zone aan alle spokes wordt gekoppeld of dat DNS-forwarding wordt gebruikt van de spokes naar een hub-resolver. Een typische migratievalkuil is het laten wijzen van de publieke DNS naar het oude on-prem IP-adres terwijl Azure-clients naar een privé-IP-adres resolven; om split-brain-verwarring te voorkomen, plan duidelijke overstapprocedures—werk publieke records pas bij nadat de private DNS en forwarding zijn gevalideerd, of gebruik split-horizon-naamgeving met een expliciete privézone voor dezelfde naam. Certificaten en host-headers moeten op elkaar zijn afgestemd: als u verwacht dat Application Gateway end-to-end TLS uitvoert naar een private backend, zorg er dan voor dat de CN/SAN van het backend-certificaat overeenkomt met de hostnaam die de gateway als Host-header verstuurt; anders zal de backend-TLS mislukken.

Azure Private Resolver en hybride naamresolutiepatronen

Azure Private Resolver maakt beheerde, schaalbare DNS-forwarding mogelijk tussen Azure VNets en on-premises netwerken zonder dat u zelf DNS-VM’s hoeft te beheren. Ontwerppatronen plaatsen resolver-eindpunten doorgaans in een hub-VNet: inkomende eindpunten ontvangen query’s van on-prem (via VPN/ExpressRoute) voor Azure private zones, terwijl uitgaande eindpunten Azure-query’s doorsturen naar on-prem DNS-servers voor uitsluitend interne namen. Regelsets van de resolver definiëren conditional forwarding voor specifieke namespaces (bijvoorbeeld contoso.internal → on-prem DNS IP’s) en kunnen worden gekoppeld aan VNets; voor wereldwijde bedrijfsdeployments centraliseert u het regelbeheer in de hub en peert of routeert u verkeer van spokes naar de hub-resolver. Afwegingen tussen prestaties en kosten omvatten het provisioneren van meerdere inkomende eindpunten in verschillende regio’s voor veerkracht en lage latentie (wat extra kosten met zich meebrengt) of het accepteren van resolver-eindpunten in één regio met peering, maar met een hogere cross-regionale latentie. Veelvoorkomende valkuilen: het niet bijwerken van on-prem conditional forwarders zodat ze naar de inkomende IP’s van de resolver wijzen, het verkeerd configureren van network security group-regels die DNS TCP/UDP 53 naar resolver-eindpunten blokkeren, en aannemen dat de door Azure geleverde DNS (168.63.129.16) zal doorsturen naar on-prem—expliciete resolver-configuratie is vereist voor conditional forwarding.

DNS-poorten: 53 UDP en 53 TCP moeten zijn toegestaan voor normale resolutie en zone-transfers.
Resolver-eindpunten: implementeer in hub-VNets; zorg ervoor dat NSG en firewall inkomend DNS-verkeer toestaan.

Aangepaste DNS-servers, DNS-proxying en operationele valkuilen

Aangepaste DNS-servers (Windows DNS domain controllers of Linux BIND) zijn nog steeds zinvol wanneer Active Directory-integratie, complex voorwaardelijk doorsturen of geavanceerde DNS-beleidsregels vereist zijn. Ze brengen echter operationele verantwoordelijkheden met zich mee: patchen, HA-clustering, back-ups en schalen. Alternatieven die de operationele last verminderen zijn Azure Private DNS-zones voor resolutie binnen Azure en Azure Private Resolver of Azure Firewall DNS proxy om doorstuurbeleid te centraliseren. DNS-proxy’s (de Azure Firewall DNS proxy-functie of NVA’s van derden) kunnen DNS onderscheppen en doorsturen naar geselecteerde resolvers, wat beleid en logging vereenvoudigt maar ook ‘single points of failure’ en extra latency kan toevoegen. Belangrijke ontwerpbeslissingen zijn onder meer of men op VM’s gebaseerde forwarders in een hub gebruikt (lagere kosten, meer onderhoud) versus Azure Private Resolver (beheerd, betere schaalbaarheid), hoeveel resolver-eindpunten er over regio’s moeten worden geïmplementeerd voor latency/veerkracht, en of automatische DNS-registratie van private endpoints moet worden ingeschakeld. Veelvoorkomende fouten van engineers zijn het uitsluitend vertrouwen op VNet-peering voor DNS-resolutie (peering deelt niet automatisch Private DNS-zones), het vergeten om de Private Endpoint-permissie te verlenen voor het automatisch registreren van DNS-records, en het nalaten om certificaatketens te valideren bij het implementeren van end-to-end TLS via een gateway. Dit alles verstoort de naamresolutie of beveiligde verbindingen in productie.

Praktijkprobleem: Use-Case Scenario

Scenario: Fabrikam Inc. beheert een multi-region hub-and-spoke Azure-netwerk. De hub in East US bevat Azure Firewall (Standard) en een Traffic Manager-profiel leidt internetgebruikers naar Application Gateway WAF_v2-instanties in twee regio’s. Twee App Service-instanties hosten www.fabrikam.com, elk gemigreerd vanuit on-prem met private endpoints in hun regionale spokes.

Uitdaging: On-prem clients en Azure spokes moeten na de migratie www.fabrikam.com kunnen resolven naar de private endpoints van de App Service, Application Gateway moet host-headers behouden om end-to-end TLS mogelijk te maken, en DNS-resolutie moet veerkrachtig zijn over de regio’s heen.

Aanbevolen Aanpak:

Implementeer een Azure Private DNS-zone genaamd fabrikam.com in de hub en koppel deze aan zowel de regionale spoke-VNet’s als het hub-VNet; voeg A-records toe voor www.fabrikam.com die verwijzen naar de IP-adressen van de private endpoints (of schakel automatische registratie in voor de private endpoints van de App Service).
Implementeer Azure Private Resolver inbound endpoints in de hub (één per regio voor veerkracht, indien nodig) en configureer on-prem conditional forwarders om query’s voor fabrikam.com door te sturen naar de inbound IP’s van de resolver.
Configureer de HTTP-instellingen van Application Gateway WAF_v2 om HTTPS op poort 443 te gebruiken, stel de backend-hostheader in op www.fabrikam.com en zorg ervoor dat backend health probes HTTPS gebruiken met een hostheader die overeenkomt met de CN/SAN van het certificaat.
Valideer door DNS-query’s uit te voeren vanaf on-prem en vanuit de spokes om te controleren of ze privé-IP’s retourneren, en verifieer end-to-end TLS van de Application Gateway door de CN/SAN van het certificaat en het succes van de probe te controleren.

Rationale: Het centraliseren van private DNS- en resolver-functionaliteit in de hub zorgt voor een ‘single source of truth’ en vereenvoudigt hybride voorwaardelijk doorsturen; het koppelen van de private zone aan alle VNet’s en ervoor zorgen dat de gateway de juiste hostheader gebruikt, behoudt de certificaatvalidatie voor end-to-end TLS, waarbij een balans wordt gevonden tussen operationeel beheer, prestaties en veerkracht.

← Hybride netwerken · Alle domeinen · Netwerkbeveiliging →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →