IaaS DNSフォワーダでAzure-オンプレ(クロスプレミス)の名前解決を実現する

モチベ

• Azureにおけるクロスプレミスの名前解決はAzure CAF上はAzure DNS Private Resolverを使えというのが推奨になっている
• 同サービスは比較的最近GAしたものであり、IaaSでフォワーダを立てたい場面が結構ある
• しかし、(オンプレミスの技術の延長にあるためか)文献が少ない
• 改めて一通りの検証をクラウド上でやっておきたい

そもそも何故クロスプレミスの名前解決を検討する必要があるか

• Azure DNSをホストしているエンドポイント168.63.129.10はAzure上のリソースからしか到達できない特殊なものとなっている
  • ここでのAzure DNSはいわゆるパブリックなコンテンツサーバであるところのAzure DNSパブリックゾーンとは異なり、DNSリゾルバを指す
• このエンドポイントは特に、Private DNSゾーンを利用する際には切っても切れない関係にあり、Private DNSゾーンへの問い合わせにはこのアドレスを経由する必要がある
  • つまり、Private Endpointを利用しようと思うと確実にこの話が出てくる
  • しかし、オンプレミスから直接このアドレスに到達できないため、Azure上にそのDNS要求を仲介してくれる存在が必要

こんな感じで、クロスプレミスの名前解決はネットワーク構成と共に検討される。今回はAzure側の仲介役として、従来から用いられるIaaSでのDNSフォワーダを利用する場合を検討する。

アーキテクチャ

• 基本は例のbicepから展開
• オンプレ側にはActive Directory用のWindows Serverを追加
• クラウド側にはDNSフォワーダ用のWindows Serverを追加
• クラウド側にストレージアカウントおよび対応するPrivate Endpoint/Private DNS Zoneを作成
  

構築

オンプレADの構築

• ドメイン名は適当にad.zukako.comにした
• オンプレVNETではDNSサーバをカスタムでこのADサーバのIPを指定
• これだけだと、外部への名前解決ができないのでためオンプレ側のDNS設定として8.8.8.8をフォワード先に指定
  
• VMを再起動する

クラウドDNSフォワーダの構築

• こちらはADDSではなくDNSサービスをインストールする

クラウドDNSフォワーダ側の設定

• まずはきちんとPrivate Endpointの名前解決ができるか確認 > 問題なさそう

$ nslookup dnsteststrg.blob.core.windows.net
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
Name:    dnsteststrg.privatelink.blob.core.windows.net
Address:  10.0.1.6
Aliases:  dnsteststrg.blob.core.windows.net

• フォワーダ(このフォワーダVMが実際にDNS要求を転送する先)にAzureDNSを追加する
  • そもそもそれがしたいがためのサーバ
    

オンプレ側からの名前解決の検証

• 何も設定していない状態だと、パブリックに解決されること確認する

$ nslookup dnsteststrg.blob.core.windows.net
Server:  UnKnown
Address:  ::1

Non-authoritative answer:
Name:    blob.tyo22prdstr09a.store.core.windows.net
Address:  20.60.172.132
Aliases:  dnsteststrg.blob.core.windows.net
          dnsteststrg.privatelink.blob.core.windows.net

• nslookupに使用するDNSサーバをクラウド側DNSフォワーダにしてみると、、、プライベートに解決される

$ nslookup dnsteststrg.blob.core.windows.net 10.0.1.5
Server:  clouddnsfwd.internal.cloudapp.net
Address:  10.0.1.5

Non-authoritative answer:
Name:    dnsteststrg.privatelink.blob.core.windows.net
Address:  10.0.1.6
Aliases:  dnsteststrg.blob.core.windows.net

オンプレAD側に条件付きフォワーダとしてクラウド側DNSフォワーダを追加

• このFQDNに対するDNS要求がAzure側のDNSフォワーダに飛ぶように条件付きフォワーダを設定

  • 登録するタイミングで[ｘ]マークが表示されるが、クラウド側のDNSフォワーダが外部のものでもなく、ad.zukako.comドメインにも参加しておらず名前解決ができないためそのように表示される
    

  • IPアドレスが登録できればOK
    

• この設定をすると、明示的にDNSサーバを指定しなくてもプライベートに解決されるようになる

$ nslookup dnsteststrg.privatelink.blob.core.windows.net
Server:  UnKnown
Address:  ::1

Non-authoritative answer:
Name:    dnsteststrg.privatelink.blob.core.windows.net
Address:  10.0.1.6

Azure > オンプレへの名前解決

クラウド側DNSフォワーダ上で条件付きフォワーダの設定

• オンプレドメインはオンプレADで名前解決するように設定
  

• これだけでは、クラウド側のDNSサーバはVNETの既定の設定でAzureDNSを参照してしまう

$ nslookup onpad.ad.zukako.com
Server:  UnKnown
Address:  168.63.129.16

*** Unknown can't find onpad.ad.zukako.com: Non-existent domain

• 自身をDNSサーバとして参照するように変更する
  

動作確認

• きちんとオンプレ側のドメインも名前解決できている

$ nslookup onpad.ad.zukako.com
Server:  clouddnsfwd.internal.cloudapp.net
Address:  10.0.1.5

Non-authoritative answer:
Name:    onpad.ad.zukako.com
Address:  10.100.1.5

• Private Endpointの名前解決も問題なさそう

$ nslookup dnsteststrg.privatelink.blob.core.windows.net
Server:  clouddnsfwd.internal.cloudapp.net
Address:  10.0.1.5

Non-authoritative answer:
Name:    dnsteststrg.privatelink.blob.core.windows.net
Address:  10.0.1.6

おわり

• クロスプレミスの名前解決にはAzure DNS Private Resolverが推奨されているが、双方向の名前解決もAzure IaaSで構築できることは確認できた
• Azure上のVM群はすべてDNSフォワーダを参照して、オンプレドメインについてはオンプレADに、Private EndpointについてはAzure DNSに、みたいなことは普通にできそう
• 場合によっては、「クラウド側VNETはDNSサーバをカスタムIPですべてオンプレADを向ける」かつ「AzureDNSが必要なドメインについてはAzureフォワーダVMへ投げる」ことも考えられそう
  • その場合は、NICレベルのDNSサーバ設定で、AzureフォワーダVMだけは自身を向くように設定する必要がある