この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
コンバンハ、千葉（幸）です。
最近初めてRoute53のプライベートホストゾーンを使いました。
いろいろ理解があいまいだった部分があったのですが、使ってみてようやく整理できたものがあるので記します。ここでは以下の３つの観点を取り上げます。
- NSレコードは登録できない
- 名前空間の重複は可能
- ACMでのパブリック証明書発行のDNS検証には使用できない
目次
プライベートホストゾーンにNSレコードは登録できない
NSレコードについてドキュメントに以下の記述があります。
サブドメインの責任を委任する NS レコードをプライベートホストゾーンに作成することはできません。 プライベートホストゾーンを使用する場合の考慮事項
権限委譲
一般的にNSレコードが必要になるのは、サブドメインに権限委譲を行う際です。パブリックホストゾーンの場合、以下のようなイメージでサブドメインの権限委譲を行うことができます。
Route53でホストゾーンを作成した場合、デフォルトでタイプ「NS」とタイプ「SOA」のレコードセットが作成されます。ここで、親ドメインのホストゾーンにおいて、以下のレコードを追加すれば権限委譲が行えます。
| 名前 | タイプ | 値 |
|---|---|---|
| サブドメインの名称 | NS | サブドメインのホストゾーンのNSレコードの値（ネームサーバ） |
権限委譲された後は、例えば親ドメインにもサブドメインにも「www.sub.example.com」というレコードセットを異なる値で登録したとしても、サブドメインの方が優先されます。
プライベートホストゾーンでは
プライベートホストゾーンではこういった権限委譲ができないため、他のドメインの親ドメインとして機能することができません。 レコードセットの追加時に、タイプ「NS」が選択できないようになっています。
プライベートホストゾーンで名前空間は重複してよい
こちらは比較的新しめのアップデートで、2019年11月に可能になっていました。例えばexample.comというホストゾーンとsub.example.comというホストゾーンを、同一のVPCに関連づけることができます。
重複した場合どういったロジックで判断されるのかと言うと、ルートテーブルのロンゲストマッチ（最長プレフィックス一致）と同じような考え方で、最も具体的に一致する方のホストゾーンを参照するようです。（平たく言うとサブドメインの方が優先される。）
example.com や accounting.example.com など、重複する名前空間を持つ複数のプライベートホストゾーンがある場合、リゾルバー は最も具体的な一致に基づいてトラフィックをルーティングします。 重複する名前空間を持つプライベートホストゾーン
もちろん、ドメイン名が完全一致する場合には重複エラーが出ます。
The VPC that you chose, vpc-0e4acafxxxxxxxxxx in region ap-northeast-1, is already associated with another private hosted zone that has an overlapping name space, example.com..
プライベートホストゾーンでACM証明書発行時のDNS検証はできない
ACMで発行できる証明書には以下の２種類があります。
- パブリック証明書
- プライベート証明書
それぞれの証明書の発行を行う際の検証の仕方には以下があります。
- パブリック証明書
- DNS検証
- Eメール検証
- プライベート証明書
- プライベート認証機関（CA）からのリクエスト
https://docs.aws.amazon.com/ja_jp/acm/latest/userguide/gs.html
このあたりの理解があいまいだったのですが、ACMを利用してプライベートな証明書を発行する場合にはプライベート認証機関（CA）を用いないといけません。プライベートCAはなかなかのお値段がします。
CA を削除するまで、ACM プライベート CA ごとに毎月 400 USD。 AWS Certificate Manager の料金
パブリックな証明書を発行してプライベートな環境で使うということを考えた場合にも、一筋縄では行きません。DNS検証とEメール検証の２種類がありますが、いずれのパターンにおいても、プライベートホストゾーンは検証先としては機能しません。ACMとRoute53でいい感じに連携して発行してくれたりするのでは、とも考えましたが、そのような仕組みは無いようでした。（上位の親ドメインから権限委譲していれば可能かと思いましたが、そういったこともなさそうです。）
このあたりの「プライベートではダメなのか？」については、AWSの仕様というよりはDNS一般の仕様によるものであるため、明確な記述があるAWSドキュメントは見つけられませんでした。以下のトラブルシューティングの記述において、DNS検証においてもメール検証においてもパブリックにアクセス可能なことが前提となっている書き方がされているため、プライベートホストゾーンでは条件を満たせないと理解しました。
- E メールの問題のトラブルシューティング
- 証明書リクエストの問題のトラブルシューティング
- ACM コンソールで [Create record in Route 53 (Route 53 でレコードを作成)] ボタンが表示されない
代替策
例えば以下のように、サブドメインはプライベートホストゾーンであっても、それより上位にパブリックなゾーンがあれば、そこで検証を行うことができます。ここで発行したパブリック証明書をプライベートホストゾーン内のリソース（ELBなど）で使用することができます。
こういった前提でなく、独自のドメイン名でプライベートホストゾーンを使用している場合には、以下の選択肢をとることになります。
- プライベート認証機関（CA）を利用してプライベート証明書を発行する
- 自己署名証明書を用いる
終わりに
使ってみないときちんと分からないものがあるもので、勉強になりました。
権限委譲とは、であったり、ACMを用いて証明書を発行する際のお作法など、自分用のメモの側面が強いですが、同じようなことを試されるどなたかの参考になれば幸いです。
4
