[Day8] やってはいけない DNS サーバーの参照設定


# Microsoft Azure Tech Advent Calendar 2019 の 8 日目です。

Azure に限った話ではないですが、DNS サーバーの参照設定を誤っている人が多いので、注意喚起の意味を込めて。

この設定を見て、何がおかしいか分かりますか?

上図では、 外部用の DNS サーバー (Google Public DNS) と、内部用の DNS サーバー (AD DC 兼 DNS サーバー) を参照する設定になっています。設定者の意図としては、パブリックな名前解決は前者で、 イントラの名前解決は後者で行われることを期待して、こうした誤った設定が行われていることが多いですが、実際にはそのようには機能しません。

実際にイントラ向けの名前解決をしてみると、以下のように優先 DNS サーバーに設定された Google の Public DNS サーバーに問い合わせたものの、Non-existent domain (NXDOMAIN) がかえってきて名前解決に失敗するかと思います。

これは何故かというと、Primary DNS サーバーに設定された Google Public DNS は、社外に公開されていないイントラのゾーン (intra.contoso.local 等) を知りえないからです。Windows OS の DNS クライアント (スタブリゾルバ) としては、エラーを受け取った時点で名前解決は失敗したものとして扱いますので、Secondary DNS サーバーに対して名前解決は試行されません。

では、どのように設定するのが正しいかというと、クライアント端末にはイントラの名前解決ができる内部向けの DNS サーバーを参照させましょう。

そして、参照先の DNS サーバー (AD 兼 DNS サーバー等) においてフォワーダーやルートヒントで外部の名前解決を行えるようにすれば、自身が管理していない外部の名前解決はフォワーダーやルートヒントを利用して行ってくれるようになります。

念のため、[再帰を無効にする] がチェックされていないことも確認しましょう。

これで、外部・内部ともに正常に名前解決が行えるようになったかと思います。

P.S. Azure VM の場合は、OS 内の NIC の設定で参照先の DNS サーバーを指定するのではなく、Azure VNet や Azure としての NIC の設定 (つまり、Azure Portal ) で DNS サーバーを指定しましょう。(OS 内の NIC の設定は触らないのが原則です。)


ExpressRoute の SKU と機能の差異について


ExpressRoute と名の付くサービスが増えてきたので、SKU 毎の機能差をまとめておこうと思います。
(以下は 2019/11 現在の情報に基づきます。)

3 種類の ExpressRoute サービス

  • ExpressRoute Circuit (ExpressRoute 回線):
    接続プロバイダーを介して Azure と 50Mbps – 10Gbps で閉域接続するサービス
    (普通は ExpressRoute といったらこれ)
  • ExpressRoute Global Reach:
    2 つの ExpressRoute 回線を介して、オンプレミス間を接続するサービス
    (例えば、東京・大阪で ExpressRoute 回線を 1 つずつ用意すれば、東阪間を MS Backbone 経由で行える)
  • ExpressRoute Direct:
    Azure のエッジルーターと 10Gbps / 100Gbps で直接接続するサービス
    (要個別申請&国内で提供されているのか不明)

各 SKU の概要

  • ExpressRoute Standard:
    ER の接続場所と同一地域のリージョンにのみ接続可能
    (例えば ER を東京で契約した場合、東日本・西日本リージョンのみに接続可能)
  • ExpressRoute Premium:
    世界中のリージョンに接続可能
    (ER を東京で契約していても、米国や欧州のリージョンにも接続可能)
  • ExpressRoute Local (ExpressRoute Direct 利用時のみ):
    ER の接続場所の最寄のリージョンにのみ接続可能
    (ER を東京で契約した場合、東日本リージョンのみ接続可能)

Standard / Premium の違い

SKUStandardPremium
価格安い高い
接続可能リージョン接続した場所と同一地域世界中の Azure リージョン
Private Peering での経路上限400010000
接続できる VNet 上限1020 – 100 (帯域次第)

PaaS のサービス等で、海外リージョンへの接続性が必要になることも多いので、悩んだら Premium SKU を使っておけばいいと思います。


App Service ドメインで購入したドメインを更新する


App Service ドメインで購入したドメインの期限が迫ってきて、donotreply@secureserver.net のアドレスから、こんなメールが届きました。

内容的には確かに自分が買ったドメインではあるものの、メールの送信元が Azure でも Microsoft でもないし、迷惑メールに仕分けされてたんで一瞬怪しいなぁと思ってググったら、自分のブログが出てきました(

よく考えたら App Service ドメインって裏は GoDaddy 系 (?) で、管理画面は secureserver.net でしたね。一件落着。

Azure ポータルで App Service ドメインの設定を再確認しましたが、自動更新を有効にしてたので特に何もせずにスルーしても平気そうでした。

せっかくなので [ドメインの更新] から手動で更新して、スクショだけ取っておきましたとさ。

おしまい。


Azure Portal や Office 365 への通信は、ExpressRoute のみでは完結しません


[サマリー]

  • ExpressRoute の Microsoft Peering を構成すれば、Azure や Office 365 (要個別承認) の Public IP に対して閉域網で通信できます。
  • ただし、Azure Portal や Office 365 宛の通信は ExpressRoute のみでは完結せず、一部は Internet 宛の通信が必要です。
  • Proxy や Azure Firewall 等で URL フィルターはできますが、ACL や NSG のように IP でフィルターすることはできません。

[詳細]

Azure Portal や Office 365 にアクセスをする際に F12 や Fiddler トレースをとれば明らかなように、単一のページを表示するだけでも裏では多量の通信先へアクセスが行われています。Azure Portal は様々な REST API を叩いて各種リソースの情報を呼び出して表示をしていますが、どのブレード (ページ) を開くかによって REST API も様々ですし、アイコン等は Azure 外の CDN 上でホストされていることもあり、通信先は ExpressRoute でアクセスできる Public IP だけではありません。

このため、完全閉域で Internet に一切アクセスできない環境からは、Azure Portal 等へアクセスをすることはできません。

なお、Proxy や Azure Firewall 等で URL フィルターをしている場合には、以下のブログやドキュメントに記載の URL を許可してあげることで概ね解決できるかと思います。(IP は変動する可能性もあり非公開のため、ACL や NSG で IP フィルターにて制御することはできません。)

※「概ね」と書いているのは、Azure Portal は毎日のように実装が変わるものであり、新機能が追加された際に通信先が追加される可能性も十分考えられるからです。

また、Office 365 については、以下のドキュメントやリンク先の RSS / JSON / PAC ファイルに、ER の疎通可否 (ER 列の「はい / いいえ」)、URL / IP / Port などが詳しくまとまっています。上記 Azure の場合と同様に、ワイルドカード指定で IP 未記載のものもありますので、ACL や NSG で IP フィルターを行うことはできないものと認識しましょう。

IP も FQDN も変動するおそれがありますし、ぶっちゃけ管理工数がバカにならないので、法規制があるような場合を除いては Internet 宛の通信を制限しない方が良いと思います。


Azure VM に Public IP を紐づけられないように制限したい


セキュリティやコンプライアンス上の理由で、Azure VM には直接 Public IP を紐づけられないように制限したいといったシナリオがあるかと思います。そういう場合には Azure Policy を利用することで制限することが可能ですのでご紹介しておきます。

まず、Azure Portal で [ポリシー] の [定義] を開くと、既に用意されている組み込みのポリシーが表示されます。あいにく、組み込みポリシーには Public IP を禁止するようなものがありませんので、 [+ ポリシー定義] から新規ポリシーを作成します。

ポリシー定義の画面では、ポリシー定義の場所 (サブスクリプションなど) を選択して任意の名前を付け、ポリシー ルールの箇所に具体的なポリシーの設定内容を定義します。今回は VM (厳密には NIC) に Public IP を付けることを禁止したいので、リソース タイプが networkInterfaces で、かつ NIC の ipconfigurations に publicIpAddress が設定されていない事を強制するため、以下のようなポリシーを定義します。

ポリシー定義の例

{
  “mode”: “All”,
  “policyRule”: {
    “if”: {
      “allOf”: [
        {
          “field”: “type”,
          “equals”: “Microsoft.Network/networkInterfaces”
        },
        {
          “not”: {
            “field”: “Microsoft.Network/networkInterfaces/ipconfigurations[*].publicIpAddress.id”,
            “exists”: “false”
          }
        }
      ]
    },
    “then”: {
      “effect”: “deny”
    }
  },
  “parameters”: {}
}

ポリシーが作成できたら、[割り当て] からポリシーを適用したいサブスクリプションやリソース グループを選択して割り当てます。

以下のようなメッセージが表示され、初回のスキャンが完了するまでに 30 分ほど時間がかかります。気長に待ちましょう。

初回の評価が終わると、既存のリソースでポリシーに準拠していないリソースがリストアップされます。

また、ポリシーの適用後に NIC に Public IP を紐づけて保存しようとすると、以下のようにエラーになるので、意図した通りに制限できたことが分かります。

JSON でポリシー定義を良い感じ書けば自由に制御できるので、Azure リソースのスキーマを理解したうえで使いこなしましょう。ちなみに、Azure Policy のプロパティに指定できるエイリアスは、Azure PowerShell で調べることが可能なので、この辺を使いこなすと楽だと思います。

https://docs.microsoft.com/ja-jp/azure/governance/policy/tutorials/create-custom-policy-definition#find-the-property-alias


Azure Load Balancer を Basic から Standard に変更する方法


Azure のロードバランサーは Basic / Standard の External (ALB) / Internal (ILB) と 4 パターンありますが、以下のドキュメントにもある通り、SKU を変更することはできません。

SKU 間での移行

SKU は変更不可です。

 重要
このドキュメント全体を確認して、SKU ごとの違いを理解し、シナリオを慎重に検証してください。 シナリオに合わせて追加の変更が必要になる場合があります。

したがって、Basic から Standard に変更する場合は、一度 Basic SKU の LB を削除し、新規で Standard の LB を作る必要があります。

SKU ごとの機能差

ザックリまとめると、SKU ごとの機能差は以下の通りです。

SKU 移行時の注意点

1. LB と Public IP の SKU は統一する必要があります。

つまり、VM に Basic SKU の Public IP を紐づけている状況で、Standard SKU の LB に所属させることはできません。Public IP も Standard SKU のものを新規作成して付け替える必要があります。

2. 可用性セット内の全てのリソースで SKU を統一する必要があります。

可用性セットは、同一の役割のサーバーをグルーピングし、同一の物理サーバー上に配置させないことで、可用性を担保するための仕組みです。言い換えれば、可用性セット内の 1 台の VM は Basic の LB に、もう 1 台の VM は Standard の LB に紐づくといったことはできないため、可用性セット内の全ての VM を同一 SKU の LB 配下に入れる必要があります。

3. VM が Public IP を持たず、Standard ILB にのみ紐づく場合は Internet アクセスができません。

VM に ILB しか紐づいておらず、Public IP もない場合、Internet アクセスができなくなります。Standard ILB は SNAT の機能を有していないため、VM に直接 Public IP を紐づけるか、ILB とは別に ALB (外部 LB) を紐づける必要があります。

あとから構成変更しようとすると割と手間がかかるので、構築時にきちんと設計しましょう。