ACM証明書のDNS検証でハマった話

はじめに

こんにちは！

今回は、AWS Certificate Manager (ACM) でSSL/TLS証明書を発行する際に直面した見落としがちなDNSの問題について共有したいと思います。

「ACMのDNS検証？CNAMEレコードを設定すればいいんでしょ？」

そう思われる方がほとんどでしょう。私もそうでした。しかし、今回のケースは一筋縄ではいきませんでした。調査の末、問題の根本原因を特定し、無事に証明書を発行することができました。その過程で得た学びは非常に大きかったので、皆さんの参考になれば幸いです。

発端：いつまでも「保留中の検証」

your-domain.jp というドメインのSSL証明書をACMでリクエストしたのが始まりです。DNS検証を選択し、ACMが提示するCNAMEレコードをRoute 53のホストゾーンに正確に登録しました。
「これで数分後、遅くても翌日には発行されるだろう」と思っていたのですが、ステータスは「保留中の検証」のまま。

初期調査

まず最初に疑ったのは、DNS検証でよくある原因でした。

• CNAMEレコードの入力ミス？

  • Route 53のコンソール画面とACMの提示情報を何度も見比べましたが、名前も値も完全に一致。
  • Route 53の編集画面では、CNAMEレコード名が自動補完されるルール（.your-domain.jp の部分を自動で付与する）も考慮し、サブドメイン部分のみを正しく入力していました。

• DNS情報が広く解決できるようになるのに時間がかかっている？

  • $ dig your-domain.jp NS を実行すると、Route 53のネームサーバー群が返って来ている
  • $ dig CNAME [ACMが提示するCNAMEレコード名]を数時間後、翌日実行しても、まだ NXDOMAIN のまま
  • $ dig CNAME [ACMが提示するCNAMEレコード名][Route53のNSレコード] ではRoute 53の正しいネームサーバーを直接指定して dig CNAME した際にANSWERが得られた

ここで大きな混乱が発生しました。

「NSレコードは解決できるのに、なぜ特定のCNAMEレコードだけ解決できない？」

問題の原因は、「グルーレコードの不一致」と「DNS解決パスの誤誘導」

この状況に対し、社内からアドバイスがありました。

問題は、ドメインの古いグルーレコードが、一見正しいRoute 53のネームサーバーを指しているように見えながらも、実際には再帰問い合わせでの検証用CNAMEレコードの解決を妨げている。
この指摘が、まさに問題解決への突破口でした。

1. グルーレコード」の不一致:
   $ whois your-domain.jp で確認できるネームサーバー（ドメインレジストラに設定されたグルーレコード情報）と、your-domain.jp ホストゾーンのRoute 53に表示されているNSレコードが、実は異なるセットだったのです。whois 情報の最終更新日が数ヶ月前の日付だったことも、レジストラ側の設定変更が反映されていない証拠でした。

2. DNS解決パスの誤誘導:
   インターネット上のDNSリゾルバやACMの検証システムは、your-domain.jp の情報を得るために、まず whoisに記載されたグルーレコード（古いネームサーバー群）に問い合わせに行きます。その古いネームサーバー群にはACM検証用のCNAMEレコードが存在しないため、NXDOMAIN という応答が返され、これがキャッシュされてしまう現象が起きていました。
   一方、Route 53の正しいネームサーバーを直接指定して dig CNAME した際にANSWERが得られたのは、正規のDNS解決経路を通っていなかったためです。

解決までの道のり

原因が特定された後、解決策は明確でした。

1. ドメインレジストラでのNSレコードの最終更新依頼:
   お客様（ドメイン所有者）にご協力いただき、your-domain.jp のネームサーバー設定を、Route 53のホストゾーンに表示されている最新のNSレコードに正確に修正するよう再度依頼しました。

2. DNS情報の解決待ち:
   レジストラ側での変更が反映され、 whois 情報も更新されるのを待ちました。

ACMの証明書が「発行済み (Issued)」に

$ dig CNAME [ACMが提示するCNAMEレコード名] を実行すると、正しくANSWER SECTIONにCNAMEレコードが返ってきました！
そして、AWSマネジメントコンソールのACMを確認すると、証明書のステータスが「保留中の検証」から「発行済み」に変わっていました！

学びと教訓

今回の経験から、以下の非常に重要な教訓を得ることができました。

1. whois 情報とグルーレコードの重要性:
   whois 情報はリアルタイムではないが、ドメインの「権威DNSサーバー」がどこに委任されているかを示す最終的な情報源であり、ここが間違っていると全てのDNS解決が機能しない。ネームサーバー変更時には、dig NS での確認に加え、whois 情報の更新も必須。

2. DNS解決パスの確認:
   dig コマンドだけでなく、dig NS、dig CNAME @[権威NS]、そして dig +trace を活用し、DNS解決の全経路を追跡する重要性。

3. 見せかけの正確さに注意:
   一見正しく見える設定でも、問題の本質を見誤る可能性がある。常に「ユーザーからのリクエストがどのようなDNS解決パスをたどるか」を意識することが重要。

ACM証明書のDNS検証で「保留中」が続く場合、単なるCNAMEレコードの入力ミスだけでなく、ドメインレジストラでのネームサーバー（グルーレコード）設定とRoute 53のNSレコードが完全に一致しているか、そしてDNSの仕組みを厳密に理解することが、問題解決の鍵となることを痛感しました。

もし同じような問題に直面している方がいらっしゃれば、この経験が解決の助けになれば幸いです。

長文にお付き合いいただき、ありがとうございました！