Cloudflare Pagesではデフォルトで{プロジェクト名}-{乱数}.pages.devというドメイン名を自動的に発行してくれるのですが、そのままでは使いにくいので大体の方はカスタムドメイン名を割り当てていると思います。本ブログもCloudFlare Pagesにcitronlimes.comというカスタムドメインを割り当てています。

カスタムドメインのDNSレコードはCloudflare上のDNSゾーンに自動的に作成されるのですが、よくみるとなんかinfoマークが出ていました。

マウスオーバーすると、

CNAME records normally can not be on the zone apex. We use CNAME flattening to make it possible.

と出ており、なんか普通だとダメだけどcloudflareだからできてるよ、的なことが言われてます。

zone apexは独自ドメインのトップドメインになります。例えば、本サイトではcitronlimes.comというドメインを利用していますが、これがzone apexになります。逆に、www.citronlimes.comのようなドメインはサブドメインと呼ばれます。

zone apexは独自ドメインのトップドメインになるので、NSレコードやSOAレコードなどが必ず存在しています。

CNAMEレコードは同一ドメインの他のレコードが存在できないという制約があるため、上述の通りNSレコードなどが存在しているzone apexだとこの制約に抵触してしまい、CNAMEレコードが生成できません。

冒頭の画像に戻りますが、この画像ではcitronlimes.comというドメインにCNAME作成された状態になっているように表示されています。これはCNAMEの制約からするとあり得ない話のはずですが、なぜ問題なくこのサイトが表示できているのでしょうか？

その仕組みがCNAME flatteningになります。CNAME flatteningについてはこちらに詳しい解説が書いてありますが、一言で言うと、cloudflare側がCNAMEの向き先のIPを事前に取得しておいて、AレコードとしてそのIPを返してくれる、という仕組みになっているみたいです。クライアントからするとAレコードが返っている状態になっているので、zone apexでも全く問題なくCNAMEレコードが定義できているように見えているんですね。

digってみました。

1$ dig citronlimes.com
2
3; <<>> DiG 9.10.6 <<>> citronlimes.com
4;; global options: +cmd
5;; Got answer:
6;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53520
7;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
8
9;; OPT PSEUDOSECTION:
10; EDNS: version: 0, flags:; udp: 512
11;; QUESTION SECTION:
12;citronlimes.com.               IN      A
13
14;; ANSWER SECTION:
15citronlimes.com.        300     IN      A       104.21.44.61
16citronlimes.com.        300     IN      A       172.67.196.85

確かに、citronliems.comはCNAMEレコードでなくAレコードとして返ってきていることがわかると思います。

この仕組みを聞いたとき、頭の中にAWS　Route53のAliasレコードの話が思い浮かびました。Aliasレコード¹はELBなどのマネージドなサービスのカスタムドメイン名として利用できるレコードで、動的にAレコードが生成されることによってzone apexでも利用できるような仕組みになっています。Cloudflareでもこれとほぼ同様な仕組みが実装されていると思うと、一つの場所で学んだ知識が別の場所でに立っている感じがあっておもしろいですね。

今回は小ネタでしたが、以上です。