なぜドメインに「www」を付けていたのか

wwwが付いた歴史背景

Web用の名前としてwww、メール用にmail、FTP用にftpなど、役割が分かるホスト名を付ける慣習が広まりました。HTTPやDNSがwwwという名前を必須にしているわけではありません。

当時の考え方

• 役割ごとに名前を分けると、利用者が接続先の用途を見分けやすい。
• DNSで「www=Webサーバー」「ftp=ファイル転送」とわかりやすくした。
• ホスト名と実機は1対1とは限らない。複数の名前を同じサーバーへ向けたり、1つの名前を複数のサーバーで受けたりできる。

DNSの事情とメリット

wwwを付けると、当時のDNS運用が少し楽になることがありました。

ApexとCNAMEの制約

• ゾーン頂点（apex）のexample.comにはSOA・NSが必要。通常のCNAMEはそれらと同じ名前に共存できないため、wwwをCNAMEでCDNへ向ける構成が使われる。
• wwwをCNAMEでCDNに向け、ApexはA/AAAAで自前サーバーに向けるなど、役割分担がしやすかった。

クッキーとサブドメインの切り分け

• wwwからDomain属性なしで設定したCookieはそのホストだけが対象。一方、Domain=example.comを指定すると兄弟サブドメインも対象になり、wwwを付けるだけではCookieは分離されない。
• 同一生成元はスキーム・ホスト・ポートで決まり、wwwの有無が違えば別の生成元。Cookieの送信範囲とは別のルールである。

いまは付けたり付けなかったり

運営者はどちらを使うか選べますが、利用者がURLのwwwを勝手に足したり消したりすると、別サイトや接続エラーになることがあります。

付けない派の理由

• URLを短くシンプルにしたい（Apex直でWebを返す）。
• DNS事業者のALIASやCNAME flatteningなどで、別名の解決結果をA/AAAAとして返せる場合がある。通常のCNAMEを頂点に置く仕組みとは異なり、対応範囲は事業者による。

付ける派の理由

• wwwをCDNにCNAMEで向け、Apexは別の運用にするなど柔軟に構成したい。
• Cookieやサブドメインスコープを切り分けたい。
• 昔からのURL資産を維持したい（SEOやブックマークとの互換）。

実務でのポイント

付ける・付けないは自由ですが、正規URLを1つに決めてブレをなくすのがコツです。

おすすめ

• 同じサイトならwwwあり・なしの一方を正規URLとして、もう一方から恒久リダイレクトする。HTTPSでは転送元の名前にも有効な証明書が必要。DNSのCNAMEだけではブラウザのURLは変わらない。
• HSTS preloadは必須ではない。登録にはincludeSubDomainsなどの条件があり、配下の全サブドメインでHTTPSを維持できるかを先に確認する。
• Cookieのドメイン設定やCORSのOrigin指定が意図通りか確認する。

仕様・関連記事

RFC 2181: CNAME / RFC 6265: Cookie Domain / Cloudflare: CNAME flattening / HSTS preload requirements
DNSの基本 / CORSとプリフライト