[61] public suffix あるいは eTLD (effective TLD) は、 TLD や、 co.jp など実質的に TLD のように機能するドメインです。 TLD 内のサブドメインの構造は TLD ごとに異なるため、 機械的に eTLD を決定することはできません。 そのため Public Suffix List (PSL) として一覧表が管理されています。

[62] public suffix は、1つのサイトeTLD+1の単位を決めるもので、 セキュリティー上も極めて重要となっています。

[63] 例えば example.co.jp や a.example.co.jp の public suffix は co.jp で、 example.co.jp がサイトeTLD+1の単位となります。もし example.co.jp がドメインが co.jp や jp のクッキーを発行できてしまうと、 異なるサイトeTLD+1であるはずの test.co.jp にも干渉できてしまいます。 それを防ぐため、 クッキーの処理で PSL を参照することになっています。

[119] 昔からクッキーの適用可能範囲の決定など重要なところで使われていたのですが、 近年では SameSite のようにWeb開発者の目に直接触れるところでも、 目立って使われるようになってきました。 Web開発の現場でますます重要な概念となるとみられます。

仕様書

意味

[33] PSL に掲載されたドメイン (public suffix) は、 ICANNドメインと私的ドメインに分類されます >>15。

[34] ICANN ドメインICANN domainは gTLD や ccTLD と、 それらの下位で分類を表す (gTLD や ccTLD の管理者が決定した) ドメインです。

[58] com, jp, co.jp, info などがあります。

[35] 私的ドメインPRIVATE domainは、 私企業等 (独自のドメイン階層の販売者、クラウドサービス事業者、DDNS 事業者等) が自身の保有するドメインを第三者に割り当てているものです。

[59] blogspot.com や github.io などがあります。

[78] 名前解決や DNS のプロトコル上は、 両者に特別な違いはありません。 運用上、 ICANN から直接認知されているかどうかが違うだけです。

[129] ICANNドメインは比較的安定しており、 私的ドメインはドメインの失効や売却、事業変更などで流動的ではありますが、 ICANNドメインの構造が変更されることも少なからずありませんし、 安定して運用されている私的ドメインもありますから、 性格の違いはあまりありません。

[130] ICANNドメインは ICANN の指針に基づき比較的公正に運用されているとされますが、 運用企業の方針や所属国家の政治的影響も受けていますから、 決定的な違いともいえません。

[131] 私的ドメインは (サブドメインではない) そのドメイン自体でサービスが提供されることが大多数で、 ICANNドメインはそうでないことが多いというのが重要な違いです。 そのためにICANNドメインのそのドメイン自体の機能が制限されても構わないとされながら、 私的ドメインの機能が制限されると困るという場面があります。 そうはいうものの、 ICANNドメインそれ自体でサービスが提供される事例も皆無ではないので、 これもやはり根本的な違いとまではいえないのですが、重大な違いではあります。

[60] public suffix や eTLD というとき、特に注記がなければ普通はこれら両方を合わせて指しています。

[121] public suffix であるドメイン名を public suffix list domain という言い方をすることがあるようです。 どこかで定義された用語ではなく、俗用でしょうか。

[120] public suffix (パブリックサフィックス) の安定した訳語は見当たりません。 原則通りに訳すなら公的接尾辞ないし公衆接尾辞でしょうか。 PSL (パブリックサフィックスリスト) は公衆接尾辞リストなどとなります。 まああえて訳すまでもないかもしれません。

演算

PSL に含まれるか否か

[21] Set-Cookie: ヘッダーの Domain 属性の処理では、 PSL を参照して検査します。 Cookie の利用者エージェントは、できれば最新の public suffix のリストを使うべきです >>20。

PSL ICANN DOMAINS か否か

[41] Chrome は、ワイルドカード証明書について、 ワイルドカード + ICANN DOMAINS になっていると一致させません。

[32] BR に従う CA は PSL の ICANN DOMAINS に掲載された public suffix のみについてのワイルドカード証明書を発行してはなりません。

ワイルドカード証明書を参照。

PSL に含まれるか、 . + 入力が PSL と末尾一致するかのいずれかであるか否か

[24] document.domain の設定器は、 新しい値が適切かどうか Public Suffix List によって検査しなければなりません >>23。

[43] これより、関連する類似起源閲覧文脈群の単位の決定に PSL が影響します。

[86] 文字列接尾辞がホスト元ホストの登録可能ドメイン接尾辞であるか等しいis a registrable domain suffix of or is equal toかどうかは、 次のように定められます >>85。

  1. [87] 接尾辞が空文字列の場合、
    1. [88] 偽を返し、ここで停止します。
  2. [89] ホストを、接尾辞にホスト構文解析器を適用した結果に設定します。
  3. [90] ホストが失敗なら、
    1. [91] 偽を返し、ここで停止します。
  4. [92] ホストと元ホストがホスト等価でない場合、
    1. [93]
      • [94] ホストがドメインでない
      • [95] 元ホストがドメインでない
      • [96] .ラベル分離子 とホストを連結したものが元ホストに末尾一致しない
      • [97] ホストがホストの public suffix と等しいhost equals
      ... のいずれかの場合、
      1. [99] 偽を返し、ここで停止します。
  5. [100] 真を返します。

[101] なお、 PSL との比較の際には PSL 側の値にもホスト構文解析器を適用しなければなりません >>85。

[102] 次の場面で呼び出されます。

  • document.domain

ドメインの public suffix

[42] eTLD+1 は、その定義より、 PSL に依存して決まります。 DMARC の Organizational Domain も同じ意味のようです。

[26] IsSearchProviderInstalled メソッドは、 判定に Public Suffix List を使わなければなりません >>25。

[46] Firefox は、設定画面や履歴表示、アドレスバーの表示をサイトeTLD+1単位とするため、 PSL を使っています >>45。

[49] Chrome は、アドレスバーの入力が URL か検索語か判断するために PSL を使っています >>45。

[44] Let's Encrypt は証明書発行頻度制限に PSL (eTLD+1) を使っています >>45。

不適用

[65] WPAD の処理にも PSL を適用して良さそうなものですが、 実装は他の方法を採っているようです。

[67] includeSubDomains の処理にも適用されても良いのかもしれませんが、 そうはなっていないようです。

データファイル

[57] PSL 由来のデータを含む各種プログラミング言語用ライブラリーなどもありますが、 PSL はかなり頻繁に更新されていますから、それにどのように追随するのかはよく検討する必要があります。 データファイルがライブラリーに埋め込まれていて、たまにしか更新されないものや、 ライブラリー自体は頻繁に更新されていてもパッケージマネージャーの都合や自社独自の指針などで依存ライブラリーをたまにしか更新できないような場合、 誤った結果を返したり、場合によってはセキュリティー的に問題のある状態となることもありますから、 注意が必要です。

変化

[77] PSL は、数日ごとに更新されています。実装は、それなりの頻度でこれに追随する必要があります。

[70] PSL の内容が変化する (のを実装がデータファイル更新により適用する) ことで、 プロトコル要素の処理が変化します。それによって、それまで可能だった操作があるときから不可能になったり、 その逆になったりすることがあります。

[71] 例えばある時点まで document.domain の設定により通信できていた Webサイト同士が、ある時から通信できなくなるかもしれません。

[72] ある意味でこれは非互換な変更が予期せぬタイミングで突然発生するものですが、 実用上はそれが問題となることはまずありません。 PSL はドメイン名管理機関の意向に従い変更されますから、 そもそもそれと矛盾する形で利用されているのはおかしな話です。

[73] ただ、新規に追加された gTLD と矛盾する内部名を使っていたケースでは、 問題が発生する可能性はあります。

代替ルート

[79] PSL は、代替ルートには対応していません。

[80] これは、ある意味で Web が代替ルートと互換性がないことを表します。 代替ルートの提供する非標準の TLD が SLD 以下に public suffix 相当の階層を設けていないのならば問題ありませんが、 設けているのであれば、本来のサイトの範囲を超えてクッキーを設定できるなど、 セキュリティーの問題が発生するかもしれません。

歴史

[54] Mozilla が導入し、管理し続けています。

[55] 他のブラウザーも追随して Mozilla の提供するデータファイルを使うようになりました。 Web 技術の仕様書からも規定の一部として参照されるようになりました。

[56] Mozilla が導入を決めた当初、 DNS 関連事業者等の中には反対する人達もいました。 しかし現にセキュリティーの問題が起こって対策が必要な状況であるにも関わらず、 有効な対案を示すことはできませんでした。

[1] mozilla-central mozilla/netwerk/dns/effective_tld_names.dat ( ( 版)) http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat

[2] draft-pettersen-subtld-structure-10 - The Public Suffix Structure file format and its use for Cookie domain validation ( ( 版)) http://tools.ietf.org/html/draft-pettersen-subtld-structure-10

[3] Bug 25865 – Consider defining Public Suffix ( ( 版)) https://www.w3.org/Bugs/Public/show_bug.cgi?id=25865

[4] Public Suffix List/Uses - MozillaWiki ( ( 版)) https://wiki.mozilla.org/Public_Suffix_List/Uses

[5] Understanding Domain Names in Internet Explorer - IEInternals - Site Home - MSDN Blogs ( ( 版)) http://blogs.msdn.com/b/ieinternals/archive/2009/09/19/private-domain-names-and-public-suffixes-in-internet-explorer.aspx

[6] [IE] Internet Explorer が 2 文字のドメインに対して Cookie を設定しない ( ( 版)) http://support.microsoft.com/kb/310676

[7] Re: [DNSOP] Public Suffix List ( ( 版)) http://www.mail-archive.com/dnsop@ietf.org/msg01002.html

[8] Bug List ( ( 版)) https://bugzilla.mozilla.org/buglist.cgi?component=Networking%3A%20Domain%20Lists

[9] Bug List ( ( 版)) https://bugzilla.mozilla.org/buglist.cgi?component=Networking%3A%20Domain%20Lists

[10] 687165 – Pseudo-TLDs causing problems for Chrome navigations ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=687165

[11] 712640 – Split PSL into "registry" and "owner-requested" sections ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=712640

[12] Public Suffix List - MozillaWiki ( ( 版)) https://wiki.mozilla.org/Public_Suffix_List

[13] 687165 – Pseudo-TLDs causing problems for Chrome navigations ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=687165

[16] draft-pettersen-subtld-structure-10 - The Public Suffix Structure file format and its use for Cookie domain validation ( ( 版)) https://tools.ietf.org/html/draft-pettersen-subtld-structure-10

[17] draft-sullivan-domain-policy-authority-01 - Asserting DNS Administrative Boundaries Within DNS Zones ( ( 版)) http://tools.ietf.org/html/draft-sullivan-domain-policy-authority-01

[18] rhcloud.com on the Public Suffix List | OpenShift Forums ( ( 版)) https://forums.openshift.com/rhcloudcom-on-the-public-suffix-list

[19] IRC logs: freenode / #whatwg / 20121027 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20121027#l-133

[22] draft-pettersen-dns-cookie-validate-05 - Enhanced validation of domains for HTTP State Management Cookies using DNS ( ( 版)) http://tools.ietf.org/html/draft-pettersen-dns-cookie-validate-05

[27] HTML Standard の古い版から派生して W3C HTML WG が変更を加えて出版した HTML 5.0 は、(元の HTML Standard に存在していた) W3C が認めている標準化団体が出版した文書への normative reference を削除するなど不可解な編集により仕様としての整合性に欠いていることがありますが、 Public Suffix List については HTML Standard と同じまま Mozilla の Webサイトを引用している >>28 ようです。

[29] 特許ポリシーに関する独特の解釈に基づき URL Standard への参照を意味の分からない独自の記述に置き換えたり、 仕様書ではない文書であるためなのか microformats wiki への参照を規定から参考に置き換えたりしている W3C HTML 5.0 ですが、 特許ポリシーが存在せず、仕様書でも無い Public Suffix List への参照はなぜか規定のままです。

[30] Public Suffix List - MozillaWiki ( 版) https://wiki.mozilla.org/Public_Suffix_List

[31] ( 版) https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf#page=25

Note: For purposes of determining the appropriate domain name level or Domain Namespace, the registerable

Domain Name is the second-level domain for generic top-level domains (gTLD) such as .com, .net, or .org, or, if the

Fully Qualified Domain Name contains a 2 letter Country Code Top-Level Domain (ccTLD), then the domain level

is whatever is allowed for registration according to the rules of that ccTLD.

[36] Mozilla CA Certificate Inclusion Policy — Mozilla ( 版) https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/

Each dNSName in permittedSubtrees must be a registered domain (with zero or more subdomains) according to the Public Suffix List algorithm.

[37] publicsuffix/list ( 版) https://github.com/publicsuffix/list

[38] Public Suffix List ( 版) https://github.com/publicsuffix

[39] ( 版) https://www.icann.org/en/system/files/files/sac-070-en.pdf

[45] Learn more about the Public Suffix List () https://publicsuffix.org/learn/

[47] [chrome] Contents of /trunk/src/net/tools/tld_cleanup/tld_cleanup.cc ( ()) https://src.chromium.org/viewvc/chrome/trunk/src/net/tools/tld_cleanup/tld_cleanup.cc?view=markup

[48] [chrome] Contents of /trunk/src/net/base/registry_controlled_domains/registry_controlled_domain.cc ( ()) https://src.chromium.org/viewvc/chrome/trunk/src/net/base/registry_controlled_domains/registry_controlled_domain.cc?view=markup

[50] RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC) ( ()) https://tools.ietf.org/html/rfc7489#section-3.2

[51] RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC) ( ()) https://tools.ietf.org/html/rfc7489#appendix-A.6.1

A public suffix list for the purposes of determining the Organizational Domain can be obtained from various sources. The most common one is maintained by the Mozilla Foundation and made public at http://publicsuffix.org. License terms governing the use of that list are available at that URI.

Note that if operators use a variety of public suffix lists, interoperability will be difficult or impossible to guarantee.

[52] >>51 IETF は政治的にこう言わざるを得ないんだろうけど、何か意味があるんだろうか??

[64] Define a host's "public suffix" and "registrable domain" by mikewest · Pull Request #72 · whatwg/url ( ()) https://github.com/whatwg/url/pull/72

[66] draft-sullivan-dbound-problem-statement-02 - DBOUND: DNS Administrative Boundaries Problem Statement ( ()) https://tools.ietf.org/html/draft-sullivan-dbound-problem-statement-02

[68] RFC 7719 - DNS Terminology ( ()) https://tools.ietf.org/html/rfc7719#page-6

Public suffix: "A domain that is controlled by a public registry."

(Quoted from [RFC6265], Section 5.3) A common definition for this

term is a domain under which subdomains can be registered, and on

which HTTP cookies ([RFC6265]) should not be set. There is no

indication in a domain name whether it is a public suffix; that

can only be determined by outside means. In fact, both a domain

and a subdomain of that domain can be public suffixes. At the

time this document is published, the IETF DBOUND Working Group

[DBOUND] is dealing with issues concerning public suffixes.

There is nothing inherent in a domain name to indicate whether it

is a public suffix. One resource for identifying public suffixes

is the Public Suffix List (PSL) maintained by Mozilla

(http://publicsuffix.org/).

For example, at the time this document is published, the "com.au"

domain is listed as a public suffix in the PSL. (Note that this

example might change in the future.)

Note that the term "public suffix" is controversial in the DNS

community for many reasons, and may be significantly changed in

the future. One example of the difficulty of calling a domain a

public suffix is that designation can change over time as the

registration policy for the zone changes, such as the case of the

"uk" TLD around the time this document is published.

[69] RFC 6265 - HTTP State Management Mechanism ( ()) https://tools.ietf.org/html/rfc6265#section-5.3

NOTE: A "public suffix" is a domain that is controlled by a

public registry, such as "com", "co.uk", and "pvt.k12.wy.us".

This step is essential for preventing attacker.com from

disrupting the integrity of example.com by setting a cookie

with a Domain attribute of "com". Unfortunately, the set of

public suffixes (also known as "registry controlled domains")

changes over time. If feasible, user agents SHOULD use an

up-to-date public suffix list, such as the one maintained by

the Mozilla project at http://publicsuffix.org/.

[74] Move lib.de.us to the private section (#256) (weppos著, ) https://github.com/publicsuffix/list/commit/f710559ab1d0b78a625e48dec815698c515bcf81

Per the request of lib.de.us, move it from the ICANN section to the PRIVATE section. This is because some browsers, such as Chrome, prevent wildcard certificates for domains in the ICANN section. lib.de.us centrally manages the infrastructure, and thus hosts a wildcard, but subdomains host independent content and thus need the separation afforded by being on the PSL.

[75] Add new gTLDs up to 2016-08-17 (#291) (sleevi著, ) https://github.com/publicsuffix/list/commit/4dcaacaf593dde7e2a34436913c24af3bf2bdb06

This also moves the KRD entries to the PRIVATE section, to facilitate

the script automation.

[76] 1129618 – please add .onion to public suffix list () https://bugzilla.mozilla.org/show_bug.cgi?id=1129618

[81] Define a host's "public suffix" and "registrable domain" by mikewest · Pull Request #72 · whatwg/url () https://github.com/whatwg/url/pull/72

[82] 25865 – Consider defining Public Suffix () https://www.w3.org/Bugs/Public/show_bug.cgi?id=25865

[83] Define document.domain in terms of a reusable algorithm (jcjones著, ) https://github.com/whatwg/html/commit/03bbc6e92b6b8c9735b4565722916d49fe3eab61

[84] Define document.domain in terms of a reusable algorithm (jcjones著, ) https://github.com/whatwg/html/commit/03bbc6e92b6b8c9735b4565722916d49fe3eab61

[103] KDDIが2文字ドメイン「au.com」を買収していた | スラド IT ( ()) https://it.srad.jp/story/17/03/21/0417257/

au.comは1990年台半ば、アンビューエル・ウラキーというコンサル会社が所有しており、2000年前後にオーストラリアの略としてセカンドレベルドメインの形でサブドメインが販売されいた。KDDIの買収前はNetRegistryという会社が管理していたが、販売が中止され、こちらのフォーラムによると2013年ごろにKDDIにドメイン所有権が移転された模様。買収額などは不明。

[104] Rate Limits - Let's Encrypt - Free SSL/TLS Certificates () https://letsencrypt.org/docs/rate-limits/

The main limit is Certificates per Registered Domain (20 per week). A registered domain is, generally speaking, the part of the domain you purchased from your domain name registrar. For instance, in the name www.example.com, the registered domain is example.com. In new.blog.example.co.uk, the registered domain is example.co.uk. We use the Public Suffix List to calculate the registered domain.

[105] Better document the PSL roadmap and needs · Issue #671 · publicsuffix/list () https://github.com/publicsuffix/list/issues/671

[106] Side effect of "default rule" on disallowed TLDs · Issue #570 · publicsuffix/list () https://github.com/publicsuffix/list/issues/570

[107] Define hosts' public suffix and registrable domain, as well as same site (mikewest著, ) https://github.com/whatwg/url/commit/6a9f7eacaae962b325547f33d6e30134789986a8

[108] Define hosts' public suffix and registrable domain. by mikewest · Pull Request #391 · whatwg/url () https://github.com/whatwg/url/pull/391

[109] Advanced Public Suffix List testing (registrable domain, same site) · Issue #11218 · web-platform-tests/wpt () https://github.com/web-platform-tests/wpt/issues/11218

[110] Build upon URL rather than PSL (annevk著, ) https://github.com/whatwg/html/commit/326c64415ddff5f619433028bd5d99408dad6430

[98] "If the given value is not a registrable domain ..." · Issue #3711 · whatwg/html () https://github.com/whatwg/html/issues/3711

[111] "If the given value is not a registrable domain ..." · Issue #3711 · whatwg/html () https://github.com/whatwg/html/issues/3711

[112] Build upon URL rather than PSL by annevk · Pull Request #3735 · whatwg/html () https://github.com/whatwg/html/pull/3735

[113] net/http/transport_security_state_static.json - chromium/src - Git at Google () https://chromium.googlesource.com/chromium/src/+/master/net/http/transport_security_state_static.json

[114] InternetDomainNameExplained · google/guava Wiki () https://github.com/google/guava/wiki/InternetDomainNameExplained#public-suffixes-and-private-domains

[115] Tracking Preference Expression (DNT) () https://www.w3.org/TR/2019/NOTE-tracking-dnt-20190117/#dfn-site-domain

[116] Suggest use of origin in public suffix warning (mozfreddyb著, ) https://github.com/whatwg/url/commit/0c6e51d2927dbfd2fcb6448795b3e1537b555728

[117] Change warning about specs not depending on PSL · Issue #429 · whatwg/url () https://github.com/whatwg/url/issues/429

[118] Suggest use of origin in warning text (Fixes #429) by mozfreddyb · Pull Request #430 · whatwg/url () https://github.com/whatwg/url/pull/430

[122] Let HTML handle the "same site" definition (domenic, , ) https://github.com/whatwg/url/commit/3703f92854207564b21301418d28a0ac647be06d

[123] Let HTML handle the "same site" definition (domenic, , ) https://github.com/whatwg/url/commit/3703f92854207564b21301418d28a0ac647be06d

[124] 令和5年の Google AdSense の仕様変更から、 PSL + 1 が登録できるドメインの基準の1つになるそうです。

[125] メール送信ドメイン認証を回避する、ドメイン名に見えるもの - 弁護士ドットコム株式会社 Creators’ blog, https://creators.bengo4.com/entry/2025/04/14/073000

[126] >>125 なぜか PRIVATE ドメインの例ばかり出して PSL では解決にならないと主張しているのだが、 PSL が ICANN ドメインと PRIVATE ドメインの2つで構成されていることを知らないのだろうか。 著者はこの分野の専門家だから知らないとも思われないのだが (というか PSL にリンクしているのだからそのときに PSL それ自体を絶対に見ているはずであって)。

[128] >>125 が PSL がクッキー由来と説明しているのは歴史的に事実ではあるし、 現在でも主要な利用目的であることには相違ないのだけれども、 PSL の公式サイトの採用規格リストにまさに DMARC が提示されているように、 インターネットメールも PSL が活用されている場面なのに、 この解説はちょっとなあ。

[127] かつての http://to./ (今はアクセスできない) のように TLD でサービスが提供される事例はあるから、 ICANN ドメインでメールの送受信が行われていても驚かないが、 その実例を探すのは困難かもなあ。