DNS Forwarding Rulesets

DNS Forwarding Rulesetsを理解するための前提

DNS forwarding rulesetはdomain suffixごとにtarget DNS serverを指定するconditional forwarding policy。outbound endpointと関連付けてAzureから外部へqueryを送る。 VNetへrulesetをlinkすると、そのVNetのresourceはAzure-provided DNS経由でrulesを利用できる。resolver VNetとpeeringしていなくてもruleset link自体は機能する。

複数ruleがmatchするとlongest suffixが選ばれる。親domainと子domainで別targetを使う場合、具体的なquery nameでmatchingを検証する。 current limitsはrulesetあたり最大1,000 forwarding rules、最大500 VNet links、最大2 outbound endpoints、ruleあたり最大6 target DNS servers。

rulesetは同じregionのVNetへlinkする。cross-tenant ruleset linkingはcurrent restrictionsで非対応。 hub inbound endpointをforward先にするdistributed designでは、そのinbound endpointと同じhub VNetへ同じrulesetをlinkするとDNS loopになり得る。

通信や判断の流れを追う

ClientDNS queryResolver / Private DNSPrivate endpointService

Control plane / DNS plane / Data plane

Rule

domainName + target DNS server(s) + port/protocol + enabled state。suffixごとのforward action。

Ruleset

rule集合とoutbound endpoint associationを保持するregional policy object。

VNet link

そのVNetのAzure-provided DNS queryにruleset評価を適用するassociation。network peeringとは別。

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

Query / packet path

client queryがAzure-provided DNSへ入る。
linked Private DNS zoneにmatchしない場合、VNetにlinkされたrulesetを評価する。
query nameとforwarding ruleのsuffixを比較し、最もspecificなmatchを選ぶ。
matching ruleのtarget DNS serverへoutbound endpointからqueryを送る。
targetのresponseをclientへ返す。
matchがなければforwardせずAzure DNSの通常resolutionへ戻る。

仕組みを分解する

rulesetはrouting tableに似ていますがIP prefixではなくDNS suffixをmatchします。`contoso.com.` と `dev.contoso.com.` の両ruleがある場合、`api.dev.contoso.com`はよりspecificな後者へ送られます。障害時は「ruleがある」だけでなく、client VNetがそのrulesetにlinkされているか、ruleがEnabledか、outbound endpoint associationがあるか、target resolverがrecursive answerを返すかを順に確認します。

設計判断

判断軸	設計方針
Suffix granularity	root domainへ広いruleを作り過ぎず、authority/ownershipに沿って最小suffixをforwardする。
Target redundancy	複数target DNS serverを登録する場合、全targetが同じzone viewを返すか、failover時にsplit-brainしないか確認する。
Distributed use	spokeにruleset linkを配布するmodelではVNet DNS settingをDefaultに保ち、custom DNSとの二重policyを避ける。
Loop prevention	inbound endpointへ戻すrule、on-prem forwarderから再びAzureへ戻るruleをdiagramで可視化し、cycleを禁止する。

確認手順

Read-only verification

rulesetのoutbound endpoint IDs、rule一覧、VNet linksを1つのsnapshotへまとめる。
親/子suffixそれぞれのtest FQDNをqueryし、longest-suffix selectionを確認する。
target DNSへUDP/TCP 53が到達し、recursive answerを返すことをresolver側log/packetで確認する。
hub/spoke/on-premのquery pathを矢印で描き、同一queryが元のresolverへ循環しないことを確認する。

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 dns-resolver forwarding-ruleset show -g <rg> -n <ruleset> -o jsonc
az dns-resolver forwarding-rule list -g <rg> --ruleset-name <ruleset> -o jsonc
az dns-resolver vnet-link list -g <rg> --ruleset-name <ruleset> -o jsonc
az dns-resolver outbound-endpoint list -g <rg> --dns-resolver-name <resolver> -o jsonc

PowerShell — read-only first

Get-AzDnsForwardingRuleset -ResourceGroupName <rg> -Name <ruleset>
Get-AzDnsForwardingRule -ResourceGroupName <rg> -DnsForwardingRulesetName <ruleset>
Get-AzDnsForwardingRulesetVirtualNetworkLink -ResourceGroupName <rg> -DnsForwardingRulesetName <ruleset>

障害切り分け

症状	第一候補	証拠	次の確認
ruleset作成済みだが使われない	VNet linkなし	ruleset vnet-link list	対象VNetをlink
wrong DNS serverへforward	more-specific rule	rule suffix一覧	longest match修正
SERVFAILが周期的	target間answer差/timeout	target別dig/nslookup	target DNS健全性修正
hubだけSERVFAIL	inbound forward rule loop	hub link + rule target	same-hub loop除去
別region VNetへlink不可	regional restriction	VNet/ruleset location	region別design

変更時の確認と rollback

rule変更前にdomainName/targets/stateをexportする。
rule削除よりdisableを先に使える変更では、影響確認後にcleanupする。
VNet link切替はclient cacheを考慮し、representative queryで新旧pathを比較する。
rollback後はtarget別packet evidenceまで取り、単にPortal resourceが戻っただけで完了にしない。

Current notes — 2026-09-11

Current behavior / guidance

2026-09-11時点のofficial overviewではrulesetのscale limitsとlongest-suffix evaluationが明記されています。古いVM forwarder設計から移行する際は、IP routingではなくsuffix policyのdistributionとして設計し直します。