Private Endpoint DNS

Private Endpoint DNSを理解するための前提

Private Endpoint利用でもapplicationは通常serviceの既存FQDNを使う。DNS構成により最終的なanswerをPE private IPへ切り替える。 Azure serviceごとに推奨Private DNS zone名とtarget subresourceが異なる。Storageならblob/file/dfs等を別々に確認する。

Private DNS zone groupはPEとPrivate DNS zoneを関連付け、PE更新時のrecord管理を自動化する。手動A recordの寄せ集めよりlifecycleを追いやすい。同名Private DNS zoneをVNetごとに量産するとrecord setが分断される。共通resolver pathでは必要なPE recordを同じauthorityから返せるよう設計する。

on-premisesからAzure Private DNSを解決するには、Azure内のDNS forwarderまたはDNS Private Resolver inbound endpointへconditional forwardする。on-premから168.63.129.16を直接queryしない。 DNSがprivate IPを返すことはroute/securityの成功を保証しない。名前解決とpacket pathを分離して検証する。

通信や判断の流れを追う

ClientDNS queryResolver / Private DNSPrivate endpointService

Control plane / DNS plane / Data plane

Public namespace

例: account.blob.core.windows.net。public DNSはservice固有CNAME chainを返し、Private Link有無だけでInternet全体のpublic recordが消えるわけではない。

Private Link zone

例: privatelink.blob.core.windows.net。linked VNet/Resolver pathからPE用A recordを返すprivate authority。

Client resolver path

Azure-provided DNS、custom DNS、Private Resolver、on-prem conditional forwarderのどれをclientが実際に使うかでanswerが変わる。

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

Query / packet path

clientがserviceの通常FQDNをresolverへ問い合わせる。
public DNS chainでservice固有のprivatelink namespaceへのCNAMEが現れる。
query sourceがPrivate DNS zoneを解決できるpathにいる場合、privatelink zoneのA recordがPE private IPを返す。
clientは最終answerのprivate IPへTCP/UDPを開始する。
Private Endpoint subnetへのroute/NSG/UDRとPrivate Link connectionがdata planeを処理する。
zoneが見えないsourceではpublic answerへ戻り得るため、「場所別のDNS差」を意図したsplit-horizonとして管理する。

仕組みを分解する

DNS障害では「A recordがあるか」だけでなく、clientがどのresolverへ問い合わせ、そのresolverがどのzoneをauthorityとして参照するかを追います。Private DNS zoneが正しくてもVNet linkがない、custom DNSがlinked zoneを参照しない、on-prem conditional forwarderが誤った宛先を向く、といった構成ではPEのprivate IPは返りません。逆に、active public zone名をprivate zoneで丸ごとoverrideすると、そのprivate zoneに存在しないpublic resourceまでNXDOMAIN/誤answerになるため、Microsoft推奨のservice別privatelink zone名を基準にします。

設計判断

判断軸	設計方針
Zone catalog	resource type / groupId / recommended private zone / public forwarder namespaceを表で管理し、service追加時にreviewする。
Zone group ownership	PE deploymentとprivateDNSZoneGroupをIaC/Policyで同一lifecycleにし、手動record driftを減らす。
Spoke strategy	各spokeを同一zoneへlinkする方式と、hub zone + Resolver ruleset方式を明示的に選ぶ。両方を混在させるならquery pathを図示する。
On-prem strategy	conditional forwarderはAzure private namespaceをPrivate Resolver inbound IPへ送り、public DNSまで巻き込む過剰なforward zoneを避ける。

確認手順

Read-only verification

同一FQDNをAzure client、別spoke、on-prem clientから照会し、CNAME chainと最終A/AAAAを保存する。
Private DNS zoneのVNet link state、zone group、A recordのIPがPE IPと一致するか照合する。
custom DNS利用VNetではVNet DNS settingとconditional forwarder/rulesetを確認する。linked zoneがあるだけではcustom DNSが自動で参照するとは限らない。
DNS修正後はclient/OS/application cacheのTTL影響を考慮し、新規queryと新規connectionで再確認する。

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 private-endpoint dns-zone-group list -g <rg> --endpoint-name <private-endpoint> -o jsonc
az network private-dns zone show -g <dns-rg> -n <privatelink-zone> -o jsonc
az network private-dns link vnet list -g <dns-rg> -z <privatelink-zone> -o table
az network private-dns record-set a list -g <dns-rg> -z <privatelink-zone> -o table
nslookup <service-fqdn>
nslookup <service-fqdn> <resolver-ip>

PowerShell — read-only first

Get-AzPrivateDnsZoneGroup -ResourceGroupName <rg> -PrivateEndpointName <private-endpoint>
Get-AzPrivateDnsZone -ResourceGroupName <dns-rg> -Name <privatelink-zone>
Get-AzPrivateDnsVirtualNetworkLink -ResourceGroupName <dns-rg> -ZoneName <privatelink-zone>

障害切り分け

症状	第一候補	証拠	次の確認
Azure VMはprivate、on-premはpublic	conditional forwarding不足	resolver別nslookup	on-prem→inbound endpoint pathを構成
一部spokeだけNXDOMAIN	zone link/ruleset link不足	VNet link一覧/ruleset link	不足linkを追加
同名serviceのrecordが消える/競合	同名zoneの分散/zone group設計不整合	zone resource IDとPE zone group	authorityを統合しlifecycleを一本化
public serviceまでNXDOMAIN	active public zoneをprivateでoverride	SOA/authorityとrecord一覧	推奨privatelink zoneへ修正
DNSはprivateだが接続不可	DNS以外のdata plane	private IPへのroute/NSG/TCP test	routing/security/service authへ切替

変更時の確認と rollback

DNS変更前にresolver別answer、TTL、zone/link/zone group inventoryを保存する。
zone groupを外す場合、Azure管理recordが削除される可能性を想定し、手動recordへ安易に切り替えない。
同名private zone統合作業はTTL/cacheと移行順序を設計し、全spokeを一度に切り替えない。
rollback完了は「元のA recordが戻った」ではなく、代表clientのFQDN接続が元pathへ戻ったことまで確認する。

Current notes — 2026-09-11

Current behavior / guidance

Microsoft LearnはPrivate Endpoint DNSをservice別zone値とDNS integration scenarioに分けて更新しています。2026-09-11時点でも、private endpoint導入時は対象serviceの最新subresource/Private DNS zone mappingを都度参照する設計が安全です。