Centralized DNS Architecture

Centralized DNS Architectureを理解するための前提

centralized DNS modelではspoke VNetのcustom DNS serverとしてhubのPrivate Resolver inbound endpoint IP等を指定し、spoke DNS trafficをhubへ集約する。 hub VNetをPrivate DNS zoneへlinkすれば、hub inbound endpoint経由でspokeからそのzoneを解決できる。spokeをzoneへ直接linkする必要がないmodelを構成できる。

hubにoutbound endpoint/rulesetを追加してon-prem domainへforwardできる。spokeから来たqueryもhub contextで同じrulesを利用する。 hub inbound endpointへforwardするprivate-zone ruleを、同じhubへlinkされたrulesetに作るとquery loopになり得る。centralized modelではprivate zoneはhub linkで直接resolveする。

centralized modelはDNS policy/inspectionを集約しやすい反面、hub DNS pathへの依存とblast radiusが増える。region/failure domainを明示する。 Azure Firewall DNS proxyを使う場合はclient→Firewall→Private Resolver/upstreamの順序と、Firewall自身のupstream DNS設定を同じ図に含める。

通信や判断の流れを追う

ClientDNS queryResolver / Private DNSPrivate endpointService

Control plane / DNS plane / Data plane

Spoke client plane

VNet custom DNSとしてhub VIP/Firewall private IP等を設定し、全queryをcentral pathへ送る。

Hub resolution plane

Private Resolver inboundがlinked Private DNS zonesを解決し、必要suffixはoutbound rulesetへ渡す。

External authority

on-prem DNS/public DNS/other cloud DNS。hub outbound rulesが必要なsuffixだけをforwardする。

判定順序まず client がどの resolver を使い何IPを得たか固定し、そのIPに対するroute/securityを確認します。DNSを確認せずroute tableだけを見る、またはprivate IPを得ただけでservice到達済みと判定するのは避けます。

Query / packet path

spoke clientがDNS queryをVNet custom DNS IPへ送る。
custom DNSがhub inbound endpointならPrivate Resolverがqueryを受ける。Firewall DNS proxyならFirewallがupstreamへproxyする。
hubにlinkされたPrivate DNS zoneにmatchするnameはAzure DNSで解決する。
on-prem suffix等がrulesetにmatchすればoutbound endpointからtarget DNSへforwardする。
その他はAzure DNS/public resolutionへ進む。
responseが同じcentral pathを戻りspoke clientへ返る。

仕組みを分解する

Centralizedとdistributedの違いは「Resolver resourceをhubに置くか」ではありません。両方hubにResolverを置けます。distributedではspokeがAzure-provided DNSを使い、ruleset linkを各spokeへ配布します。centralizedではspoke VNet DNS settingをhub inbound IP等へ変え、全queryをhubへ送ります。どちらを採用したかをVNet DNS settingとruleset linksから判定できるようにします。

設計判断

判断軸	設計方針
Central vs distributed	central inspection/legacy DNS integrationが必要ならcentralized、spokeのAzure-provided DNSを維持したいならruleset-link distributedを比較する。
Hub HA	single hub/region/inbound IP依存を許容するか、secondary region resolver/forwarderを設計する。
Firewall DNS proxy	FQDN filteringとの整合が必要な場合に使い、Resolver直指定との役割を重複させない。
Change blast radius	VNet custom DNS変更は多数workloadへ即時影響し得る。代表spoke→pilot→waveの順にrolloutする。

確認手順

Read-only verification

spoke VNet DNS settingが期待するhub IPを指すことを確認し、VM OSの古いDHCP/DNS設定も再取得する。
hub Private DNS zone linksとrulesetを確認し、private zone向けloop ruleがないことを静的checkする。
spokeからprivate zone/on-prem/publicの3種類をqueryし、それぞれexpected authority/pathへ行くことを確認する。
hub DNS path failure testを行い、secondary pathまたは明示したRTO/RPOどおりになるか確認する。

Evidence to keep

resource ID / subscription / region / VNet / subnetを固定し、同名resource取り違えを防ぐ。
DNS queryはresolver IP、query name、answer/CNAME、TTL、timestampを一緒に保存する。
network testはsource、resolved destination IP、protocol/port、winning route/security decisionを保存する。
変更前後で同じquery/application journeyを再実行し、cache/既存sessionでの見かけ上成功を避ける。

Azure CLI / client — read-only first

az network vnet show -g <spoke-rg> -n <spoke-vnet> --query "dhcpOptions.dnsServers" -o json
az dns-resolver inbound-endpoint list -g <hub-rg> --dns-resolver-name <resolver> -o jsonc
az network private-dns link vnet list -g <dns-rg> -z <zone> -o table
az dns-resolver forwarding-rule list -g <hub-rg> --ruleset-name <ruleset> -o table

PowerShell — read-only first

Get-AzVirtualNetwork -ResourceGroupName <spoke-rg> -Name <spoke-vnet> | Select-Object -ExpandProperty DhcpOptions
Get-AzDnsResolverInboundEndpoint -ResourceGroupName <hub-rg> -DnsResolverName <resolver>
Get-AzDnsForwardingRuleset -ResourceGroupName <hub-rg>

障害切り分け

症状	第一候補	証拠	次の確認
全spokeで同時にDNS障害	hub resolver/firewall single path	hub health + DNS target	HA/failoverへ切替
private zoneだけSERVFAIL	same-hub loop	ruleset + zone link	private-zone forward rule除去
一部VMだけ旧DNS	DHCP setting未更新/cache	ipconfig/resolvectl	lease/NIC/OS DNS更新
public DNSだけ遅い	central proxy/upstream bottleneck	query latency/target logs	upstream/Firewall capacity確認
spokeはOK、hub workloadだけ違う	hub自身のDNS setting/ruleset差	VNet DNS + link comparison	hub/spoke policy差を明文化

変更時の確認と rollback

spoke VNet DNS server list変更前に元settingをexportし、wave単位で戻せるようにする。
Firewall DNS proxyを追加/除去する変更はFQDN rule behaviorへの影響も同時に確認する。
hub ruleset/zone linkを変更する前にquery class別のbaselineを取得する。
rollback後はprivate/on-prem/publicの3query classを代表spokeで再試験する。

Current notes — 2026-09-11

Current behavior / guidance

MicrosoftのPrivate Resolver architectureはcentralizedとdistributedを明確に分けています。2026-09-11時点では、centralized modelはspoke custom DNS→hub inbound endpoint、distributed modelはspokeのAzure-provided DNS + ruleset linkとして説明できるため、この差をページ中心に据えます。

Centralized DNS Architecture