GitHubドメイン認証がうまくいかない

会社でGitHubを利用するときは組織のドメイン認証を行い、トップ画面に"Verified"マークを表示させることが多いと思います。

GitHubのドメイン認証を行うときは指定のTXTレコードを追加しますが、CloudFrontを使っているときには注意が必要です。

たとえばwww.example.comのドメイン認証を行うとします。このサイトはCloudFrontで配信しており、CloudFrontのドメイン（d***.cloudfront.net）がCNAMEで指定されているとします。

このドメインを認証する場合、GitHubのドキュメントにあるように_github-challenge-***-org.www.example.comのTXTレコードを作成します。

編集したゾーンをデプロイすると、手元の環境で_github-challenge-***-org.www.example.comのTXTレコードが返ってくるようになりました。これで問題なく完了と思っていたのですが、このドメインの認証は失敗してしまいました。

CloudFrontドメインの仕様

CloudFrontディストリビューションを作成すると、自動的にd***.cloudfront.netドメインが設定されます。このドメインにはA、AAAA、SOA、NSレコードが設定（このうちAAAAレコードは無効化可能）されています。このため、www.example.comのCNAMEにd***.cloudfront.netを指定すると、www.example.comが暗黙的なRoute53ゾーンに委任されます。このゾーンは編集できないCloudFront専用のゾーンです。

> doggo d***.cloudfront.net SOA
NAME                            TYPE    CLASS   TTL     ADDRESS                         NAMESERVER
d***.cloudfront.net.  SOA     IN      60s     ns-***.awsdns-***.net.           [fe80::f0fe:***]:53
                                                        awsdns-hostmaster.amazon.com.
                                                        1 7200 900 1209600 86400

> doggo d***.cloudfront.net NS
NAME                            TYPE    CLASS   TTL     ADDRESS                         NAMESERVER
d***.cloudfront.net.  NS      IN      172800s ns-***.awsdns-***.org.          [fe80::f0fe:***]:53
d***.cloudfront.net.  NS      IN      172800s ns-***.awsdns-***.co.uk.        [fe80::f0fe:***]:53
d***.cloudfront.net.  NS      IN      172800s ns-***.awsdns-***.com.            [fe80::f0fe:***]:53
d***.cloudfront.net.  NS      IN      172800s ns-***.awsdns-***.net.           [fe80::f0fe:***]:53

このCNAMEにNSが設定される実装はあまり一般的ではなく、カケハシで使っているCNAME設定型ホスティングサービスではCloudFrontのみです。

GitHubのドメイン認証の仕様

GitHubのドメイン認証は対象ドメインのNSレコードに指定されているDNSサーバが使われます。www.example.comであれば、

www.example.comのNSレコードを解決
www.example.comのNSレコードがなければ、その上位のドメインのNSを検索する（この場合はexample.com）
返ってきたNSレコードから_github-challenge-***-org.www.example.comのTXTレコードを検索する

CloudFrontのドメインをCNAMEに設定している場合NSレコードが追加されるので、GitHubのドメイン認証リクエストがこのNSレコードを使ってしまいます。このNSで指定される暗黙のRoute53ゾーンには認証用TXTレコードはないのでドメイン認証は成功しません。

手元PCから_github-challenge-***-org.www.example.comのTXTレコードを検索すると、example.comのNSでTXTレコードを検索します。www.example.comのNSは使わないため、この現象は発生しません。そのため、設定できているのになぜか失敗するように見えます。

解決方法

CloudFrontのドメインがNSを返さなくなればベストですが、ドキュメントを探してもNSを削除する方法がありませんでした。そのためCNAMEを使わずRoute53に委任し、ALIASレコードを使う必要があります。

example.comがすでにRoute53を使っているドメインなら、CNAMEをAレコードのALIASに差し替えれば完了です。クライアントの名前解決回数が1回減るので一石二鳥です。Route53を使っていなければ、Route53で新しくwww.example.comゾーンを作成し、ドメインを委任することになります。www.example.com以下に別のレコードがある場合は、既存のDNSサーバからRoute53に忘れずにレコードをコピーします。

先述の通り、CloudFrontのドメインは標準でAAAAレコードも設定されます。単純にCNAMEをAレコードに変更しただけだとAAAAレコードが消えてしまい、IPv6で接続できなくなります。AAAAレコードが消えてもIPv4経由で引き続き利用できることがほとんどですが、意図しない設定変更なのは変わりありません。CNAMEと同じ挙動にするためにはAAAAレコードにもALIASの設定が必要です。