プライベートホステッドゾーン内のレコードに対して、ACM証明書を作りたい時がある。
でもプライベートなのでDNS検証が通らない（ACMはCNAMEレコードを作って名前解決することでDV検証をする）。
そんな時の対応方法を検証したのでメモ。
※若干込み入ってるので、流れがわかりやすいようスクショは最低限としています。
結論
スプリットホライズンDNS（スプリットビューDNS）の構成を取ればいける。
前提条件
プライベートホステッドゾーンprivate.hoge.com内のレコードdummy.private.hoge.comに対してACM証明書を発行し、このレコードに対応するリソース（例えばスキーム＝内部のELB）のHTTPSリスナーで使いたいとする。
この場合、以下のようなドメイン構成を用意する。
| ドメイン名 | タイプ | 備考 |
|---|---|---|
| hoge.com | パブリックホステッドゾーン | レジストラに登録済み |
| private.hoge.com | プライベートホステッドゾーン | 目的のAレコードが存在するゾーン |
hoge.comとprivate.hoge.comがスプリットホライズンDNSの関係にある。
後者はサブドメインのように見えるが、あくまでプライベートホステッドゾーンなので、サブドメイン移譲の設定はしないこと（親ドメインhoge.comにprivate.hoge.comのNSレコードを作成しないこと）。これをやってしまうと、SERVFAILでハマることになる。
証明書発行の流れ
以下の流れで作成すればOK。
1. ACM証明書を作成
dummy.private.hoge.com用の証明書を作る。
ちなみにprivate.hoge.com用としても同じ挙動になる。
2. DNS検証用レコードを作成
ACM画面から、Route 53にCNAMEレコードを直接作成できるので、これを使う。
今回の場合、ACMからパブリックにアクセス可能なhoge.comにレコードが作成される。
これによってDNS検証が可能になる点がポイント。
3. digで検証（オプション）
ACMのDNS検証は自動的に行われるが、少し時間がかかる場合があるので、空き時間にCNAMEレコードの疎通確認をしておく。
以下のようにANSWERセクションが正常に返ってくればOK。
> dig <_で始まる文字列>.private.hoge.com.
...（前略）...
;; ANSWER SECTION:
<_で始まる文字列>.private.hoge.com. 300 IN CNAME <_で始まる別の文字列>.mhbtsbpdnt.acm-validations.aws.
;; AUTHORITY SECTION:
mhbtsbpdnt.acm-validations.aws. 900 IN SOA <NSレコード> awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
...（後略）
4. ACMを確認
早ければ秒単位、長くても分単位でDNS検証が完了し、下記の状態になる。
まとめ
スプリットホライズンDNSの構成を使うことで、プライベートホステッドゾーン内のレコードに対してもACM証明書のDNS検証（DV検証）が通るようになる。
誤って、プライベートホステッドゾーンに対してサブドメイン移譲の設定を行わないようにする点だけ要注意。