背景

静的ファイルを別ドメインのCDNから配信したい

• zenn.devで利用しているNext.jsではビルド時に静的ファイルが_next/staticディレクトリの中に書き出される
• このファイルをもともとアプリ同一ドメインであるzenn.devから配信していた（https://zenn.dev/_next/static/foo.jsのようなイメージ）
  • ちなみに前も今もGoogle Cloud CDNを使っている
• しかし同一ドメインから静的ファイルを配信する場合、zenn.devのcookieが静的ファイルへのリクエストにまでついてしまう
  • パフォーマンスと安全性の観点から必要なエンドポイントにのみcookieを送信したい

サブドメインではなく別ドメインにしたい

• cookieをセットするときにdomain属性を空にすればcookieはサブドメイン（例 example.zenn.dev）には送られない（参考: CookieのDomain属性は 指定しない が一番安全）
• しかし、外部サービスによりつけられるcookieはコントロールしづらいことがある。例えばGoogle Analytics（GA）やStripeのcookieなど。※ GAは設定を変えられることは確認済み
• そこで静的ファイルの配信には別ドメイン（zncdn.dev）を使うことに。CDNにはCloud CDNを継続して利用

発生した問題1. 一部のインターネットプロバイダーを使用しているユーザーが静的ファイルにアクセスできない

• 静的ファイルの配信元を別ドメイン（zncdn.dev）に切り替えたところ、Twitterで「Zennのスタイルがあたらなくなった」という声を観測
• ヒアリングしたところ一部のインターネットプロバイダーでzncdn.devの静的ファイルへのアクセスがブロックされていることが分かった（J:COMユーザーが多かった）

原因（憶測）

• GCPでの設定時、もともと別の用途で使っていたCDNのために確保した静的外部IPアドレスを使いまわしてしまった。具体的にはstatic.zenn.devというドメインを紐付けていたIPアドレスをzncdn.devにそのまま使ってしまった
• その直後にTerraformのapplyの都合でzncdn.devに別のIPアドレスに紐付け直したことが影響しているかもしれない
• このへんの動きがフィッシングサイトっぽくてブロックされたんじゃないか？と疑ってるが実際のところどうなのかは分からない

解決策

• 新しいドメインを取得し、新しい静的外部IPアドレスに紐付けた。問題が発生していたユーザーが問題なくアクセスできるようになったことを確認したうえでNext.jsのアセットの読み込み元を変更

発生した問題2. 一部の会社のインターネット環境からアクセスできない

• 新・新ドメインでもブロックされてしまうことがある模様
• たぶんその会社に導入されているフィルタリングソフトによって弾かれている
• 色々と調べてみると、とあるフィルタリングソフトのフォーラムで「うちの製品はドメインが取得されてから30日間はそのドメインを信頼できないものとみなすよ」的な記述を発見。ドメインを取ってからまだ1週間ほどしか経っていないのでそれが原因でブロックされているのかもしれない

解決策

• とりあえず様子見か？

新しいドメインを問答無用でブロックしてしまうソフトもあるらしい。一度もどすか・・・

https://twitter.com/nothink/status/1469522320641622020?s=21