パブリックサフィックス（Public Suffix）

概要

パブリックサフィックス（Public Suffix） は、個別のドメイン名を直接登録できる最上位のドメインラベルです。.com、.co.jp、.github.io などがパブリックサフィックスに該当します。eTLD（effective TLD）とも呼ばれ、パブリックサフィックスの直下に登録されたドメイン（example.com、example.co.jp）が「登録ドメイン（eTLD+1）」です。

パブリックサフィックスの概念は DNS の RFC で定義されたものではなく、Mozilla が管理する Public Suffix List（PSL） というデータベースによって運用されています。ブラウザー、メールサービス、CA（認証局）がこのリストを参照し、ドメインの境界を判定します。

パブリックサフィックスの判定が必要な理由はセキュリティです。もし .co.jp がパブリックサフィックスとして認識されなければ、evil.co.jp が .co.jp 全体に有効な Cookie を設定でき、bank.co.jp の Cookie を上書きできてしまいます。同様に、*.co.jp のワイルドカード証明書が発行されると、.co.jp 配下の全ドメインを偽装できます。PSL はこのようなドメイン横断の攻撃を防ぐ境界線を定義しています。

仕組み

PSL は ICANN セクションとPRIVATE セクションの 2 部構成で、ブラウザーの Cookie 制御、CA の証明書発行判定、DMARC のドメイン境界判定に使われます。

Public Suffix List（PSL）の構造

PSL は Mozilla が GitHub リポジトリ（publicsuffix/list）で管理するテキストファイルです。リストは 2 つのセクションで構成されます。

ICANN セクション には、ICANN が管理する TLD とその配下のパブリックサフィックスが記載されています。.com、.net、.co.jp、.ac.uk など、レジストリが管理する正規のドメイン階層です。

PRIVATE セクション には、企業やサービスが運営するホスティングドメインが記載されています。github.io、herokuapp.com、s3.amazonaws.com など、複数のユーザーがサブドメインを共有するサービスが該当します。

// ===BEGIN ICANN DOMAINS===
com
co.jp
ac.uk
// ===END ICANN DOMAINS===

// ===BEGIN PRIVATE DOMAINS===
github.io
herokuapp.com
// ===END PRIVATE DOMAINS===

eTLD と eTLD+1

パブリックサフィックスを基準にしたドメインの分類です。

ドメイン	パブリックサフィックス（eTLD）	登録ドメイン（eTLD+1）
www.example.com	com	example.com
app.example.co.jp	co.jp	example.co.jp
user.github.io	github.io	user.github.io

github.io がパブリックサフィックスに登録されていることで、user1.github.io と user2.github.io は別の登録ドメインとして扱われます。Cookie やセキュリティの境界が両者の間に引かれます。

ブラウザーでの利用

ブラウザーは PSL を参照して以下の判定を行います。

Cookie のスコープ制限: example.com のページは .example.com に有効な Cookie を設定できますが、.com に有効な Cookie は設定できません。.com はパブリックサフィックスであり、他のすべての .com ドメインに影響する Cookie の設定をブラウザーが拒否します。

同一サイト判定: Cookie の SameSite 属性やブラウザーのセキュリティポリシーは、eTLD+1 を基準に「同じサイトかどうか」を判定します。www.example.com と api.example.com は同一サイトですが、example.com と example.org は異なるサイトです。

HSTS プリロード: HSTS（HTTP Strict Transport Security）のプリロードリストもパブリックサフィックスの概念を参照しています。

CA（認証局）での利用

CA/Browser Forum の Baseline Requirements は、パブリックサフィックスに対するワイルドカード証明書の発行を禁止しています。*.com や *.co.jp のワイルドカード証明書が発行されると、そのサフィックス配下の全ドメインを偽装できてしまうためです。CA は証明書の発行時に PSL を参照し、リクエストされたドメインがパブリックサフィックスそのものでないことを確認します。

具体例

PSL の判定結果がセキュリティにどう影響するかの具体例です。

Cookie のスコープ

サイト: shop.example.com

# 許可される Cookie 設定
Set-Cookie: session=abc; Domain=.example.com
  → example.com のサブドメインで共有される（OK）

# ブラウザーが拒否する Cookie 設定
Set-Cookie: session=abc; Domain=.com
  → .com はパブリックサフィックスのため拒否

github.io のケース

github.io が PSL に登録されていない場合を仮定すると次のようになります。

# PSL に github.io がない場合（仮定）
user1.github.io が Domain=.github.io の Cookie を設定
  → user2.github.io でもその Cookie が送信される（危険）

# PSL に github.io がある場合（実際の動作）
user1.github.io が Domain=.github.io の Cookie を設定しようとする
  → ブラウザーが拒否（github.io はパブリックサフィックス）

確認方法

特定のドメインがパブリックサフィックスかどうかは、PSL のデータを参照して判定します。

# PSL の最新データを取得
curl -s "https://publicsuffix.org/list/public_suffix_list.dat" | head -50

ドメインの NS レコードを確認することで、ドメイン階層の構造を把握できます。

# ドメインの NS レコードを確認
dig NS example.com

# TLD の NS レコードを確認
dig NS com.

外部の視点からも確認したい場合は、Labee Dev Toolbox の DNS API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/dns?domain=example.com&type=NS"

{
  "success": true,
  "data": {
    "domain": "example.com",
    "records": {
      "NS": [
        "ns1.example.com",
        "ns2.example.com"
      ]
    }
  },
  "error": null,
  "meta": { "responseTime": 45 }
}

よくある問題

PSL への登録漏れや更新の反映遅延が、Cookie の分離不備やセキュリティ境界の誤判定を引き起こします。

PSL への登録漏れによる Cookie スコープの問題

ホスティングサービスが新しいドメイン（例: myapp.dev）でユーザーにサブドメインを提供する場合、PSL に登録しないとユーザー間の Cookie 分離ができません。user1.myapp.dev が設定した Cookie が user2.myapp.dev に送信される状態になります。ホスティングサービスの運営者は、ユーザーにサブドメインを提供する前に PSL への登録を申請する必要があります。

PSL の更新タイミング

PSL は定期的に更新されますが、ブラウザーへの反映はブラウザーのリリースサイクルに依存します。Firefox と Chrome はそれぞれ独自のタイミングで PSL を更新しています。PSL に新しいエントリを追加しても、すべてのユーザーのブラウザーに反映されるまで数週間〜数か月かかることがあります。

ccTLD のサブ階層が PSL に未登録

一部の ccTLD は複雑なサブ階層を持ちます。例えば .jp の下には .co.jp、.ac.jp、.ne.jp などがあり、それぞれがパブリックサフィックスです。PSL にこれらが正しく登録されていなければ、evil.co.jp が .co.jp 全体に Cookie を設定できる脆弱性が生じます。ccTLD の管理者は自身のドメイン階層を PSL に正確に反映する責任があります。