Azure DNS入門｜独自ドメインの名前解決からプライベートDNS・Route 53との違いまで現場で使える実践ガイド

Azureで独自ドメインを使おうとしたとき、「今まではBINDで管理していたのに、Azureでは何をすればいい？」と戸惑ったエンジニアは多い。オンプレ環境では、ゾーンファイルを直接編集してnamed.confをリロードし、セカンダリDNSと同期を取る作業が当たり前だった。そのノウハウがそのまま通用しないのがクラウドDNSだ。

Azure DNSは、そうした運用の手間を一気に解消するフルマネージドのDNSホスティングサービスだ。ゾーンファイルの管理もセカンダリの冗長設定も不要で、グローバルに分散したDNSインフラをAzureポータルやAzure CLIから数分で構成できる。

この記事では、Azure DNSの基本概念からパブリック・プライベートDNSゾーンの設定手順、Amazon Route 53との違い、料金体系と実務Tips、よくあるトラブルまで、オンプレ経験者の視点でまとめる。

なぜAzure DNSなのか？（オンプレとの違い）

オンプレでBINDを運用していた経験があるなら、ゾーンファイルのシンタックスエラーで名前解決が止まった経験や、プライマリとセカンダリの同期ズレに悩まされた記憶が1度はあるはずだ。Azure DNSはこれらの問題を構造的に解決している。

オンプレBIND vs Azure DNSの主な違い

・冗長構成: BINDはプライマリ＋セカンダリの構成を自前で設計・維持する必要があった。Azure DNSは世界中に分散した4台以上のネームサーバーが自動で割り当てられ、冗長構成が最初から組み込まれている
・ゾーンファイル管理: BINDはSOAレコードのシリアル番号を手動更新し、named-checksoneで構文チェックするなど運用負荷が高い。Azure DNSではGUIやAPIで操作するため、シリアル番号の概念自体がなくなる
・可用性: MicrosoftはAzure DNSのSLAとして99.99%以上を謳っており（2026年7月時点）、単一障害点を排除した設計になっている
・Azureリソースとの統合: Azure Load BalancerやAzure Front DoorのIPとDNSレコードを直接連携する「エイリアスレコード」機能があり、IPアドレスが変わっても自動追従できる

ただし注意点もある。Azure DNSはドメイン登録（レジストラ機能）を提供していない。独自ドメインの取得はお名前.comやRoute 53などの別サービスで行い、そのNSレコードをAzure DNSのネームサーバーに向ける形になる。

Azure DNSの基本概念

設定作業に入る前に、押さえておくべき用語を整理しておく。

1. DNSゾーン

Azure DNSでは「DNSゾーン」がドメイン1つの管理単位になる。example.com というドメインを管理するなら、example.com というDNSゾーンをAzureポータルで作成する。

ゾーンには2種類ある。

・パブリックDNSゾーン: インターネット上の名前解決に使う。外部からアクセスするWebサイトやメールのMXレコードなどをここで管理する
・プライベートDNSゾーン: Azure仮想ネットワーク（VNet）内部の名前解決に使う。Azure VM同士がホスト名で通信する際や、Private Endpointの名前解決に欠かせない

2. レコードセット

Azure DNSでは個々のDNSレコードを「レコードセット」という単位で管理する。同じ名前・同じタイプのレコードをまとめたものだ。例えば www.example.com のAレコードが2件あれば、それが1つのレコードセットになる。

主なレコードタイプ：

・A: IPv4アドレスへのマッピング
・AAAA: IPv6アドレスへのマッピング
・CNAME: 別のドメイン名へのエイリアス
・MX: メールサーバーの指定
・TXT: SPF・DKIM・ドメイン所有権確認などに使う
・NS: ネームサーバーの指定（ゾーン委譲時に使う）
・SOA: ゾーンの権威情報（Azureが自動管理）

3. エイリアスレコード（Azure固有）

Azure DNSには通常のCNAMEとは異なる「エイリアスレコード」という仕組みがある。Azure Load Balancer、Azure Front Door、Azure Traffic ManagerなどのAzureリソースを直接参照するレコードで、リソースのIPが変わっても自動的に追従する。

オンプレ環境では、ロードバランサーのIPが変わるたびにDNSレコードの手動更新が必要だったが、エイリアスレコードを使えばその手間がなくなる。

基本的な使い方（コンソール操作）

1. パブリックDNSゾーンの作成

Azureポータルで「DNSゾーン」を検索し、「＋作成」をクリックする。

設定項目：

・サブスクリプション: 管理するサブスクリプションを選択
・リソースグループ: DNS管理専用のリソースグループを用意するのが推奨（例: rg-dns）
・名前: 管理するドメイン名（例: example.com）
・リージョン: 「グローバル」固定（Azure DNSはグローバルサービス）

作成完了後、ゾーンの概要画面に4つのネームサーバーアドレスが表示される（例: ns1-XX.azure-dns.comなど）。この4つのアドレスをドメインレジストラ側のNSレコードとして登録する。

2. ドメインレジストラでのNS委譲設定

ドメインを購入したレジストラ（お名前.com、AWS Route 53など）の管理画面でNSレコードを書き換える。書き換えるべき値はAzureポータルのゾーン画面に表示された4つのネームサーバーだ。

NS変更はDNSキャッシュの都合上、全世界へ反映されるまで最大48時間かかることがある（実際は数時間以内がほとんど）。反映確認は以下のコマンドで行う。

# NSレコードの確認（Linuxターミナルから）
dig NS example.com +short

# Azureのネームサーバーが返ってくればOK
# 例: ns1-01.azure-dns.com.

3. Aレコード・CNAMEレコードの追加

Azureポータルのゾーン画面から「＋レコードセット」をクリックして追加する。Azure CLIを使う場合は以下のようになる。

# Azure CLI でAレコードを追加する
az network dns record-set a add-record \
  --resource-group rg-dns \
  --zone-name example.com \
  --record-set-name www \
  --ipv4-address 203.0.113.10 \
  --ttl 300

# CNAMEレコードを追加する例
az network dns record-set cname set-record \
  --resource-group rg-dns \
  --zone-name example.com \
  --record-set-name blog \
  --cname www.example.com \
  --ttl 300

TTLはオンプレ時代に「変更するときだけ短くして、普段は長め」という運用をしていたエンジニアも多いと思う。Azure DNSでも同じ考え方が使える。変更作業前はTTLを300秒（5分）に短縮しておき、作業後に3600秒（1時間）に戻すと安全だ。

4. プライベートDNSゾーンの設定

Azure VM同士をホスト名で通信させたい、あるいはPrivate EndpointのFQDNを内部で解決したい場合はプライベートDNSゾーンを使う。

Azureポータルで「プライベートDNSゾーン」を検索して作成する。ゾーン名はパブリックDNSと同じ形式だが、内部専用の名前（例: internal.example.com）や、Azureサービス固有のプライベートリンクドメイン（例: privatelink.blob.core.windows.net）を使うことが多い。

作成後は、対象のVNetにゾーンを「リンク」する必要がある。

# プライベートDNSゾーンをVNetにリンクする
az network private-dns link vnet create \
  --resource-group rg-dns \
  --zone-name internal.example.com \
  --name link-vnet-prod \
  --virtual-network /subscriptions//resourceGroups/rg-network/providers/Microsoft.Network/virtualNetworks/vnet-prod \
  --registration-enabled true

# --registration-enabled true にすると、VNet内のVMが起動した際に
# プライベートDNSゾーンへ自動でAレコードが登録される

--registration-enabled true（自動登録）を有効にすると、VNet内のAzure VMが起動するたびにそのプライベートIPとホスト名がDNSゾーンへ自動登録される。オンプレのDHCPサーバーがDNS動的更新をしていた感覚に近い。

料金の仕組み（コスト感覚）

Azure DNSの料金は「ゾーン単価」と「クエリ単価」の2軸で構成される（2026年7月時点、東日本リージョン基準）。

一般的なWebサービスであれば月間DNSクエリ数は数千万以下に収まることが多く、ゾーンが数個なら月額数百円から数千円の範囲に収まる。コスト最適化の観点では、不要なゾーンを削除することがシンプルに効果的だ。

Linuxサーバーの基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。Azureで構築したVMのOS設定・ネットワーク設定はLinuxの知識が直接活きます。

Amazon Route 53との比較

AWSをすでに使っているエンジニアにとって気になるのが Route 53 との違いだ。

料金はほぼ同じ水準だが、機能面ではRoute 53の方が単体で完結しやすい。Azureでは「DNSのヘルスチェック付きルーティング＝Traffic Manager + Azure DNS」という組み合わせが基本になるため、設計をシンプルに保ちたい場合はアーキテクチャを意識する必要がある。

応用・実務Tips

1. エイリアスレコードでIPアドレス管理を不要にする

Azure Front DoorやAzure Traffic Managerを使う場合は、CNAMEではなくエイリアスレコードを使う。CNAMEはゾーンの頂点（ルートドメイン）には設定できないという制約があるが、エイリアスレコードはゾーンの頂点にも設定できる。

example.com（ルートドメイン）をAzure Front Doorに向けたい場合は、Aレコードとしてエイリアスを設定するとよい。

2. Private EndpointのDNS設定はプライベートDNSゾーンで統一する

Azure Storage、Azure SQL、Azure Key VaultなどをPrivate Endpointで閉域接続する場合、各サービスに対応したプライベートリンクDNSゾーン（例: privatelink.blob.core.windows.net）をVNetにリンクする必要がある。ここを手動で管理すると抜け漏れが出やすいため、Azure PolicyやTerraformでゾーン作成とリンクを自動化するのが現場のベストプラクティスだ。

3. 複数VNetへのリンクとDNS forwarder

Hubスポーク構成（Transit VNet + スポークVNet）の場合、スポーク側からHub側のプライベートDNSゾーンを解決したい場面がある。この場合はHub VNetにDNSプロキシ用のAzure Firewallを配置し、スポーク側のカスタムDNS設定をAzure FirewallのIPに向けるパターンが一般的だ。

4. CLI・IaCでの一括管理

複数のDNSレコードをまとめて管理したい場合は、Azure CLIよりもTerraformやAzure Bicepを使った方が変更履歴が追いやすい。特に複数のチームが同じゾーンを触る環境では、IaCで「誰がいつどのレコードを追加したか」を Git で管理できる体制が望ましい。

よくあるトラブルと対処法

① NSTレコードを変更したのに名前解決が変わらない
原因はほぼキャッシュだ。dig +trace でキャッシュをバイパスして確認するか、時間をおいてTTLが切れるのを待つ。急ぐ場合はWindowsなら ipconfig /flushdns、Linuxなら systemd-resolve –flush-caches で自端末のキャッシュを消す。

② プライベートDNSゾーンを作ったのにVMが名前解決できない
VNetへのリンクが未設定の可能性が高い。Azureポータルのプライベートゾーン→「仮想ネットワークリンク」でリンクが存在するか確認すること。リンクはあってもVMが参照するDNS設定がAzureデフォルト（168.63.129.16）でないと解決できない場合もある。

③ エイリアスレコードを設定したのにnxdomainが返る
参照先のAzureリソースが削除済みか、異なるサブスクリプションにある可能性がある。エイリアスレコードは同一サブスクリプション内のリソースにしか張れない制約がある（2026年7月時点）。

④ CNAMEをゾーン頂点（example.comそのもの）に設定しようとするとエラーになる
DNS仕様上の制約でCNAMEはゾーン頂点に設定できない。代替手段としてエイリアスレコード（Azureリソース向け）またはAAAAレコードへの書き換えで対応する。

本記事のまとめ

Azure DNSの要点を整理する。

オンプレのBINDと比べてAzure DNSは圧倒的に運用コストが低い。ゾーンファイルのシンタックスを気にせず、冗長構成もAzureに任せられる。特にプライベートDNSゾーンを使った自動登録は、VNetスケール時のホスト管理を大幅に楽にしてくれる。

ネットワーク設計の次のステップとして、Azure Virtual NetworkやNSGの設計も合わせて押さえておくと、インフラ全体の流れが見えてくる。