はじめに

こんにちは！ACS事業部）土居です。

Microsoftの年次大型イベントであるIgnite 2022が始まりました。
Azure関連でも様々な新サービスが発表され注目を集めている中、地味ですが個人的には待望だったAzure DNS Private ResolverがようやくGAになりました。
せっかくですので今回取り上げて紹介してみたいと思います。

azure.microsoft.com

AzureにおけるDNSのハマりポイント

Azureでシステム設計経験がある方なら、その特徴的なDNS周りの仕組みで誰しも一度はハマった経験はあるかと思います。本筋から逸れるため詳細は下記の参考ドキュメントを確認してもらいたいのですが、今回取り上げたいのが以下のようなオンプレミス-Azure間で接続しているような環境での話です。

この環境の場合、オンプレミスからAzure上のプライベートDNSゾーンに登録されているFQDNを使ってアクセスさせたくなります。しかし、AzureのプライベートDNSゾーンがリンクされている仮想ネットワークの既定DNSサーバ（168.63.129.16）は同じ仮想ネットワーク内からしか参照できません。オンプレミスの端末でDNS設定を168.63.129.16に変更しても意味がないのです。

以前までは、Azure上にDNSクエリ転送用のVMを用意し、オンプレミスのDNSサーバー→DNS転送用VM→プライベートDNSゾーンの順で解決させる手法をMicrosoftも推奨していました。しかし、オンプレミスからのアクセスのためだけに、DNS転送用のVMを準備するのはユーザー側に管理負担を強いていました。

オンプレミスのコンピューターからの Azure のホスト名の解決は、対応する仮想ネットワーク内のユーザーが管理する DNS プロキシサーバーにクエリを転送し、プロキシサーバーが解決するために Azure にクエリを転送します。

learn.microsoft.com

Azure DNS Private Resolverが全て解決

Azure DNS Private Resolverは上記のような悩みを解決するためのサービスです。
DNSクエリ転送用のVMをデプロイすることなく、オンプレミス環境から Azure DNS プライベートゾーンにクエリを実行したり、その逆を実行したりできるサービスとなっています。メンテナンス不要で、ゾーン冗長などの高可用性も備えています。価格もクエリの転送量に依存し、VMの準備するよりも安価で利用可能です。

先程の構成も、Azure DNS Private Resolverを利用すると下記のように置き換え可能です。オンプレミスからでもAzure DNS Private Resolverを利用して名前解決が可能になります。

今後はオンプレミスからAzureプライベートDNSゾーンへの名前解決はAzure DNS Private Resolverを積極的に利用していきましょう。

learn.microsoft.com

Azure DNS Private Resolverの仕組み

Azure DNS Private Resolverの動作について確認していきます。
まず、Azure DNS Private Resolverは以下のコンポーネントで構成されています。

コンポーネント	説明
受信エンドポイント	DNSクエリのインバウンドエンドポイントです。Subnet上のIPアドレスが静的に付与されます。オンプレミスの端末からのDNSサーバー指定やフォワーディング先、DNS転送ルールセットの宛先として静的なアドレスを指定します。
送信エンドポイント	DNSクエリのアウトバウンドエンドポイントです。こちらも構成にSubnetが必須ですが、受信エンドポイントと異なり静的なアドレスは付与されません。送信エンドポイントから転送されるDNSクエリは同じVirtual Network内の既定のDNSを参照することでプライベートDNSゾーンを名前解決できます。
DNS転送ルールセット	DNS転送ルールセットは、指定のドメイン名の際にDNSクエリを別のDNSサーバーに転送するといったルールセットを適用することができます。仮想ネットワークにもリンクすることができ、別の仮想ネットワークのプライベートDNSゾーンを参照することもできます。

オンプレミスからはAzure DNS Private Resolverの受信エンドポイントに対してDNSを指定する、もしくはフォワーディングしてやればいいだけなのでとても簡単です。

一方で、Hub-Spoke型のVirtual Network構成を取っている場合は若干複雑になります。
送信エンドポイントは自分が属するVirtual NetworkプライベートDNSゾーンを解決するため、オンプレミスから名前解決ができるように下記の図ではプライベートDNSゾーンはHub側のVirtual Networkにリンクしています。

上記でオンプレミスからのアクセスは問題ありませんが、SpokeのVirtual Network内の端末からはプライベートDNSゾーンがリンクされていないため、名前解決ができなくなります。
そこで登場するのがDNS 転送ルールセットであり、SpokeのVirtual Networkにリンクを行うことでHub側のVirtual NetworkのDNSを参照することが可能となります。

SpokeのVirtual Network内からのクエリ転送の評価プロセスは下記のように公開されています。是非参考にして下さい。

仮想ネットワーク内のクライアントが DNSクエリを発行します。
この仮想ネットワークの DNS サーバーがcustom として指定されている場合、クエリは指定された IP アドレスに転送されます。
既定の (Azure 提供の) DNS サーバーが仮想ネットワークで構成されており、同じ仮想ネットワークにリンクされているプライベートDNS ゾーンがある場合、これらのゾーンが参照されます。
クエリが、仮想ネットワークにリンクされているプライベートDNS ゾーンと一致しない場合は、DNS転送ルールセットの仮想ネットワークリンクが参照されます。
ルールセットリンクが存在しない場合は、クエリの解決に Azure DNS が使用されます。
ルールセットリンクが存在する場合、DNS転送ルールが評価されます。
サフィックスの一致が見つかった場合、クエリは指定されたアドレスに転送されます。
複数の一致が存在する場合は、最も長いサフィックスが使用されます。
一致するものが見つからない場合、DNS転送は行われず、Azure DNS を使用してクエリが解決されます。

Azure DNS Private Resolverの作成

Azure Portalから「DNS Private Resolve」を検索し、実際に作成してみましょう。

まずは、作成するリソースグループやリージョン、名前、DNS Private Resolverのエンドポイントを作成するVirtual Networkなどを指定します。

次に受信エンドポイントと送信エンドポイントを作成します。
サブネットも合わせて新規作成可能なので、ついでに作成してしまいます。

サブネットは、最小で /28 のアドレス空間または最大で /24 のアドレス空間である必要があります。

1 つのサブネットを複数の DNS リゾルバーエンドポイント間で共有することはできません。 1 つのサブネットを使用できるのは、1 つの DNS リゾルバーエンドポイントのみです。

DNS リゾルバーの受信エンドポイントのすべての IP 構成は、同じサブネットを参照する必要があります。 1 つの DNS リゾルバーの受信エンドポイントの IP 構成を複数のサブネットにまたがるようには設定できません。

DNS リゾルバーの受信エンドポイントに使用されるサブネットは、親 DNS リゾルバーによって参照される仮想ネットワーク内にある必要があります。