1. はじめに

IBM Cloud上のVPCでは、IBM Cloud サービスに対してVPE(Virtual Private Endpoint)を定義することで、VPC のサブネットから割り振られるアドレスを使用して接続することができる。
しかし、VPEはあくまで個々のVPCごとの設定・構成であり、VPEを定義したVPC上以外で名前解決を試みても、VPE IPアドレスを返さないという制限がある。この問題を解決するために、新たにDNS Hub/DNS Shared機能が提供されたので、本稿で紹介したい。

2. VPEの名前解決上の問題点

IBM Cloud上のVPCでは、サポートされている IBM Cloud サービスに対してVPE(Virtual Private Endpoint)を定義することで、VPC のサブネットから割り振られるアドレスを使用して接続することができる。

例えば、以下のようにVPEを定義すれば、そのVPEを定義したVPC内部からは、名前解決時にVPEのIPアドレス(=VPC のサブネットから割り振られるアドレス）を返すことが可能となる。

VPEを定義したVPC内のVSIからの名前解決。VPEのIPアドレスを返す

$ cat /etc/resolv.conf
; generated by /usr/sbin/dhclient-script
nameserver 161.26.0.7
nameserver 161.26.0.8

$ dig +noall +ans helloworld.1fdfnyy2ykpt.private.jp-tok.codeengine.appdomain.cloud
helloworld.1fdfnyy2ykpt.private.jp-tok.codeengine.appdomain.cloud. 900 IN A 172.16.0.4

しかし、VPEを定義していないVPCから名前解決をしても、VPEのIPアドレスを返さず、代わりにCSE(Cloud Service Endpoint)のIPアドレスが返る。

VPEを定義したVPCに存在しないVSIからの名前解決。CSEのIPアドレスを返す

$ dig +noall +ans helloworld.1fdfnyy2ykpt.private.jp-tok.codeengine.appdomain.cloud
helloworld.1fdfnyy2ykpt.private.jp-tok.codeengine.appdomain.cloud. 241 IN CNAME	cse.s01.jp-tok.codeengine.appdomain.cloud.
cse.s01.jp-tok.codeengine.appdomain.cloud. 241 IN A 166.9.42.87
cse.s01.jp-tok.codeengine.appdomain.cloud. 241 IN A 166.9.40.80
cse.s01.jp-tok.codeengine.appdomain.cloud. 241 IN A 166.9.44.33

この仕様（？）を元に、複数VPCを利用する際にVPE経由でサービスにアクセスしようとすると、色々問題があることに気付く。

例えば、以下のような構成において、VPC-AからVPC-B/VPC-C/VPC-D上にあるサービスにVPE経由でアクアセスしたい場合であっても、別VPC上に定義されたVPEであるため、VPC-AからはVPC-B/VPC-C/VPC-DにあるVPE IPを得ることができない。

また、以下のようなTransit VPC構成において、オンプレミスからDirect Link経由でアクセスする際に、一般的にVPC-AのVPEはDNS ServicesのCustom Resolverを使えば名前解決はできるが、やはりそのままではVPC-B/VPC-C/VPC-DのVPEの名前解決ができない。

特に、Direct Link経由ではCSEには直接アクセスできないので、仮にTransit VPC構成を組んでもこのままではVPC-B/VPC-C/VPC-D内のサービスにはアクセスできないという問題を抱える。もちろん、VPC-AだけでなくVPC-B/VPC-C/VPC-DにもCustom Resolverを作成し、アクセスするサービスによってそれぞれのCustom Resolverを利用するようにオンプレミス側のDNSでDNS Forwardingを構成するのも１つの解決策ではあるが、構成が非常に複雑になり、連携するサービスが増えるに連れて設定も複雑になる。

3. DNS Hub/DNS Shared機能とは

このような問題を解決する機能がDNS Hub/DNS Shared機能である。
要は、DNS Shared側でのVPE名前解決を、DNS Hub側でも実現可能とする機能である。
これにより、VPC-AをDNS Hubに、VPC-B/VPC-C/VPC-DをDNS Sharedとなるように構成すれば、VPC-AにてVPC-B/VPC-C/VPC-DのVPEの名前解決が可能になる。

また、VPC-A(DNS Hub)にてCustom Resolverを設定すればオンプレミスからもVPC-AのCustom Resolverを通じてVPC-B/VPC-C/VPC-DのVPEの名前解決が可能になるし、VPC-B/VPC-C/VPC-Dが利用するDNSとして161.26.0.7/161.26.0.8の代わりにVPC-AのCustom Resolverを利用することで自身のVPC内のVPEだけでなく、他のVPC内にあるVPEの名前解決が可能となる。

ちなみに個人的にはDNS Hub/DNS Spokeという表現の方が好きなのだが、IBM CloudではDNS Hub/DNS Sharedという表現になっているので、以下の記述ではその表現を踏襲することとする。（以下はDNS Hub機能を設定した際の画面。DNS Hub/DNS Sharedというフラグが付く）

制限事項はこちら。特に重要なのは

DNS Hub/DNS Sharedは別アカウントのVPCでも良いが、同一リージョンのVPCである必要がある。
DNS Hubを複数作成することはできるが、1つのDNS Sharedは複数のDNS Hubに属することはできない（= DNS Sharedは、DNS resolution bindingを１つまでしか作れない）。

4. DNS Hub/DNS Shared機能の設定

4-1. DNSBindingConnector権限の付与

DNS SharedとなるVPCからDNS HubとなるVPCに対して名前解決の許可を与える権限が、DNSBindingConnector権限である。
https://cloud.ibm.com/docs/vpc?topic=vpc-hub-spoke-s2s-auth&interface=ui
source/targetともに、Resource TypeとしてVirtual Private Cloudを選択しておく必要がある（all resourcesに対しては設定できない）。

4-2. DNS Hubを設定する

DNS HubとなるVPC内に既にVPEが存在した場合には、全てPermit DNS Resolution Bindingが有効になっていることを確認する。これが有効になっていないと、DNS Hubを有効にしようとする際にエラーになる。
DNS HubとなるVPC側で、DNS Hubを有効にする。
- Before
- After

4-3. DNS SharedとなるVPC側で、DNS resolution bindingを作成する。

DNS resolution BindingにてCreateを押下
DNS resolution binding名とDNS HubとなるVPC名を指定

こうすることで、DNS Hub/DNS Sharedの構成が完了した。

DNS HubとなったVPCの設定結果
DNS SharedとなったVPCの設定結果

4-4. DNS SharedとなるVPC側のVPEで、`Permit DNS Resolution Binding`を有効にする

どのVPEをDNS Hub側でも名前解決可能とするかを指定するのが、Permit DNS resolution bindingである。DNS Shared側のVPE設定にて、DNS Hub側でも名前解決可能とするVPEに対してPermit DNS resolution bindingを有効にする。

Before
After

これにより、DNS Hub側VPCや、DNS Shared側VPCでのVPE数が2となった。

DNS Hub側VPCでDNS Resolution BindingにおけるVPEの数が2になった。
DNS Shared側VPCでDNS Resolution BindingにおけるVPEの数が2になった。

4-5. 名前解決テスト

以下の通り、DNS Hub側VPCでも名前解決時に、DNS Shared側VPCのVPEのIPを返すようになった。
なお、DNS ServicesのCustom ResolverをDNS Hub側VPCでも作成済みであり、そのresolver locationを指定した結果も同時に確認している。なお、Custom Resolverは作成済みだが、Enabledにしていないことに注意。（これをEnabledにするとDHCPでresolver locationのIPアドレスが/etc/resolv.confに配布される。Disabled状態でもresolver locationのアドレスを明示的に指定すれば名前解決は可能）

DNS Hub/DNS Shared設定前におけるDNS Hub側VPCでの名前解決

[root@new-syasuda-tok1-vpc1 ~]# cat /etc/resolv.conf
; generated by /usr/sbin/dhclient-script
nameserver 161.26.0.7
nameserver 161.26.0.8

# SystemのDNSを利用した名前解決
[root@new-syasuda-tok1-vpc1 ~]# dig +noall +ans helloworld.1fdfnyy2ykpt.private.jp-tok.codeengine.appdomain.cloud
helloworld.1fdfnyy2ykpt.private.jp-tok.codeengine.appdomain.cloud. 300 IN CNAME	cse.s01.jp-tok.codeengine.appdomain.cloud.
cse.s01.jp-tok.codeengine.appdomain.cloud. 300 IN A 166.9.44.33
cse.s01.jp-tok.codeengine.appdomain.cloud. 300 IN A 166.9.42.87
cse.s01.jp-tok.codeengine.appdomain.cloud. 300 IN A 166.9.40.80

# Custom Resolverを指定した名前解決
[root@new-syasuda-tok1-vpc1 ~]# dig +noall +ans helloworld.1fdfnyy2ykpt.private.jp-tok.codeengine.appdomain.cloud @10.0.0.13
helloworld.1fdfnyy2ykpt.private.jp-tok.codeengine.appdomain.cloud. 237 IN CNAME	cse.s01.jp-tok.codeengine.appdomain.cloud.
cse.s01.jp-tok.codeengine.appdomain.cloud. 237 IN A 166.9.40.80
cse.s01.jp-tok.codeengine.appdomain.cloud. 237 IN A 166.9.44.33
cse.s01.jp-tok.codeengine.appdomain.cloud. 237 IN A 166.9.42.87

DNS Hub/DNS Shared設定後におけるDNS Hub側VPCでの名前解決

[root@new-syasuda-tok1-vpc1 ~]# cat /etc/resolv.conf
; generated by /usr/sbin/dhclient-script
nameserver 161.26.0.7
nameserver 161.26.0.8

# SystemのDNSを利用した名前解決
[root@new-syasuda-tok1-vpc1 ~]# dig +noall +ans helloworld.1fdfnyy2ykpt.private.jp-tok.codeengine.appdomain.cloud
helloworld.1fdfnyy2ykpt.private.jp-tok.codeengine.appdomain.cloud. 900 IN A 172.16.0.4

# Custom Resolverを指定した名前解決
[root@new-syasuda-tok1-vpc1 ~]# dig +noall +ans helloworld.1fdfnyy2ykpt.private.jp-tok.codeengine.appdomain.cloud @10.0.0.13
helloworld.1fdfnyy2ykpt.private.jp-tok.codeengine.appdomain.cloud. 900 IN A 172.16.0.4

6. DNS Shared側でもDNS Hubの名前解決を可能にする(DNS HubのCustom ResolverをManualで指定）。

上記の構成により、DNS Hubからは名前解決ができるようになったのは確認できたが、DNS Shared側からもDNS HubのVPEや他のDNS SharedのVPEの名前解決が行いたいので、以下でその構成を行う。

6-1. DNS Hub/DNS Sharedの設定直後の状態

当然DNS Shared内のVPCで、自身のVPC内にあるVPEの名前解決は問題なし。

[root@hub-spoke-test-syasuda1 ~]# cat /etc/resolv.conf
; generated by /usr/sbin/dhclient-script
nameserver 161.26.0.7
nameserver 161.26.0.8

[root@hub-spoke-test-syasuda1 ~]# dig +noall +ans helloworld.1fdfnyy2ykpt.private.jp-tok.codeengine.appdomain.cloud
helloworld.1fdfnyy2ykpt.private.jp-tok.codeengine.appdomain.cloud. 900 IN A 172.16.0.4

ただし、このままでは、DNS Hubや他のDNS SharedにあるVPEの名前解決はできない。

DNS Sharedから、DNS HubにあるVPEのIPアドレスは返らない

[root@hub-spoke-test-syasuda1 ~]# dig +noall +ans 9369fb24-af09-41ba-903e-d7b625a33cba.private.jp-tok.secrets-manager.appdomain.cloud
9369fb24-af09-41ba-903e-d7b625a33cba.private.jp-tok.secrets-manager.appdomain.cloud. 73	IN CNAME secmgr-dp1.jp-tok.proxy.serviceendpoint.cloud.ibm.com.
secmgr-dp1.jp-tok.proxy.serviceendpoint.cloud.ibm.com. 73 IN A 166.9.249.107
secmgr-dp1.jp-tok.proxy.serviceendpoint.cloud.ibm.com. 73 IN A 166.9.249.171
secmgr-dp1.jp-tok.proxy.serviceendpoint.cloud.ibm.com. 73 IN A 166.9.249.158

6-2. DNS Shared側においてDNS resolver settingsを変更

DNS Shared側においてDNS resolve settingsを変更する。

Editを押下
デフォルトはSystem
Manualで例えば、8.8.8.8を指定する

すると、DHCPにて/etc/resolv.confに8.8.8.8が構成されるようになる。

[root@hub-spoke-test-syasuda1 ~]# dhclient -r eth0;dhclient eth0
Killed old client process
[root@hub-spoke-test-syasuda1 ~]# cat /etc/resolv.conf
; generated by /usr/sbin/dhclient-script
nameserver 8.8.8.8

DHCPなので反映されるまでに少し時間がかかります。即時に反映させたい場合は、例えば以下のコマンドを実施すれば良いでしょう。

[root@hub-spoke-test-syasuda1 ~]# dhclient -r eth0;dhclient eth0
Killed old client process

この仕組みを利用して、先述のDNS Hub側に存在するCustom Resolverを指定する。

DNS Hub側に存在するCustom Resolverの設定（再掲）
DNS Shared側のDNS resolver settingsにて、Manualを選択し、Custom Resolverのresolver locationのIPアドレスを入力（できるだけ同じAZで名前解決するように、zone affinityは有効にしておく）
設定結果

この結果、以下のようにDNS Hub側だけでなく、DNS Shared側でもDNS Hubや他のDNS SharedにあるVPEの名前解決が可能になる。

DNS Hub

[root@new-syasuda-tok1-vpc1 ~]# cat /etc/resolv.conf
; generated by /usr/sbin/dhclient-script
nameserver 161.26.0.7
nameserver 161.26.0.8

# DNS Hub VPC（自分自身）にあるVPEの名前解決
[root@new-syasuda-tok1-vpc1 ~]# dig +noall +ans 9369fb24-af09-41ba-903e-d7b625a33cba.private.jp-tok.secrets-manager.appdomain.cloud
9369fb24-af09-41ba-903e-d7b625a33cba.private.jp-tok.secrets-manager.appdomain.cloud. 900 IN A 10.0.0.36

# DNS Shared VPCにあるVPEの名前解決
[root@new-syasuda-tok1-vpc1 ~]# dig +noall +ans helloworld.1fdfnyy2ykpt.private.jp-tok.codeengine.appdomain.cloud
helloworld.1fdfnyy2ykpt.private.jp-tok.codeengine.appdomain.cloud. 900 IN A 172.16.0.4

DNS Shared

# Custom resolverを指定したため、161.26.0.7/161.26.0.8ではなくなった
[root@hub-spoke-test-syasuda1 ~]# cat /etc/resolv.conf
; generated by /usr/sbin/dhclient-script
nameserver 10.0.0.13
nameserver 10.1.0.5
nameserver 10.2.0.5

# DNS Hub VPCにあるVPEの名前解決
[root@hub-spoke-test-syasuda1 ~]# dig +noall +ans 9369fb24-af09-41ba-903e-d7b625a33cba.private.jp-tok.secrets-manager.appdomain.cloud
9369fb24-af09-41ba-903e-d7b625a33cba.private.jp-tok.secrets-manager.appdomain.cloud. 900 IN A 10.0.0.36

# DNS Shared VPC（自分自身）にあるVPEの名前解決
[root@hub-spoke-test-syasuda1 ~]# dig +noall +ans helloworld.1fdfnyy2ykpt.private.jp-tok.codeengine.appdomain.cloud
helloworld.1fdfnyy2ykpt.private.jp-tok.codeengine.appdomain.cloud. 900 IN A 172.16.0.4

7. DNS Shared側でもDNS Hubの名前解決を可能にする(Delegatedで指定）。

DNS resolver settingsでは、SystemとManual以外にDelegatedという指定が可能である。
これは、DNS HubでCustom Resolverが設定されており、なおかつEnabledになっている際に構成が可能である。つまり、DNS Hub側で/etc/resolv.confの設定としてresolver locationのIPアドレスが利用されている場合に利用可能である。

Before
After
custom resolverをEnabledにした結果、DNS Hub側のDNS resolver settingsにおけるDNS resolver serversも10.0.0.13/10.1.0.5/10.2.0.5に更新された。

なお、Custom Resolverを一度Enabledにしてしまうと、DNS HubにDNS Binding設定が残っている限りは、以下のようにDisabledに戻せないので注意（こういう制約があるなら、前項のようにManualで設定した方が良いのではないかと個人的には思う。ただ、DNS resolver settingsのManual設定でresolver locationのIPアドレスを１つ１つ入れていくのが面倒だとか、custom resolverの設定変更をしたときに併せて変更する必要があるので、このようなオプションを設けた意義は理解できる。）。

DNS resolver settingsにて上記の条件を満たした場合は、Delegatedが選択可能である。

Delegatedを選択。DNS hub VPCを指定。
DNS Shared側のDNS resolver settingsにおけるDNS resolver serversも10.0.0.13/10.1.0.5/10.2.0.5に更新された