DNS-beveiliging en privénaamomzetting

In dit artikel wordt uitgelegd hoe u DNS ontwerpt voor Azure netwerken met behulp van privé-DNS-zones, Azure DNS privé-resolver en DNS-beveiligingsmaatregelen. Het behandelt patronen voor privénaamomzetting, hybride DNS-doorsturen, DNS-integratie van privé-eindpunten en beveiliging tegen bedreigingen op DNS-laag.

Wat in dit artikel wordt behandeld

DNS vormt de basis van de netwerkverbinding: elke verbinding begint met een naamomzettingsquery. In Azure bepaalt het DNS-ontwerp hoe workloads elkaar via virtuele netwerken heen kunnen vinden, hoe on-premises systemen Azure-gehoste namen omzetten en hoe Private Endpoints via hun fully qualified domain names (FQDN's) bereikbaar worden. Naast resolutie is DNS ook een kwetsbaarheid voor aanvallen. DNS-tunneling, exfiltratie en query's voor schadelijke domeinen vertegenwoordigen echte bedreigingen waarvoor beveiligingsmaatregelen voor DNS-lagen zijn vereist.

In dit artikel worden drie DNS-problemen behandeld:

Privénaamomzetting: Hoe virtuele machines, containers en platformservices namen binnen Azure omzetten zonder DNS-query's beschikbaar te maken voor het openbare internet.
Hybride DNS-doorsturing: Hoe on-premises-netwerken Azure-privénamen oplossen en hoe Azure-workloads on-premises-namen oplossen.
DNS-beveiliging: Schadelijke DNS-query's blokkeren, DNS-exfiltratie voorkomen en netwerkfiltering op basis van FQDN inschakelen.

Wie heeft dit artikel nodig

Lees dit artikel als u:

Implementeer privé-eindpunten (indien van toepassing op uw scenario) en heb workloads nodig om DNS-zones correct op te lossen privatelink.* .
Beheer hybride omgevingen waarin on-premises systemen private Azure-namen moeten kunnen oplossen (of omgekeerd).
Gebruik Azure Firewall en hebt op FQDN gebaseerde filtering in netwerkregels nodig.
Dns-query's naar bekende schadelijke domeinen op de resolutielaag blokkeren.
Beheer omgevingen met meerdere VNet's waarbij gecentraliseerde DNS-omzetting bewerkingen vereenvoudigt.
Plan de DNS-architectuur voor hub-spoke-topologieën met gedeelde services.

Lift-and-shiftfocus: Behoud het bestaande DNS-naamgevingsgedrag tijdens de migratie. Gebruik bidirectioneel doorsturen tussen on-premises DNS en Azure, configureer voorwaardelijke doorstuurservers voor split-horizon-resolutie en host Azure privénamen in Privé-DNS zones, zodat toepassingen hun huidige DNS-configuratie behouden.

Focus op modernisering: Centraliseer naamresolutie terwijl u workloads naar een nieuw platform migreert. Gebruik Azure DNS Private Resolver met doorstuurregelsets voor hybride omzetting, integreer Privé-DNS zones met privé-eindpunten voor PaaS-services en schakel de Azure Firewall DNS-proxy in, zodat op FQDN gebaseerde regels en DNS-omzetting één pad in de cache delen.

Focus op meerdere cloudomgevingen: Plan de DNS-cutover tussen cloudomgevingen vóór de workloadmigratie. Gebruik Azure DNS Private Resolver voor naamresolutie tussen clouds, configureer voorwaardelijke doorsturing met AWS Route 53 Resolver of Google Cloud DNS en verlaag de TTL-waarden vóór de omschakeling om het risico op verouderde cachegegevens te verminderen.

Azure services en functies

In de volgende tabel worden de Azure services en functies beschreven die betrokken zijn bij DNS-beveiliging en privénaamomzetting.

Service/functie	Purpose	Belangrijkste functionaliteit	Wanneer gebruiken
Azure DNS (openbare zones)	Gezaghebbende hosting voor openbare domeinnamen	Wereldwijd anycast-netwerk, Azure RBAC-integratie, aliasrecords voor Azure-resources	U bent eigenaar van een openbaar domein en wilt DNS-records hosten in Azure met hoge beschikbaarheid.
Azure DNS-zones voor privégebruik	Naamresolutie binnen virtuele netwerken zonder openbare toegang	VNet-koppeling, automatische registratie van VM-hostnamen, privatelink-zonehosting	Interne naamresolutie voor Azure workloads. Vereist voor DNS-integratie met privé-eindpunten.
Azure DNS Private Resolver	DNS-doorsturen tussen Azure en externe netwerken	Binnenkomend eindpunt (on-premises → Azure oplossing), uitgaand eindpunt (Azure → on-premises doorsturen), regelsets voor doorsturen	Hybride omgevingen die bidirectionele DNS-omzetting nodig hebben zonder aangepaste DNS-VM's te implementeren.
AZURE FIREWALL DNS-proxy	Gecentraliseerde DNS-onderschepping voor FQDN-filtering	Dns-antwoorden in de cache opslaan, op FQDN gebaseerde netwerkregels inschakelen, biedt één DNS-eindpunt voor spoke-VNets	U implementeert Azure Firewall en u hebt FQDN-filtering in netwerkregels nodig. Vereist voor consistente FQDN-resolutie.
DNS-beveiligingsbeleid	Bedreigingsbeveiliging op de DNS-laag	Oplossing van bekende schadelijke domeinen blokkeren met behulp van Microsoft Threat Intelligence-feed	U wilt voorkomen dat workloads verbinding maken met opdracht- en beheer- of malwaredistributiedomeinen.

Concepten van Privé-DNS-zones

Privé-DNS zones bieden naamomzetting voor gekoppelde virtuele netwerken zonder records beschikbaar te maken op internet. Belangrijkste gedragingen:

VNet-koppeling: U kunt een privé-DNS-zone koppelen aan meerdere VNets. Alle resources in gekoppelde VNets kunnen records in de zone oplossen.
Automatische registratie: Wanneer deze optie is ingeschakeld op een VNet-koppeling, maakt Azure automatisch A-records voor virtuele machines die in dat VNet zijn geïmplementeerd. Azure records verwijdert wanneer u de toewijzing van VM's ongedaan wilt maken of verwijderen. Automatische registratie werkt alleen voor VM's (alleen primaire NIC). Een VNet kan zich automatisch registreren bij slechts één privé-DNS-zone, maar u kunt meerdere VNets koppelen aan dezelfde zone.
PRIVÉ-eindpunt-DNS: voor Azure services die toegankelijk zijn via privé-eindpunten, zijn specifieke privélink-DNS-zones vereist (bijvoorbeeld privatelink.blob.core.windows.net voor Azure Blob Storage). Zonder de juiste zone lossen clients het openbare IP-adres op in plaats van het privé-eindpuntadres.

Architectuur van DNS Private Resolver

Azure DNS Private Resolver vervangt de behoefte aan aangepaste VIRTUELE DNS-machines in hybride doorstuurscenario's. In het volgende diagram ziet u de stroom van hybride DNS-omzetting van on-premises via Azure DNS Privé-resolver naar een PRIVÉ-eindpunt-IP-adres.

De resolver maakt gebruik van twee eindpunttypen:

Inkomend eindpunt: Biedt een IP-adres dat on-premises DNS-servers kunnen gebruiken als een conditionele doorstuurserver. Azure DNS beantwoordt query’s die naar dit IP-adres worden verzonden (inclusief gekoppelde privé-DNS-zones). Vereist een toegewezen subnet dat is gedelegeerd aan Microsoft.Network/dnsResolvers.
Uitgaand eindpunt: Hiermee kunnen Azure workloads DNS-query's doorsturen naar on-premises DNS-servers, andere cloudproviders of externe resolvers. Hiervoor is ook een toegewezen subnet vereist. Regelsets voor doorsturen die zijn gekoppeld aan het uitgaande eindpunt bepalen welke domeinachtervoegsels moeten worden doorgestuurd en welke DNS-doelservers moeten worden gebruikt.

Important

Voor binnenkomende en uitgaande eindpunten is elk hun eigen toegewezen subnet vereist. U kunt geen andere resources implementeren in deze subnetten. Een VNet dat is gekoppeld aan een regelset voor doorsturen hoeft niet te worden gekoppeld aan het VNet van de resolver. Regelsetkoppelingen werken onafhankelijk van VNet-peering.

Hoe te kiezen

Gebruik de volgende beslissingsstructuur om de juiste DNS-onderdelen voor uw omgeving te selecteren.

Beslissingsstructuur

Gebruikt u privé-eindpunten?
- Ja → Privé-DNS zones implementeren met de juiste privatelink.* zonenamen. Koppel zones aan VNets die private-endpuntadressen moeten kunnen oplossen.
Moeten on-premises systemen Azure-privénamen omzetten?
- Ja → DNS Private Resolver implementeren met een binnenkomend eindpunt. Configureer on-premises DNS-servers met voorwaardelijke doorstuurservers die verwijzen naar het IP-adres van het binnenkomende eindpunt.
Moeten Azure-workloads on-premises namen kunnen omzetten in IP-adressen?
- Ja → DNS Private Resolver implementeren met een uitgaand eindpunt. Regelsets voor doorsturen maken voor on-premises domeinachtervoegsels (bijvoorbeeld corp.contoso.com).
Implementeert u Azure Firewall en hebt u FQDN-filtering in netwerkregels nodig?
- Ja → de DNS-proxy van de firewall inschakelen. Configureer spoke-VM's voor het gebruik van het privé-IP-adres van de firewall als hun DNS-server.
Wilt u DNS-query's blokkeren voor bekende schadelijke domeinen?
- Ja → DNS-beveiligingsbeleid inschakelen met Microsoft Threat Intelligence-feed op de doel-VNets.

Algemene patronen

Patroon	Onderdeel	Gebruiksituatie
Alleen resolutie van privé-eindpunten	Privé-DNS zones + VNet-koppelingen	Workloads met alleen cloudtoegang tot PaaS-services via privé-eindpunten. Geen hybride connectiviteit.
Hybride bidirectionele resolutie	Privé-DNS zones + DNS Private Resolver (inkomend + uitgaand)	On-premises lost Azure-privénamen op; Azure lost de on-premises Active Directory-namen op.
Gecentraliseerde hub-DNS	Dns Private Resolver in hub VNet + doorstuurregelsets gekoppeld aan spokes	Hub-spoke-topologie waarbij alle DNS-naamomzetting via de hub verloopt voor gecentraliseerde logregistratie en controle.
Firewall-gemediateerde DNS	Azure Firewall DNS proxy + Privé-DNS zones	Omgevingen die firewall gebruiken voor FQDN-filtering. De firewall onderschept DNS, waardoor consistente omzetting van FQDN naar IP voor netwerkregels mogelijk wordt.
Volledige beveiligingsstack	Alle voorgaande opties, plus DNS-beveiligingsbeleid	Bedrijfsomgevingen waarvoor hybride resolutie, FQDN-filtering en beveiliging tegen bedreigingen op DNS-lagen zijn vereist.

Voorbeelden van DNS-zone voor privé-eindpunt

De volgende tabel bevat algemene Azure-services en de vereiste Privé-DNS zonenamen.

Azure-dienst	Privé-DNS zonenaam
Azure Blob Storage (opslagdienst van Azure)	`privatelink.blob.core.windows.net`
Azure SQL Database	`privatelink.database.windows.net`
Azure Key Vault	`privatelink.vaultcore.azure.net`
Azure Files	`privatelink.file.core.windows.net`
Azure Container Registratiedienst	`privatelink.azurecr.io`
Azure Cosmos DB (SQL API)	`privatelink.documents.azure.com`

Note

Zie Azure DNS-configuratie voor privé-eindpunten voor alle Azure-services voor de volledige lijst met Privé-DNS zonenamen.

Prerequisites

Voordat u DNS-beveiliging en privénaamomzetting implementeert, moet u het volgende doen:

Een virtueel netwerk: Alle DNS-functies werken binnen of in virtuele netwerken. Zie Virtuele netwerken en subnetten voor basisrichtlijnen. (F1)
Netwerkconnectiviteit voor hybride scenario's: Inkomende eindpunten van de DNS Private Resolver vereisen netwerkverbinding vanaf on-premises (ExpressRoute of VPN) met het VNet van de resolver.
Toegewezen subnetten voor DNS Private Resolver: Elk eindpunt (inkomend en uitgaand) vereist een eigen subnet dat is gedelegeerd aan Microsoft.Network/dnsResolvers. Plan ten minste een /28 voor elk eindpuntsubnet.
Privé-eindpunten die zijn geïmplementeerd (als u privatelink-zones gebruikt): Privé-DNS zones voor privatelink.* namen bieden alleen waarde wanneer privé-eindpunten bestaan. Zie Privé PaaS-toegang met privé-eindpunten voor implementatierichtlijnen. (C5)
Azure Firewall geïmplementeerd (als u DNS-proxy gebruikt): voor de functie DNS-proxy is een bestaand Azure Firewall-exemplaar vereist. Zie Azure Firewall en verkeersinspectie. (S1)
Machtigingen: Rol DNS Zone Contributor voor het beheren van privé-DNS-zones. Netwerkbijdrager voor implementatie van privé-dns-resolver.

Beveiligingsoverwegingen

DNS introduceert specifieke aanvalsvectoren waarvoor speciale besturingselementen nodig zijn. De volgende secties hebben betrekking op exfiltratierisico's, blokkeren op basis van bedreigingsinformatie, gedrag van de DNS-proxy van de firewall en DNSSEC-beperkingen.

Risico's voor DNS-exfiltratie

DNS-tunneling codeert gegevens in DNS-query's om informatie te exfiltreren via een ander onbeperkt protocol. Omdat de meeste netwerken uitgaande DNS (UDP/TCP 53) toestaan, gebruiken aanvallers DNS als een bedekt kanaal. Beperk dit risico door:

Het inschakelen van Azure Firewall DNS-proxy en het routeren van al het DNS-verkeer via de firewall. De firewall registreert alle DNS-query's, waardoor tunneling kan worden gedetecteerd via analyses.
DNS-beveiligingsbeleid toepassen om de resolutie te blokkeren van domeinen die zijn gekoppeld aan bekende exfiltratiehulpprogramma's en command-and-control-infrastructuur.
Dns-querypatronen in Azure Monitor controleren op afwijkingen, zoals ongebruikelijk lange subdomeinlabels, grote queryvolumes naar één domein of query's naar onlangs geregistreerde domeinen.

DNS-beveiligingsbeleid

DNS-beveiligingsbeleid met Microsoft Threat Intelligence blokkeert DNS-omzetting naar bekende schadelijke domeinen op VNet-niveau. Wanneer een workload een domein probeert op te lossen dat is gemarkeerd door Microsoft Security Response Center (MSRC), blokkeert het beleid de oplossing voordat een netwerkverbinding plaatsvindt. Dit besturingselement werkt onafhankelijk van Azure Firewall en vereist geen wijzigingen in afzonderlijke workloadconfiguraties.

Belangrijkste kenmerken:

Maakt gebruik van Microsoft Threat Intelligence-feed die afkomstig is van MSRC.
Werkt op de DNS-resolutielaag: blokkeert de query, niet het verkeer.
Toegepast per VNet: schakel dit in voor alle VNets die workloads bevatten die toegang hebben tot internet.
Verschilt van firewall-FQDN-filtering: DNS-beveiligingsbeleid blokkeert wereldwijd schadelijke domeinen zonder dat er firewallimplementatie is vereist.

Firewall DNS-proxy en FQDN-filtering

Azure Firewall DNS-proxy is vereist voor filteren op basis van FQDN in netwerkregels. Zonder DNS-proxy kunnen DNS-aanvragen van client-VM's op andere momenten worden opgelost dan de naamomzetting door de firewall, wat leidt tot inconsistente IP-naar-FQDN-toewijzingen en regelconflicten.

Wanneer u DNS-proxy inschakelt:

Configureer spoke-VM's voor het gebruik van het privé-IP-adres van de firewall als hun DNS-server.
De firewall verwerkt query’s namens clients en slaat de resultaten op in de cache (positieve cache tot 1 uur, negatieve cache tot 30 minuten).
FQDN-to-IP-koppelingen worden elke 15 seconden vernieuwd. De firewall verwijdert verouderde vermeldingen na 15 minuten.
Toepassingsregels (L7) gebruiken SNI (Server Name Indication) voor FQDN-overeenkomsten en vereisen geen DNS-proxy. Netwerkregels (L4) vereisen een DNS-proxy voor FQDN-naamomzetting.
FQDN-filtering in netwerkregels ondersteunt alleen exacte domeinovereenkomsten. Jokertekenpatronen worden niet ondersteund in FQDN's voor netwerkregels. Gebruik toepassingsregels voor FQDN-overeenkomsten met jokertekens.

Note

Als alle geconfigureerde upstream-DNS-servers niet meer beschikbaar zijn, valt Azure Firewall DNS-proxy niet terug op een alternatieve resolver. DNS-omzetting mislukt totdat ten minste één upstream-server wordt hersteld. Plan de redundantie van de DNS-server in uw upstream-configuratie.

Caution

Als u DNS-proxy inschakelt, maar client-VM's niet configureert voor het gebruik van de firewall als hun DNS-server, werken netwerkregels op basis van FQDN niet correct. Clients en firewall kunnen verschillende IP-adressen voor dezelfde FQDN oplossen, waardoor onverwacht verkeer afneemt.

DNSSEC-beperkingen

Azure DNS biedt momenteel geen ondersteuning voor DNSSEC-validatie voor privézones. Openbare zones die worden gehost in Azure DNS ondersteuning bieden voor DNSSEC-ondertekening voor gezaghebbende antwoorden, maar recursieve omzetting binnen Azure virtuele netwerken voert geen DNSSEC-validatie uit. Als uw beveiligingsvereisten DNSSEC-validatie verplicht stellen, evalueert u met behulp van een aangepaste DNS-resolver die ondersteuning biedt voor validatie of implementatie van verificatie op toepassingslaag.

Ontwerpoverwegingen

Focus op lift-and-shift-DNS-ontwerp

Configureer bidirectioneel DNS-doorsturen tussen on-premises DNS-servers en Azure DNS Private Resolver.
Gebruik conditionele forwarders, zodat on-premisesquery's voor in Azure gehoste namen in Azure worden opgelost en Azure-query's voor on-premisesnamen via uw bestaande DNS-infrastructuur worden opgelost.
Maak privé-DNS-zones voor elke Azure-service die door gemigreerde workloads wordt gebruikt, met name services die gebruikmaken van Private Endpoint.
Behoud tijdens de migratie het DNS-gedrag van toepassingen door aliasrecords of CNAME-records te gebruiken in plaats van de resolverinstellingen van clients te wijzigen.

Focus op DNS-ontwerp moderniseren

Centraliseer DNS-resolutie in de hub met behulp van Azure DNS Private Resolver met doorstuurregelsets die worden gedeeld in virtuele spoke-netwerken.
Koppel Privé-DNS-zones aan elke PaaS-service die gebruikmaakt van een Private Endpoint, zodat geherplatformde workloads privatelink-namen automatisch kunnen omzetten naar IP-adressen.
Schakel de Azure Firewall DNS-proxy in, zodat netwerkregels op basis van FQDN en de DNS-resolutie van de werkbelasting een consistent, in de cache opgeslagen omzettingspad gebruiken.
Gebruik automatische registratie en Azure RBAC op Privé-DNS zones om handmatig recordbeheer te verminderen wanneer u infrastructuur als code in gebruik neemt.

Focus voor DNS-ontwerp in meerdere clouds

Gebruik Azure DNS Private Resolver als controlepunt voor doorsturen voor naamresolutie tussen clouds onderling.
Configureer conditioneel doorsturen tussen Azure Private DNS, AWS Route 53 Resolver en Google Cloud DNS voor elke private naamruimte die tussen omgevingen moet worden opgelost.
Plan de DNS-omschakeling gefaseerd: verlaag de TTL-waarden, controleer doorstuurpaden, wijzig CNAME- of A-records en bewaak querylatentie en cachegedrag.
Pas DNSSEC toe op gezaghebbende zones waar de verbonden platforms deze ondersteunen en documenteer waar privéomzettingspaden DNSSEC niet valideren.

Privé-PaaS-toegang met privé-eindpunten: Privé-eindpunten implementeren en PRIVÉlink-DNS-zones configureren.
Azure Firewall en verkeersinspectie: DNS-proxyconfiguratie van de firewall en FQDN-filtering.
Virtuele netwerken en subnetten: basisinformatie over VNet's, waaronder subnetplanning voor DNS-resolver-eindpunten.
Hub-spoke-netwerktopologie: Gecentraliseerde DNS-resolutie in hub-spoke-architecturen.
Ontwerpfasen in één oogopslag: op fase gebaseerde samenvatting van planning, connectiviteit, beveiliging en operationele beslissingen.

Meer informatie

Volgende stappen

Tip

Zelf verkennen? Ga terug naar de overzichtsnavigator om uw volgende artikel per mogelijkheid te vinden.

De volgende stap in uw lift-and-shift-traject:

Uitgaand internetverkeer beheren: centraliseer alle uitgaande communicatie via Azure Firewall en schakel standaard uitgaande toegang uit.

Vervolgens in uw moderniseringstraject:

Productiebewaking instellen: schakel Network Watcher en netwerk-Performance Monitor in voor productiegereedheid vanaf dag één.

De volgende stap in uw cross-cloudtraject:

Beveilig uw cross-cloudovergangspad: implementeer Azure Firewall in uw beveiligde virtuele hub om al het verkeer tussen clouds, vertakkingen en internetverkeer te inspecteren.

Feedback

Is deze pagina nuttig?

Last updated on 2026-07-01