オンプレミスから Azure SQL Managed Instance（MI）に接続しようとして「FQDN を引いても IP が出ない」「SSMS でホスト名が見つからない」「TCP 1433 に届かない」と悩んでいないでしょうか。多くの場合、原因はネットワークではなく DNS 設計です。本記事では、MI を Private Link（Private Endpoint）で閉域公開している前提で、オンプレ／テレワーク環境からの推奨 DNS・ネットワーク構成と、具体的な設定・トラブルシュート方法を詳しく解説します。
症状の整理：Resolve-DnsName で CNAME まで見えるのに IP が出ない
まずは、よくある相談パターンを整理します。
- オンプレ（または閉域クライアント網）から MI の FQDN を
Resolve-DnsNameで引く xxxxx.database.windows.netからxxxxx.privatelink.database.windows.netやworker.vnet.database.windows.netへの CNAME までは見える- しかし、最終的な A レコード（プライベート IP）が返ってこない
- SSMS では「ホストが見つかりません」や「TCP 1433 に接続できません」で失敗
hostsに手動で IP を書くとつながるが、運用・サポート面で非常に不安
つまり、「名前解決の途中までは行けているが、最後の A レコードだけ Azure 内のどこかに閉じていて取れない」状態です。
| 項目 | 状況 |
|---|---|
| クライアント OS | オンプレ Windows / VPN で閉域接続した PC など |
| 接続先 | Azure SQL Managed Instance（Private Endpoint 利用） |
| DNS で見えるもの | *.database.windows.net から *.privatelink.database.windows.net などへの CNAME |
| DNS で見えないもの | 最終的な A レコード（Private Endpoint のプライベート IP） |
| 一時回避策 | hosts で IP を固定すると接続可能（だが非推奨） |
Azure SQL Managed Instance のエンドポイント種類とポートを整理する
DNS の話に入る前に、MI の「どのエンドポイントに」「どのポートで」つなぐ構成なのかを整理しておきます。Azure SQL Managed Instance には主に次の 3 パターンの接続経路があります。
| 接続方式 | エンドポイント種別 | ポート | 到達に必要な経路 | 主な用途 |
|---|---|---|---|---|
| VNet 内からの直接接続 | VNet-local エンドポイント | 1433/TCP | 同一 VNet またはピアリング VNet | アプリ VM や Azure Service からの接続 |
| インターネット経由 | Public Endpoint | 3342/TCP | インターネット＋ NSG / FW による厳格な制限 | VPN を用意できない開発・検証など |
| Private Link 経由 | Private Endpoint | 1433/TCP（Proxy 方式） | VPN / ExpressRoute / P2S VPN などの私設経路 | オンプレやテレワークからの閉域接続 |
本記事で扱うのは 3 つ目、「Private Endpoint（Private Link）」に対してオンプレから接続したいケースです。Private Endpoint は Azure VNet 上のプライベート IP でのみ公開されるため、インターネットから直接到達することはできません。必ず Site-to-Site VPN、ExpressRoute、もしくは Point-to-Site VPN のようなプライベートなネットワーク接続が必要になります。
なぜ FQDN から A レコードが引けないのか：CNAME の先は Azure の Private DNS ゾーン
現象の本質はシンプルです。
- クライアントは MI の FQDN（例：
mimi.abcd1234.database.windows.net）を問い合わせる - Public DNS は、その FQDN に対して
....privatelink.database.windows.netやworker.vnet.database.windows.netへの CNAME を返す - しかし、その CNAME の最終 A レコードは Azure の「Private DNS ゾーン」にのみ存在する
- オンプレ DNS は Azure 内の Private DNS ゾーンにアクセスできないため、CNAME の先で「行き止まり」となる
Private Endpoint を作成すると、Azure では対応する Private DNS ゾーン（例えば privatelink.<dns-zone>.database.windows.net）に A レコードが作成され、その名前を Private Endpoint のプライベート IP に解決できるようにします。ところが、このゾーンは Azure の仮想ネットワークに閉じており、そのままではオンプレ DNS から見えません。
つまり、「Public DNS が知っているのは CNAME まで」「Private DNS が知っているのは最後の A レコード」であり、オンプレ DNS から見ると CNAME の途中で分断されている構図になります。
推奨アーキテクチャの全体像
このギャップを埋めるための推奨パターンは次のような構成です。
- オンプレ DNS：条件付きフォワーダーを設定し、
database.windows.net宛の問い合わせを Azure に転送する - Azure：Azure DNS Private Resolver（もしくは DNS フォワーダー VM）で問い合わせを受け、Private DNS ゾーンに解決させる
- Private DNS ゾーン：
privatelink.<dns-zone>.database.windows.netなどを作成し、Private Endpoint の A レコードを持たせる - ネットワーク：オンプレと Azure VNet を VPN/ExpressRoute/P2S VPN などで閉域接続する
オンプレ クライアント
↓ (クエリ: <mi-name>.<dns-zone>.database.windows.net)
オンプレ DNS
↓ (条件付きフォワーダー: database.windows.net)
Azure DNS Private Resolver（Inbound Endpoint）
↓
Private DNS ゾーン (privatelink.<dns-zone>.database.windows.net)
↓
Private Endpoint のプライベート IP
Azure DNS Private Resolver は、Azure Private DNS ゾーンとオンプレ DNS の「橋渡し」を行うマネージドサービスです。Inbound Endpoint にプライベート IP が割り当てられるので、オンプレ DNS の条件付きフォワーダーの転送先にこの IP を指定することで、オンプレから Azure の Private DNS ゾーンを参照できるようになります。
DNS 設計の要点：どのドメインをどこに転送するか
条件付きフォワーダーは privatelink.… ではなく database.windows.net に向ける
よくある誤解が、「Private Endpoint だから privatelink.database.windows.net をフォワードすればよい」という設計です。実際には、database.windows.net を条件付きフォワードするのが推奨です。
- クライアントは最初に
<mi-name>.<dns-zone>.database.windows.netを引く - ここで CNAME の連鎖が始まるため、最初のゾーン
database.windows.netを Azure に任せる必要がある privatelink.database.windows.netだけをフォワードしても、CNAME チェーンの出発点がオンプレ DNS で止まり、正しく解決できない
Microsoft 公式の Private Endpoint DNS 解説でも、「条件付きフォワーダーは privatelink.… ではなく Public DNS のゾーン名（例：database.windows.net）を対象にせよ」と明示されています。
MI 用 Private DNS ゾーンのパターンを理解する
Azure SQL Managed Instance の Private Endpoint 用 Private DNS ゾーンは、次のようなパターンになります。
| 構成パターン | 推奨 DNS ゾーン名 | ポイント |
|---|---|---|
| MI と Private Endpoint が別 VNet | privatelink.<dns-zone>.database.windows.net | このゾーンを Private Endpoint 側 VNet（＋必要な VNet）にリンクし、<mi-name> の A レコードを Private Endpoint の IP で作成する |
| MI と Private Endpoint が同一 VNet | 別名の Private DNS ゾーン（例：mi.contoso.local など） | MI が内部で利用する privatelink.<dns-zone>.database.windows.net を上書きしないよう注意。クライアント側は HostNameInCertificate を適切に設定する |
MI と Private Endpoint が別 VNet の場合は、ドキュメントに従い privatelink.<dns-zone>.database.windows.net ゾーンを作成し、そこに A レコードを持たせるのが基本パターンです。一方、同一 VNet に Private Endpoint を置く場合にこのゾーン名で Private DNS ゾーンを作ると、MI の内部通信や管理機能が使っている名前解決を上書きしてしまい、管理操作が失敗することがあるため注意が必要です。
MI が動作する VNet で *.database.windows.net を上書きしない
もう一つの重要な注意点は、MI が存在する VNet 内で database.windows.net の解決方法を勝手に変えないことです。Managed Instance は、管理プレーンとの通信や内部コンポーネント間の通信にも *.database.windows.net を利用しています。このゾーンをカスタム DNS で上書きすると、バックアップ・パッチ適用・スケールなどの管理操作が不安定になる可能性があります。
手を動かす：最小構成の具体的な手順
ここからは、代表的なシナリオとして「MI と Private Endpoint は別 VNet」「オンプレ DNS は AD DS の DNS サーバー」「Azure DNS Private Resolver を利用」の前提で実装手順を整理します。
1. MI の FQDN と DNS ゾーン名を確認する
- Azure ポータルで MI のリソースを開きます。
- 接続文字列 などの項目から FQDN を確認します（例：
mimi.abcd1234.database.windows.net）。 - このうち、
mimiが MI 名、abcd1234が DNS ゾーン部分になります。
以降の手順では、この abcd1234 を使って privatelink.abcd1234.database.windows.net という Private DNS ゾーンを作成します。
2. Private DNS ゾーンを作成し、Private Endpoint 用の A レコードを登録する
- Azure ポータルで「Private DNS ゾーン」を開き、「作成」をクリックします。
- 名前に
privatelink.abcd1234.database.windows.netを指定し、リソースグループとリージョンを選択して作成します。 - 作成したゾーンを開き、「仮想ネットワークリンク」から Private Endpoint がある VNet（＋ DNS Private Resolver を配置するハブ VNet）をリンクします。
- MI の Private Endpoint リソースを開き、「ネットワークインターフェイス」からプライベート IP アドレス（例：
10.10.1.4）を控えます。 - Private DNS ゾーンに戻り、「レコードセットの追加」で以下のように A レコードを作成します。
- 名前：
mimi - 種類：A
- IP アドレス：
10.10.1.4（Private Endpoint の IP）
- 名前：
これで、Azure 内からは mimi.abcd1234.database.windows.net → CNAME → mimi.privatelink.abcd1234.database.windows.net → A レコード（10.10.1.4）という流れで名前解決できるようになります。
3. Azure DNS Private Resolver を展開する
- Private Endpoint が属する VNet からルーティングできる「ハブ VNet」を 1 つ決めます（同じでも可）。
- その VNet に、サブネット
AzureDnsSubnetなどを作成します（/28 以上）。 - 「Azure DNS Private Resolver」を作成し、先ほどのサブネットを紐づけます。
- 作成後、「Inbound Endpoint」を追加し、Inbound 用サブネット に IP を割り当てます（例：
10.20.0.4）。 - Private DNS ゾーン
privatelink.abcd1234.database.windows.netは、必ずこの Resolver が属する VNet にもリンクされていることを確認します。
この 10.20.0.4 がオンプレ DNS が問い合わせる先（条件付きフォワーダーの転送先 IP）になります。
4. オンプレ DNS（Windows Server）の条件付きフォワーダーを設定する
次に、オンプレ側 DNS サーバーに「database.windows.net を Azure に聞きにいく」設定を追加します。
- DNS 管理コンソール（
dnsmgmt.msc）を開きます。 - 左ペインでサーバー名を右クリックし、「条件付きフォワーダー」を選択します。
- 「新しい条件付きフォワーダー」をクリックし、以下を設定します。
- DNS ドメイン：
database.windows.net - 転送先の IP アドレス：
10.20.0.4（Azure DNS Private Resolver の Inbound IP） - 必要に応じて「Active Directory に格納してすべての DNS サーバーにレプリケート」を有効化
- DNS ドメイン：
- 同様に、保険として
privatelink.database.windows.netの条件付きフォワーダーを追加しておくと、他の Private Link 対象サービスとの混在時にも安心です。
BIND を利用している場合は次のようなイメージになります。
zone "database.windows.net" IN {
type forward;
forward only;
forwarders { 10.20.0.4; }; // Azure DNS Private Resolver Inbound IP
};
5. ネットワーク経路（VPN / ExpressRoute / P2S）を確保する
Private Endpoint は Azure VNet のプライベート IP です。オンプレ／自宅 PC から到達させるには、次のいずれかの方法で VNet に閉域接続する必要があります。
| 経路 | 概要 | 向いているシナリオ |
|---|---|---|
| Site-to-Site VPN | オンプレ拠点の VPN ゲートウェイと Azure VPN Gateway を IPsec で接続 | 拠点単位での常時接続 |
| ExpressRoute（Private Peering） | 専用線経由でオンプレと Azure 間のプライベート接続 | レイテンシ要件が厳しい/帯域が大きいシステム |
| Point-to-Site VPN | クライアント PC から Azure VPN Gateway に直接 VPN 接続 | テレワーク端末や一部の管理者のみ接続したい場合 |
加えて、ファイアウォール／NSG では Private Endpoint が属するサブネットに対し、上記経路からの TCP 1433 宛の通信を許可する必要があります。
6. 動作確認：DNS と TCP の両方をチェックする
構成ができたら、オンプレクライアントから次のコマンドで確認します。
Resolve-DnsName mimi.abcd1234.database.windows.net
Test-NetConnection mimi.abcd1234.database.windows.net -Port 1433
Resolve-DnsNameで、最終的に A レコードとして Private Endpoint の IP（例：10.10.1.4）が参照できていることTest-NetConnectionで、ポート 1433 に対してTcpTestSucceeded : Trueとなること
ここまで通れば、SSMS から通常の接続文字列（mimi.abcd1234.database.windows.net）で接続できるはずです。
テレワーク端末からの接続パターン
自宅 PC など、オンプレ LAN にはいないけれど MI へ閉域接続したいケースでは、次のようなパターンが典型です。
| クライアントの位置 | 推奨パターン | ポイント |
|---|---|---|
| 社外ネットワークの PC | PC からオンプレ VPN（社内 LAN）に接続し、そこから Azure へ S2S VPN / ExpressRoute | オンプレ DNS をそのまま利用できるため、DNS 設計を簡潔に保てる |
| 社外ネットワークの PC（オンプレ経由したくない） | PC から Azure の P2S VPN に直接接続 | P2S VPN クライアントの DNS サフィックス・DNS サーバー設定で Azure 側 DNS を利用させる |
テレワーク端末をオンプレに収容するか、Azure に直接ぶら下げるかで、クライアントが参照する DNS が変わります。「オンプレ DNS を参照させたいのか」「Azure 側 DNS（Resolver）を直接参照させたいのか」を決め、どちらか一方に寄せると設計がシンプルになります。
よくあるハマりどころと対処法
privatelink.… だけフォワードしている
最も多いのが、「privatelink.database.windows.net には条件付きフォワーダーを作ったが、database.windows.net には何もしていない」というケースです。この状態では、クライアントが最初に問い合わせる FQDN がオンプレ DNS で完結してしまい、CNAME 連鎖が Azure 側で処理されません。必ず database.windows.net を Azure にフォワードするよう設定を見直してください。
Private DNS ゾーンが Resolver の VNet にリンクされていない
Azure DNS Private Resolver の VNet と、Private DNS ゾーンの「仮想ネットワークリンク」がつながっていないと、Resolver は Private DNS ゾーン内のレコードを参照できません。Resolver の VNet、MI/Private Endpoint の VNet、必要に応じてアプリ側 VNet の 3 つが、いずれも該当 Private DNS ゾーンにリンクされているか確認しましょう。
MI がいる VNet 内で privatelink.<dns-zone>.database.windows.net を自前で作ってしまった
MI のドキュメントには、Private Endpoint を同一 VNet に作成する場合に privatelink.<dns-zone>.database.windows.net ゾーンを自前で作成すると、MI の内部通信・管理操作に影響が出る可能性があると注意書きがあります。MI と Private Endpoint を同一 VNet に置くときは、別名の Private DNS ゾーンを用意し、その名前で接続するようクライアント設定を見直すのが安全です。
ファイアウォール／NSG で 1433/TCP が閉じている
Private Endpoint 経由の MI 接続は、Proxy 方式で常に 1433/TCP を利用します。NSG やオンプレ・クラウド間のファイアウォールで、オンプレから Private Endpoint サブネットへの 1433/TCP が許可されているかを必ず確認してください。
hosts による IP 固定でごまかしている
hosts による IP 固定は「とりあえずつなぐ」目的には役立ちますが、以下の理由から本番運用では非推奨です。
- Private Endpoint の IP はサブネットの再構成や再作成で変わることがある
- 名前解決をバイパスするため、障害時の切り分けが難しくなる
- クライアントが多数存在する場合、配布・更新コストが高くヒューマンエラーの温床
「hosts で動くなら、DNS さえ正しく設計すればきれいに解決できる」はずなので、あくまで検証用に留め、速やかに DNS/ネットワーク設計を是正しましょう。
Public Endpoint を選ぶ場合の注意点
もしどうしても VPN / ExpressRoute 等の閉域接続を用意できない場合、暫定策として MI の Public Endpoint（3342/TCP）を有効化する選択肢もあります。この場合は次の点に注意してください。
- Public Endpoint はインターネットに公開されるため、NSG やファイアウォールで ポート 3342/TCP の送信元 IP を厳格に制限する
- MI 側の接続許可リストやファイアウォール機能で、必要最小限のクライアントのみを許可する
- 接続文字列では、必ず Public Endpoint 用の FQDN とポート 3342 を利用する
Microsoft のセキュリティベストプラクティスでも、MI の Public Endpoint を使う場合は NSG 等で 3342/TCP のアクセス元を限定することが推奨されています。
設計の最終チェックリスト
最後に、本記事のポイントをチェックリストとしてまとめます。新規設計・既存トラブルシュート時の「セルフレビュー」に使ってください。
- オンプレ DNS に
database.windows.netの条件付きフォワーダーが設定されているか - 条件付きフォワーダーの転送先が Azure DNS Private Resolver の Inbound Endpoint（または DNS フォワーダー VM）の IP になっているか
- Private DNS ゾーン
privatelink.<dns-zone>.database.windows.netが作成され、MI の Private Endpoint IP に向けた A レコードが存在するか（別 VNet パターン） - Resolver の VNet、Private Endpoint の VNet、クライアント VNet が必要な Private DNS ゾーンにリンクされているか
- MI が動作する VNet 内で
*.database.windows.netやprivatelink.<dns-zone>.database.windows.netを不適切に上書きしていないか - オンプレ／Azure 間の VPN / ExpressRoute / P2S VPN が正しく確立し、ルートが配布されているか
- ファイアウォール／NSG で Private Endpoint サブネットへの 1433/TCP が許可されているか
Resolve-DnsNameで最終的に Private Endpoint の IP が引けるかTest-NetConnectionで 1433/TCP の疎通が確認できるか- Public Endpoint を使う場合は 3342/TCP を厳格に制限しているか
これらを順番に潰していけば、「CNAME までは見えるが IP が返らない」「hosts に書けばつながる」といった DNS 由来のトラブルはほぼ解消できます。オンプレ DNS は database.windows.net を Azure に条件転送し、Azure 側では Private Resolver＋Private DNS ゾーンで最終 A レコードへ落とす──このパターンさえ押さえておけば、Managed Instance の Private Link 接続はぐっとシンプルに設計できるはずです。
コメント