「1.1.1.1 は一部の多段 CNAME を解決してくれない」改め「makeshop.jp は 1.1.1.1 をブロックしている」

2023/09/20 追記

以下で有識者からコメントをいただきました。
https://b.hatena.ne.jp/entry/s/zenn.dev/happy_elements/articles/cloudflare_cname_chain
https://twitter.com/tss_ontap_o/status/1704265573482578371

makeshop.jp は 1.1.1.1 を遮断しているらしく、本記事はまさに makeshop.jp で制作したページが見れないことに起因した話題であったため、多段 CNAME は無関係でした。
コメント頂いた皆様、ありがとうございました！

1.1.1.1 をブロックしている SaaS があると思わずに首を傾げていた頃の記事

disclaimer

Dig Web Interface を用いて振る舞いを観測した結果、 1.1.1.1 のみ異なる結果を返したことから本記事のようなタイトルを付けていますが、 1.1.1.1 の振る舞いが正しい可能性もあります。

ことのはじまり

とある SaaS でカスタムドメインを利用するため、 CNAME を以下のように設定したところ、 1.1.1.1 もしくは 1.0.0.1 をネームサーバーとして利用する環境からのみ A レコードの名前解決に失敗するという事象を観測しました。

mydomain.example.com. 600	IN	CNAME	tenant.saas.example.com

現状把握

1.1.1.1 の応答例 (A レコード)

$ dig mydomain.example.com. A @1.1.1.1

; <<>> DiG 9.10.6 <<>> mydomain.example.com. A @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 43535
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 16 74 69 6d 65 20 6c 69 6d 69 74 20 65 78 63 65 65 64 65 64 ("..time limit exceeded")
;; QUESTION SECTION:
;mydomain.example.com.	IN	A

;; Query time: 1010 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Tue Sep 05 20:25:23 JST 2023
;; MSG SIZE  rcvd: 80

1.1.1.1 の応答例 (CNAME レコード)

$ dig mydomain.example.com. CNAME @1.1.1.1

; <<>> DiG 9.10.6 <<>> mydomain.example.com. CNAME @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56797
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;mydomain.example.com.	IN	CNAME

;; ANSWER SECTION:
mydomain.example.com. 600	IN	CNAME	tenant.saas.example.com

;; Query time: 134 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Tue Sep 05 21:45:24 JST 2023
;; MSG SIZE  rcvd: 92

8.8.8.8 の応答例 (A レコード)

$ dig mydomain.example.com. A @8.8.8.8

; <<>> DiG 9.10.6 <<>> mydomain.example.com. A @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11634
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mydomain.example.com.	IN	A

;; ANSWER SECTION:
mydomain.example.com. 600	IN	CNAME	tenant.saas.example.com
tenant.saas.example.com 3600	IN	CNAME	distribution-id.cloudfront.example.net.
distribution-id.cloudfront.example.net. 60 IN	A	192.0.2.1
distribution-id.cloudfront.example.net. 60 IN	A	192.0.2.2
distribution-id.cloudfront.example.net. 60 IN	A	192.0.2.3
distribution-id.cloudfront.example.net. 60 IN	A	192.0.2.4

;; Query time: 48 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Sep 05 20:26:48 JST 2023
;; MSG SIZE  rcvd: 199

8.8.8.8 の応答からも分かる通り、 SaaS より提示されたアドレス tenant.saas.example.com は更にCloudFrontのアドレス distribution-id.cloudfront.example.net. への CNAME レコードが設定されていました。

多段 CNAME が問題 ?

CNAME レコードがチェインすることについて、 RFC1034 には次のように記載がありました。

    52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU

rather than pointing at USC-ISIC.ARPA.  Of course, by the robustness
principle, domain software should not fail when presented with CNAME
chains or loops; CNAME chains should be followed and CNAME loops
signalled as an error.

domain software should not fail when presented with CNAME chains と記載されていますので、CNAME レコードがチェインしていること自体は直ちに DNS の仕様として何かに違反しているわけではなさそうです。
ただし、あくまでも should ですので、多段 CNAME が 1.1.1.1 によってサポートされることを検証する必要があります。

ネームサーバーの問題 ?

SaaS の提供するドメインを利用しないようにしてみる

今回は CloudFront への CNAME だけをホストできればよかったので、自分の管理するドメインで distribution-id.cloudfront.example.net. への CNAME を設定し、 mydomain.example.com. の値を自分の管理するドメインに変更しテストしました。
すると、以下のように応答が得られることから、多段 CNAME 自体はサポートされており、今度は SaaS が提供しているドメインを管理しているネームサーバーが疑わしいことがわかります。

1.1.1.1 の応答例

$ dig mydomain.example.com. @1.1.1.1

; <<>> DiG 9.10.6 <<>> mydomain.example.com. @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36763
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;mydomain.example.com.	IN	A

;; ANSWER SECTION:
mydomain.example.com.	600 IN	CNAME	saas-compatible.example.com.
saas-compatible.example.com. 600	IN	CNAME	distribution-id.cloudfront.example.net.
distribution-id.cloudfront.example.net. 60 IN	A	192.0.2.1
distribution-id.cloudfront.example.net. 60 IN	A	192.0.2.2
distribution-id.cloudfront.example.net. 60 IN	A	192.0.2.3
distribution-id.cloudfront.example.net. 60 IN	A	192.0.2.4

;; Query time: 82 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Tue Sep 05 22:51:02 JST 2023
;; MSG SIZE  rcvd: 185

SaaS が提供するドメインを管理しているネームサーバーを調べる

これは単純に、 +trace オプション付きで dig コマンドを実行することで判明しました。

応答例

; <<>> DiG 9.10.6 <<>> tenant.saas.example.com. +trace @1.1.1.1
;; global options: +cmd
.			516318	IN	NS	a.root-servers.net.
.			516318	IN	NS	b.root-servers.net.
.			516318	IN	NS	c.root-servers.net.
.			516318	IN	NS	d.root-servers.net.
.			516318	IN	NS	e.root-servers.net.
.			516318	IN	NS	f.root-servers.net.
.			516318	IN	NS	g.root-servers.net.
.			516318	IN	NS	h.root-servers.net.
.			516318	IN	NS	i.root-servers.net.
.			516318	IN	NS	j.root-servers.net.
.			516318	IN	NS	k.root-servers.net.
.			516318	IN	NS	l.root-servers.net.
.			516318	IN	NS	m.root-servers.net.
;; Received 1097 bytes from 1.1.1.1#53(1.1.1.1) in 15 ms

# 実際には jp ドメインなので jp ドメイン相当の応答
jp.			172800	IN	NS	a.dns.jp.
jp.			172800	IN	NS	b.dns.jp.
jp.			172800	IN	NS	c.dns.jp.
jp.			172800	IN	NS	d.dns.jp.
jp.			172800	IN	NS	e.dns.jp.
jp.			172800	IN	NS	f.dns.jp.
jp.			172800	IN	NS	g.dns.jp.
jp.			172800	IN	NS	h.dns.jp.
;; Received 843 bytes from 199.7.83.42#53(l.root-servers.net) in 85 ms

# SaaS が管理するドメインのうち、トップレベルドメインは AWS Route53 でホストされている様子
example.com.		86400	IN	NS	ns-1560.awsdns-03.co.uk.
example.com.		86400	IN	NS	ns-794.awsdns-35.net.
example.com.		86400	IN	NS	ns-178.awsdns-22.com.
example.com.		86400	IN	NS	ns-1143.awsdns-14.org.
;; Received 686 bytes from 203.119.1.1#53(a.dns.jp) in 7 ms

# SaaS は途中で独自管理のネームサーバーを運用している様子
saas.example.com.		3600	IN	NS	saas1.example.com.
saas.example.com.		3600	IN	NS	saas2.example.com.
;; Received 120 bytes from 205.251.192.178#53(ns-178.awsdns-22.com) in 189 ms

# 最終的に目的のドメインに到達出来た
tenant.saas.example.com 3600	IN	CNAME	distribution-id.cloudfront.example.net.
;; Received 95 bytes from 192.0.2.1#53(saas2.example.com.) in 14 ms

まとめ

単純な CNAME の設定でも実はトラブルが発生していることがあります。
本事象は Dig Web Interface を用いて調査する限り、 1.1.1.1 のみ発生します。ドメインの設定後は最低限、有名どころのオープンリゾルバ全てで期待通りの結果が得られることをちゃんと確認するようにしましょう。
※ここまでの検証を行った時点で、 SaaS のサポートとのやり取りが必要であり解決に時間がかかることが見込まれるため、当面の対策としては自分たちの管理するドメイン mydomain.example.com. の CNAME に直接 distribution-id.cloudfront.example.net. を指定することで、 SaaS 管理側が CloudFront Distribution を入れ替えない限りは当面は動作するようにしました。