Azure DNSのプラクティス
351 Views
April 27, 26
スライド概要
Azure と Power Platform 出来ます。
関連スライド
各ページのテキスト
すきやねん Azure!! #37 Azure DNSのプラクティス 2026/4/24 株式会社NTTデータ先端技術 経営企画部 Microsoft技術センター 原田 幸太郎 © 2026 NTT DATA INTELLILINK Corporation
目次 1. 自己紹介 2. DNS の基礎 3. OSI 参照モデル 4. Azure DNSのプラクティス 5. Appendix © 2026 NTT DATA INTELLILINK Corporation 2
01 自己紹介 © 2026 NTT DATA INTELLILINK Corporation 3
はじめに 私の属性は インフラエンジニア です。 インフラエンジニアとは： インフラエンジニアは、ITインフラの設計、構築、運用を担当する専門家です。彼らはサーバー、 ネットワーク、ストレージなどの基盤技術を管理し、システムの安定性と効率性を確保します。開 発系エンジニアがアプリケーションのコードを書くのに対し、インフラエンジニアはそのコードが動作する 環境を整備し、最適化します。 異属性の方々にはピンとこない話になることも多々あると思いますが、 暖かくご視聴いただけますと幸いです。 © 2026 NTT DATA INTELLILINK Corporation 4
自己紹介 Azure: まあまあいける Power Platform: 多少かな Microsoft 365: 普通 SQL Server: まあまあいける © 2026 NTT DATA INTELLILINK Corporation 氏名 原田 幸太郎 生年月日 1976年3月8日(50歳) 出身地 愛知県北名古屋市 所属 株式会社NTTデータ先端技術 職歴 アプリケーション開発エンジニア：5年 パッケージフィールドエンジニア：3年 パッケージ開発エンジニア：2年 インフラエンジニア：16年 趣味 クラフトビール・旅行・テニス 5
02 DNS の基礎 © 2026 NTT DATA INTELLILINK Corporation 6
DNS とは何か / なぜ必要か DNS（Domain Name System）とは、名前解決を行う仕組み。 人が使う「名前（ドメイン名）」と、コンピュータが使う「IPアドレス」を結びつける。 例： www.example.com → 93.184.216.34 DNS が必要な理由 • IPアドレスは人間にとって覚えにくい • Web、メール、クラウドなどほぼ全ての通信で必須 DNS がないと... • Web サイトにアクセスできない • メールが届かない © 2026 NTT DATA INTELLILINK Corporation 7
DNS の歴史（年表） DNS はインターネットの成長とともに進化してきた。 • 1980年代初頭：hosts による名前管理 – 1台のファイルで名前と IP を管理、台数増加により限界に到達 • 1983年：DNS の概念が提案・RFC 策定 – 分散型の名前解決システムとして設計 DNS の基本的な構造はこのあたりで固まって今も 変わっていない。 インターネット基盤プロトコルの中でも最古の1つ。 • 1980年代後半：実運用への普及 – .com .org .jp などの TLD が登場 SMTP： 1982年 DNS： 1983年 HTTP： 1991年 • 2000年代：インターネットの商用利用拡大 – 可用性・性能が重要に • 2010年代以降：セキュリティとクラウド対応 – DNSSEC、マネージド DNS（クラウド DNS）の普及 © 2026 NTT DATA INTELLILINK Corporation 8
ドメイン名の構造 ドメイン名は階層構造になっている。 例：portal.azure.com 1. .（ルート） 2. com（トップレベルドメイン：com / org / jp / net など） ➢ jp の下に属性型ドメインが存在（co.jp / go.jp など） ➢ ブランド TLD というものもある（microsoft / toyota / nike など） 3. azure（セカンドレベルドメイン：azure / microsoft365 / github など） 4. portal（ホスト名） 企業が取得・管理するのは主に「セカンドレベルドメイン」以下。 © 2026 NTT DATA INTELLILINK Corporation 9
ドメイン名のビジネス ドメイン名は「国家が保有するデジタル天然資源」でして外貨獲得ビジネスとなっている https://www.imf.org/en/news/articles/2024/05/15/ cf-an-ai-powered-boost-to-anguillas-revenues 出展: お名前.com (お名前ドットコム) 公式note © 2026 NTT DATA INTELLILINK Corporation 10
DNS サーバーの種類 再帰 DNS • 自身が起点となり、再帰問い合わせを行って最終的な名前解決結果を返すサーバー • クライアント（端末・サーバー）から直接指定されるのは基本的にこれ 権威 DNS • ドメインの正式な DNS 情報（ゾーン）を管理するサーバー • 管理しているゾーンに対する問い合わせにのみ回答 ルート DNS / TLD DNS • IP アドレスは返さず、次に問い合わせるべき DNS サーバーを案内 フォワード DNS • 自らはゾーンを管理せず、問い合わせを受けさらに上位の DNS へフォワード（転送）するサーバー • 実装によっては応答をキャッシュし、キャッシュサーバーとしても動作する © 2026 NTT DATA INTELLILINK Corporation 11
DNS の仕組み DNS 問い合わせの流れ（portal.azure.com の例） ① ユーザーがブラウザで portal.azure.com にアクセス ② キャッシュで過去の名前解決結果を確認（なければ次へ） ③ 再帰 DNS サーバー（ISP / 企業 / Public DNS）が代わりに名前解決を開始 → ドメインコントローラーのように自分でゾーンをホストしている場合はここで返却 ④ ルート DNS サーバー：「.com はどこが管理？」を回答（IP は返さない） ⑤ TLD DNS サーバー（.com）：「azure.com を管理する権威 DNS はどこ？」を回答 ⑥ 権威 DNS サーバー（azure.com） ： portal.azure.com の正式な DNS 情報を管理 → IP アドレスを回答 ⑦ 再帰 DNS サーバーが結果をキャッシュしクライアントへ返却 ⑧ ユーザーが IP アドレスへ接続し Azure Portal を表示 ※ ルート DNS・TLD DNS は IP アドレスを返さず、「次に問い合わせる先」を案内する役割。 © 2026 NTT DATA INTELLILINK Corporation 12
主な DNS レコード • A レコード：IPv4 アドレス • AAAA レコード：IPv6 アドレス • CNAME：別名（エイリアス） – 使用例：Azure Web App にカスタムドメインを割り当てる、www.example.com を myapp.azurewebsites.net に解決 • MX：メールサーバー – 使用例：example.com のメールを mail.example.com に配送 • TXT：認証・設定情報 – 使用例：SPF / DKIM / DMARC（メール送信ドメイン認証） – 使用例：Microsoft 365 や各種 SaaS のドメイン所有確認 • NS：DNS サーバー情報 – 使用例：ゾーンを管理する権威 DNS サーバーを指定、Azure DNS などのマネージド DNS へ委任 © 2026 NTT DATA INTELLILINK Corporation 13
ゾーン転送 / フォワード / ルートヒント ゾーン転送（Zone Transfer） • 権威 DNS サーバー間でゾーン情報（DNS レコード一式）を複製する仕組み • 代表例：プライマリ DNS → セカンダリ DNS への同期、オンプレ DNS サーバー間のゾーン複製 フォワード（Forward） • 受け取った DNS 問い合わせを別の DNS サーバーへ転送する仕組み、自分では解決せず「この名前はあちらに 聞く」という役割分担 • 代表例：社内 DNS → インターネット向け DNS • 条件付きフォワーダー（Conditional Forwarder）：特定のドメイン（例：corp.example.com）のみを 指定した DNS サーバーへ転送、社内ドメインは社内 DNS、クラウド／外部ドメインは別 DNS へ振り分け ルートヒント（Root Hints） • DNS サーバーが最初に参照するルート DNS サーバーの一覧。フォワード設定がない場合、再帰 DNS はルート ヒントを起点に名前解決を開始する • 役割：「どのルート DNS に聞けばよいか」を知るための初期情報、DNS が自律的にインターネット全体をたどる ことのできる根本的な仕組み © 2026 NTT DATA INTELLILINK Corporation 14
キャッシュ キャッシュの場所 • クライアント側キャッシュ – OS やブラウザが保持、端末再起動やキャッシュクリアの影響を受ける • サーバー側キャッシュ – DNS サーバー（ISP / 企業 / Public DNS）が保持、多数のユーザーで結果を共有 TTL（Time To Live） • キャッシュの有効期限 • この値が DNS 変更の伝播速度に直接影響 – TTL が長い → 変更が反映されるまで時間がかかる – TTL が短い → 変更は早く反映されるが負荷が増える 設定変更がすぐ反映されない理由 • TTL 有効期限内でクライアント側・サーバー側のキャッシュが残っているため © 2026 NTT DATA INTELLILINK Corporation 15
DNS とセキュリティ 代表的な攻撃例 • DNS キャッシュポイズニング – 偽の DNS 応答をキャッシュに混入させる攻撃 – 正しいドメイン名でも攻撃者が用意した偽サイトの IP に誘導される – 一度キャッシュされると、TTL が切れるまで影響が継続 • フィッシング（DNS を悪用した例） – 正規サービスに似たドメイン名を使い利用者を欺く – 例：portal-azure.example など紛らわしい名前 – DNS 自体は正しく動作していても、人間の判断を狙う攻撃 主な対策 • DNSSEC：DNS 応答が正当なものであることを検証、キャッシュポイズニング対策 • 信頼できる DNS サービス、セキュリティ対策・監視が行われた再帰 DNS を使用 © 2026 NTT DATA INTELLILINK Corporation 16
03 (閑話休題) OSI 参照モデル © 2026 NTT DATA INTELLILINK Corporation 17
OSI 参照モデル 概要 OSI参照モデル（Open Systems Interconnection Reference Model）とは、 ネットワーク通信の仕組みを 7 つの階層（レイヤ）に分けて整理した国際標準モデル。 • • • • ネットワーク通信を階層構造で理解できる 各層が独立して役割を持つため、トラブルシューティングが容易 機器・ソフトウェアの設計や比較がしやすい TCP/IP など実際のプロトコル群を理解するための「考え方のモデル」 ポイント • 上位層：人間に近い処理（アプリケーション寄り） • 下位層：機器・物理に近い処理（ケーブル・信号寄り） © 2026 NTT DATA INTELLILINK Corporation 18
OSI 7 層 層 レイヤ名 主な役割 代表的な例 対応するネットワーク機器 第7層 アプリケーション層 利用者が直接使う通信機 能 HTTP, FTP, SMTP, DNS プロキシサーバ、ロードバランサ （L7） 第6層 プレゼンテーション層 データ形式変換・暗号化 TLS/SSL ※ 実装依存で L5 〜 L7に渡る ※ L7 として扱われることが多い 第5層 セッション層 通信の開始・維持・終了管 理 セッション制御 ※ L7 として扱われることが多い 第4層 トランスポート層 データ分割・再送制御 TCP, UDP ロードバランサ（L4）、ファイアウォー ル 第3層 ネットワーク層 宛先決定・ルーティング IP, ICMP ルータ、L3 スイッチ 第2層 データリンク層 同一ネットワーク内転送 Ethernet, ARP ※ ARP は L2 と L3 の中間にあ るが L2 に分類されることが多い スイッチ、ブリッジ 第1層 物理層 電気信号・物理接続 ケーブル、コネクタ ハブ、リピータ © 2026 NTT DATA INTELLILINK Corporation 19
HTTP通信 の流れ [クライアント（ブラウザ）] [スイッチ] [ルーター] [Webサーバ] | | | HTTPS リクエスト----------------------------------------------------------------------------------------> | | | | ① 電気信号／光信号として送信----------------> | | | | ② Ethernet によるフレーム転送 | --------------->(GW) | | | | ③ IP によるルーティング | -----------------------> | | | | ④ TCP による通信制御 | | ・ポート番号（443） | | ・再送制御／順序制御 | | | | ⑤ TLS ハンドシェイク | | ・証明書送信／検証 | | ・共通鍵生成 | | | | ⑥ HTTPS 通信開始 | | | | <-------------------------------------------------------- | ------------------------ | -- HTTPS レスポンス | © 2026 NTT DATA INTELLILINK Corporation 20 ← 第1層 ← 第2層 ← 第3層 ← 第4層 ← 第5層〜第7層 ← 第7層
04 Azure DNSのプラクティス © 2026 NTT DATA INTELLILINK Corporation 21
Azure DNS Public Zones • Azure が提供するパブリック DNS、インターネット向けシステムの名前解決を担うドメインのホスティングサービス • グローバル Anycast ネットワークを利用、利用者に最も近い DNS サーバーから応答することで高速・高可用 ➢ SLA：100%（最大利用時間 (分) - ダウンタイム / 最大利用時間 (分) x 100） ➢ 「ダウンタイム」とは、最大利用時間 (分) のうち、DNS ゾーンを使用できなかった合計累積時間 (分) です。DNS ゾーンが有効な DNS 要求に対して 2 秒以内に DNS 応答を返さなかった場合に、その DNS ゾーンは 1 分間使用できなかったと見なされます。 ただし、有効な DNS 要求が DNS ゾーンに関連付けられたすべてのネーム サーバーに対して行われ、少なくとも 60 秒間連続して 再試行されることを条件とします。 • • • • • • ➢ リージョンに依存しない Non Regional サービス ドメインは App Service ドメインまたは外部レジストラで取得し、Azure Public DNS に委任して権威 DNS とする 2025年2月に DNSSEC が GA 再帰 DNS としては利用不可、ホストしているゾーンに対しての権威 DNS としてのみ動作 ゾーン転送（AXFR / IXFR）非対応 Azure DNS の価格 パブリック DNS の制限 © 2026 NTT DATA INTELLILINK Corporation 22
Azure DNS Private Zones • Azure 仮想ネットワーク向けのプライベート DNS サービス、インターネット非公開の名前解決を提供 • 1 つのリージョンリソースとして管理されるが、その中の DNS データは Azure の DNS 基盤でグローバルに複製さ れる • VNet 内および接続された複数 VNet 間で仮想マシンや VNet に接続されたリソースの名前解決を実現 • 仮想ネットワークとゾーンをリンクすることで利用可能、自動登録により VM の DNS レコードを自動管理 ➢ ただし 1 つの VNet に自動登録リンクできる Private DNS Zone は 1 つのみ • Azure 既定名ではなく独自のカスタムドメイン名を利用可能、ドメイン名の購入・登録は基本的に不要 • 再帰処理は Azure-provided DNS が実施し、Private DNS Zone は権威 DNS として参照される • ゾーン委任（NSレコード）作成不可、サブドメインは Private DNS Zone として独立作成する必要がある • Azure DNS の価格 • プライベート DNS の制限 © 2026 NTT DATA INTELLILINK Corporation 23
Azure DNS Private Resolver • Azure とオンプレミス（または他 DNS）間の名前解決を中継するマネージド DNS サービス • Azure Private DNS ゾーンをオンプレミスから解決（ Inbound ） 、または Azure からオンプレミスのドメイン を解決（ Outbound ）するシナリオに適用 • Inbound Endpointでオンプレミス等からの DNS クエリを受信、Outbound Endpoint＋転送ルールセット （フォワードルール）で Azure から外部 DNS へ条件付き転送 • DNS クエリを Azure-provided DNS や外部 DNS に中継するためのフォワードサーバー、Inbound Endpoint はクライアントの DNS サーバーとして指定可能 • Azure DNS の価格 • DNS プライベート リゾルバー の制限 © 2026 NTT DATA INTELLILINK Corporation 24
Azure-provided DNS VNet の DNS 設定を「既定（Azure 提供）」にした場合に使われる、Azure 基盤の再帰 DNS DHCP で割り当てられ DNS サーバーとして参照（Azure が管理する特殊な仮想 IP） VNet 統合された PaaS やネットワークリソースも利用 VNet 外からの直接参照不可（再帰 DNS としての利用不可） 既定では VNet を跨いだ解決は不可だが、Private DNS Zone をリンクすれば複数 VNet 間で解決可能 サービスが使用する 168.63.129.16 は他の Azure 基盤通信にも使用されるため基本的に遮断不可 VNet 上に Active Directory を構築する場合は、カスタム DNS としてドメインコントローラーを指定し、ドメイ ンコントローラー上の DNS サーバーでフォワーダーとして 168.63.129.16 を設定する構成とする • 課金：なし • • • • • • • © 2026 NTT DATA INTELLILINK Corporation 25
Azure DNS Security Policy Azure が提供する VNet 単位の DNS トラフィック可視化・制御機能 主な機能 • DNS クエリログの取得：クエリ名・応答結果・適用ルールなどを Log Analytics 等へ出力 • ドメイン単位の制御：Domain List に基づき Allow / Block / Alert を設定 • Threat Intelligence 連携：Microsoft 管理の悪性ドメインリストを利用可能 適用スコープと特徴 • VNet にリンクして適用（Private DNS Zone と同様のリンクモデル） • Azure Firewall の DNS プロキシ有無に依存せず動作 • DNS レベルでの制御のため、通信が確立する前に遮断可能 利用シナリオ • マルウェア／C2 通信の早期遮断 • 内部システムからの意図しない外部通信の可視化 • Sentinel 連携による SOC・セキュリティ監視の強化 © 2026 NTT DATA INTELLILINK Corporation 26
サブドメインテイクオーバー 未解決の DNS エントリを防ぎ、サブドメインの乗っ取りを回避する app-contogreat-dev-001 の App Service を作成することで greatapp.contoso.com を 乗っ取ることができる © 2026 NTT DATA INTELLILINK Corporation 27
その他のサービス Azure Traffic Manager（DNS ベースの負荷分散） • DNS ベースのグローバルトラフィック制御サービス • DNS の名前解決に Traffic Manager が介在し、プロファイルに基づいて適切な（地域ごとに最も近い など） エンドポイントの IP アドレスを返却する仕組み • その後の通信は Traffic Manager を経由せず、クライアントからエンドポイントへ直接通信される（プロキシ／ ゲートウェイ型のサービスではない） Azure Firewall（DNS プロキシ） Azure Firewall に組み込まれた DNS プロキシ機能 クライアントからの DNS クエリを Azure Firewall が受信し、指定された DNS サーバーへフォワードする Azure Firewall 自身はフォワード専用、名前解決は背後の DNS サーバーが実施 DNS プロキシを有効化すると、クライアントは DNS サーバーとして Azure Firewall のプライベート IP を参照 する構成となる • ネットワークルールで FQDN 制御を行いたい場合は利用必須（アプリケーションルールの場合は不要） • • • • © 2026 NTT DATA INTELLILINK Corporation 28
Traffic Manager のしくみ ここで地理的ルールなどを適用し、動的にレコー ドを返却することでルーティングを行う仕組み 出展: Traffic Manager のしくみ © 2026 NTT DATA INTELLILINK Corporation 29
PaaS / SaaS の名前解決 Azure App Service • App Service の既定の名前解決は Azure-provided DNS を参照する • 仮想ネットワークと統合した場合、仮想ネットワークに構成されている DNS サーバーを使用して名前解決を行う • 仮想ネットワークに Azure Private DNS Zone がリンクされている場合、App Service からの名前解決でも その Private DNS Zone が参照される Azure Kubernetes Service • AKS では 3 レイヤーの名前解決が提供される • /etc/resolv.conf → CoreDNS or LocalDNS → Azure DNS or カスタム DNS – クラスタ内部名（svc.cluster.local） – 外部名 → Upstream DNS（既定で仮想ネットワークの DNS 設定を参照） – Azure DNS（168.63.129.16）またはカスタム DNS（VNet DNS） • CoreDNS をカスタマイズして外部 DNS に直接フォワードすることも可能 © 2026 NTT DATA INTELLILINK Corporation 30
特殊なシナリオ Azure Virtual WAN • プライベート DNS ゾーンを Virtual WAN ハブにリンクすることはできない • Virtual WAN ハブに任意のサブネットを作成することができないので、サブネットに依存する Azure DNS Private Resolver は配置できない ➢ DNS 専用スポークに Private Resolver を配置する構成がプラクティス • ピアリングされた専用スポークで DNS を処理することがプラクティスとして提示されている © 2026 NTT DATA INTELLILINK Corporation 31
ベストプラクティス Azure Virtual Network 名前解決ガイド |Microsoft Learn # シナリオ 解決策 1 同じ仮想ネットワーク内にある仮想マシン間や、 同じクラウドサービス内の Azure Cloud Services ロールインスタンス間の名前解決。 Azure Private DNS zones または Azure 提 供の名前解決 ホスト名または FQDN 2 異なる仮想ネットワーク内の仮想マシン間や異 なるクラウドサービスにおけるロールインスタンス間 の名前解決。 Azure Private DNS zone, Azure DNS Private Resolver, または顧客管理の DNS サーバーで仮想ネットワーク間でクエリを転送し、 Azure（DNS プロキシ）で解決します。 FQDN のみ 3 Azure App Service（ウェブアプリ、関数、ポッ ト）から、仮想ネットワーク統合を使って同じ仮 想ネットワーク内のインスタンスや仮想マシンに ロールアウトします。 Azure DNS Private Resolver や顧客管理の FQDN のみ DNS サーバーで、仮想ネットワーク間でクエリを 転送し、Azure（DNS プロキシ）で解決します。 → Azure Private DNS zones または Azure 提供の名前解決じゃない？ 4 App Service の Web アプリから同じ仮想ネット ワーク内の仮想マシンへの名前解決。 Azure DNS Private Resolver や顧客管理の FQDN のみ DNS サーバーで、仮想ネットワーク間でクエリを 転送し、Azure（DNS プロキシ）で解決します。 → Azure Private DNS zones または Azure 提供の名前解決じゃない？ © 2026 NTT DATA INTELLILINK Corporation 32 DNSサフィックス
ベストプラクティス（続き） # シナリオ 解決策 DNS サフィックス 5 App Service の Web アプリが 1 つの仮想ネッ Azure DNS Private Resolver や顧客管理の FQDN のみ トワーク内の仮想マシンに名前解決を行います。 DNS サーバーで、仮想ネットワーク間でクエリを 転送し、Azure（DNS プロキシ）で解決します。 6 Azure 内の仮想マシンやロールインスタンスから オンプレミスのコンピュータ名やサービス名を解決 すること。 Azure DNS Private Resolver や顧客管理の FQDN のみ DNS サーバー（オンプレミスのドメインコントロー ラー、ローカル読み取り専用ドメインシトローラー、 ゾーン転送で同期された DNS セカンダリなど）。 → Active Directory では仮想ネットワーク内に ドメインコントローラの出先機関を立てる構成 7 オンプレミスのコンピュータから Azure ホスト名の 解決。 クエリを対応する仮想ネットワーク内の顧客管理 の DNS プロキシサーバーに転送します。プロキ シサーバーはクエリを Azure に転送して解決しま す。 → Active Directory 環境ではこうだけど、そうで ないなら Azure DNS Private Resolver じゃな い？ © 2026 NTT DATA INTELLILINK Corporation 33 FQDN のみ
ベストプラクティス（続き） # シナリオ 解決策 DNS サフィックス 8 内部 IP には逆 DNS を使います。 Azure プライベート DNS ゾーン、Azure が提 供する名前解決、Azure DNS プライベートリゾ ルバ、または自分の DNS サーバーを使った名前 解決など。 該当しません 9 仮想ネットワーク内ではなく、異なるクラウドサー ビスに存在する仮想マシンやロールインスタンス 間で名前解決を。 該当しません。異なるクラウドサービス内の仮想 マシンとロールインスタンス間の接続は、仮想ネッ トワークの外ではサポートされていません。 該当しません © 2026 NTT DATA INTELLILINK Corporation 34
過去あったトラブル事例 # 発生日 影響サービス トラブルの内容 リンク 1 2019-05-02 Azure 全般、Microsoft 365 DNS 移行中の nameserver delegation change による DNS resolution 障害。 ZDNET 2 2021-04-01 Azure, Microsoft 365, Xbox 等 Azure DNS のコード欠陥＋ DNS クエリ急増により DNS が過負荷・応答不可 ZDNET 3 2022-06-08 Azure Front Door *.azurefd.net の DNS レコードが解決不能（AFD 側 DNS 障害）。 Reddit 4 2025-10-29 Azure Front Door, Entra ID, Azure Portal ほか Azure Front Door 障害に伴う Domain Name System (DNS) resolution issues Microsoft 公式 PIR © 2026 NTT DATA INTELLILINK Corporation 35
- https://www.zdnet.com/article/azure-global-outage-our-dns-update-mangled-domain-records-says-microsoft/
- https://www.zdnet.com/article/microsoft-heres-what-caused-our-recent-azure-cloud-computing-services-outage/
- https://www.reddit.com/r/AZURE/comments/v7wwvx/all_front_door_standardpremium_dns_not_resolving/?solution=17ca5afd099a845b17ca5afd099a845b&js_challenge=1&token=bbbe4bf1c9a2b5160829c4be34da58615274e4f586f114790e220ce69d42d43e&jsc_orig_r=
- https://azure.status.microsoft/status/history/?trackingId=YKYN-BWZ
まとめ 本セッションでは、Azure によって提供されている DNS 関連機能について、基本的な名前解決機能から、セキュリ ティ、運用の観点までを段階的に整理しました。 Azure DNS は、パブリック DNS ゾーンおよびプライベート DNS ゾーンを提供し、Anycast によりグローバルに分 散された名前解決を行うマネージド DNS サービスです。 パブリック DNS ゾーンでは DNSSEC による応答署名がサポートされており、また DNS セキュリティ ポリシーを利用 することで、VNet 単位で DNS クエリのログ取得や、ドメインリストに基づく Allow / Block / Alert といった制御が 可能です。 一方で、インターネット向け名前解決、VNet 内の名前解決、オンプレミス連携やフォワーディングなどを含めて設計す る場合には、複数のサービスを組み合わせて利用する必要があります。そのため、各サービスの役割や名前解決の流 れを理解した上で設計・運用することが前提となります。 インターネットの基幹プロトコルである DNS と、Azure における DNS 機能の整理・理解を深める一助となれば幸い です。 © 2026 NTT DATA INTELLILINK Corporation 36
05 Appendix © 2026 NTT DATA INTELLILINK Corporation 37
MX レコードとメール配送の仕組み MX レコード（Mail Exchanger） • • • • ドメイン宛てのメールをどのメールサーバーに配送するかを定義するレコード 優先度（Priority）が低い数値ほど優先して使われる 例：example.com MX 10 mail.example.com Microsoft 365 の場合：example-com.mail.protection.outlook.com メール配送の流れ ① ② ③ ④ ⑤ 送信者のメールサーバーが宛先ドメインの MX レコードを DNS で引く MX レコードが示すホスト名の A / AAAA レコードを引き IP アドレスを取得 取得した IP の受信メールサーバーへ SMTP で配送 受信サーバーが SPF / DKIM / DMARC 認証を実施 認証結果に応じて受信・隔離・拒否 © 2026 NTT DATA INTELLILINK Corporation 38
SPF / DKIM / DMARC とは メール送信の正当性を DNS レコードで証明する仕組み。 SPF（Sender Policy Framework） • • • 「このドメインからメールを送信してよいサーバー」を TXT レコードで宣言 受信側はエンベロープ From のドメインの SPF レコードを確認し、送信元 IP が許可されているか検証 例：v=spf1 include:spf.protection.outlook.com -all DKIM（DomainKeys Identified Mail） • • • 送信メールにデジタル署名を付与し、改ざん検知を実現 公開鍵を DNS の TXT レコードとして公開、受信側が署名を検証 例：selector._domainkey.example.com TXT "v=DKIM1; k=rsa; p=...“ DMARC（Domain-based Message Authentication, Reporting & Conformance） • • • SPF/DKIM の認証結果に基づき、失敗時のポリシー（none / quarantine / reject）を定義 認証失敗メールのレポートを受け取ることも可能 例：_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:[email protected]" © 2026 NTT DATA INTELLILINK Corporation 39
DNS のトラブルシューティング 切り分け手順 1. クライアントのローカルキャッシュをクリアして再確認する 2. 参照先 DNS サーバーを明示して問い合わせ、期待の値が返るかを確認する 3. ルート DNS から順に再帰解決の経路を追跡し、どの階層で解決が詰まっているかを特定する 4. 権威 DNS に直接問い合わせて正しい値が返るかを確認する ➢ 返らない場合はレコードの設定ミス、返る場合はキャッシュや委任の問題を疑う 5. 変更直後の場合は TTL 残存時間を確認する ➢ TTL 内であればキャッシュが残っているため時間経過か強制フラッシュで解消する 確認コマンド nslookup example.com 8.8.8.8 - 特定のDNSサーバーに直接問い合わせ dig example.com @8.8.8.8 +trace - ルートDNSから順に再帰解決の経路を追跡 dig example.com +short - 解決結果のIPのみ表示 dig -x 93.184.216.34 - 逆引き（PTRレコードの確認） © 2026 NTT DATA INTELLILINK Corporation 40