Private Endpoint が別の Private DNS Zone で有効化された場合に接続できない
まぁ、そうだねぇ、という話なのですが、記事にしておきます。
まず、3 つの Storage Account を考えてみます。
それぞれの Storage Account において、適当な file share を作成してあり、Azure VM からその file share がマウントできるかを確認します。
- Resource group #1 にある Storage Account #1 は Private Endpoint を有効化し、Private DNS Zone #1 に登録
- Resource group #2 にある Storage Account #2 は Private Endpoint を有効化していない
- Resource group #3 にある Storage Account #3 は Private Endpoint を有効化し、Private DNS Zone #3 に登録
この状態で、Resource group #1 にある VM から Storage Account #1 に接続すると、Private Endpoint 経由で接続されます。
次に、Storage Account #2 に接続すると、Public Endpoint 経由で接続が可能です。
で、問題は Storage Account #3 で、nsloookup の結果が返ってきません。(NXDOMAIN)
Private Endpoint を有効化した Storage Account の名前解決の流れ
Private Endpoint を有効化すると、<account-name>.file.core.windows.net に対して、<account-name>.privatelink.file.core.windows.net という CNAME レコードが Azure 内部で作成されます。
そして、この <account-name>.privatelink.file.core.windows.net というレコードは、privatelink.file.core.windows.net という Private DNS Zone によって名前解決されます。
通常の設定であれば Storage Account #1 に対応する <account-name>.privatelink.file.core.windows.net は Private DNS Zone #1 に登録されるので問題はありません。
ただし、Storage Account #3 に対応する <account-name>.privatelink.file.core.windows.net は Private DNS Zone #3 に登録されるので、Private DNS Zone #1 では名前解決できません。
どうすれば解消できるか
書いておきつつあまりすすめられた方法ではないなと思っているのですが、一応の解決策としては Private DNS Zone #1 に Storage Account #3 に対応するレコードを追加する、ということになります。
ここで追加するレコードは、例えば file.tyo20prdstr05a.store.core.windows.net などといった値の CNAME レコードです。
この値は、Storage Account #3 の FQDN を nslookup する途中ででてくるレコードです。
ただし、この tyo20prdstr05a というのはたまたまそこに実態があるだけということであり、これが変わらないことは保証されていないかと思います。
とはいえ、具体的に名前解決した IP アドレスを書くよりかは気持ち的にマシかな、という感じです。
一応、この方法で Storage Account #3 のファイル共有がマウントできることは確認しています。
ただし、繰り返しですが、あくまで workaround かなぁと思っており、確実にこれだ、という解決方法は分からないです。。
Discussion