注意したい独自ドメイン設定手順とルールの目次を開く ▼

個人サイト制作：サイトマップへ戻る

注意したい独自ドメイン設定手順とルール

自分のサイトのURLを独自ドメインにしたい人は多いかと。
ただ、気分的な問題と言うより、ある程度の規模とトラフィックがあるサイトなら、独自ドメインにした方が良いと考えています。
信頼性とプロフェッショナルな印象を与えつつ、サイトのアイデンティティを強化できます。
SEOにも効果があり、自分のニーズに合わせたメールアドレスやサブドメインも作成できる。
このページでは、独自ドメインを設定する際、どのような手順を踏めば良いか、また注意点等を書いています。
加えて、当サイトが.orgドメインにしている意図であるとか、そういったものもお伝えしていきます。

注意点

• そもそも、独自ドメインは必須でも何でもありません。
• 大金ではありませんが、独自ドメインはお金がかかります。
• 独自ドメインにしたからと言って、必ずしもSEO効果が期待できるわけではありません。
• 何かしら特殊な環境であった場合、設定にIT知識を要求されるケースがあります。

基礎的な独自ドメインの設定手順

ホスティングサービスの選択

次に、サイトをホストするためのホスティングサービスを選びます。

1. ホスティングプロバイダを選ぶ

ホスティングプロバイダを選びます。

2. ホスティングプランを選択

サイトの規模や必要に応じたホスティングプランを選びます。

3. アカウントを作成

ホスティングプロバイダでアカウントを作成し、ホスティングプランを購入します。

ドメインとホスティングを結びつける

ドメインとホスティングを結びつけるための手順です。

1. DNS設定を変更

ドメインレジストラの管理画面にログインし、DNS設定を変更します。
ホスティングプロバイダが提供するネームサーバーを設定します。

2. ホスティングプロバイダでドメインを設定

ホスティングプロバイダの管理画面にログインし、購入した独自ドメインを追加します。

ウェブサイトのファイルをアップロード

最後に、ウェブサイトのファイルをホスティングプロバイダにアップロードします。

1. ファイルマネージャまたはFTPを使用

ホスティングプロバイダのファイルマネージャまたはFTPクライアントを使用して、ウェブサイトのファイルをアップロードします。

2. サイトの公開

ファイルがアップロードされると、独自ドメインでウェブサイトが公開されます。

まずはサーっと基礎的な流れを把握していただいて。
実際には細かくいろいろあります。
このサイトは2025年3月から独自ドメインを設定したので、その時のことを例にとってご紹介します。

【重要】URLを決める時に守るべきルール

独自ドメインを決める際には、いくつかのルールやベストプラクティスがあります。
全てを守る必要はありませんが、最低限の事柄くらいはあるのですよ。
参考までに、私のWebサイトのURLである https://feinatelier.org を例にとってみますね。

独自ドメインを決める際にこのようなルールを守ることで、ユーザーにとってアクセスしやすく、SEOにも有利なドメインを取得することができます。
次はURLの文字列と商標・著作権の話ですね…

URLの文字列と商標・著作権

他社の商標や著作権を侵害しないように注意することは、独自ドメインを選ぶ際に非常に重要なポイントなのです。
これを怠ると、法的な問題や信頼性の低下、最悪の場合、損害賠償請求などの深刻な事態に発展する可能性があります。
このセクションでは、その理由と具体的な対策について詳しく解説いたします。

1. 商標侵害のリスク

ドメイン名とは、ウェブサイトの住所のことです。
例えば example.com と書くだけで、誰でもそのサイトにアクセスできます。
試しに私のサイトで実験して良いですよ？
「feinatelier.org」と、ブラウザのアドレスバーに入力してください。私のサイトが出てきます。
ちなみに、住所を英語にすると address です。

商標侵害のリスクによって、法的措置やドメイン名の喪失に繋がる可能性も否定できません。
商標権者から使用差し止めや損害賠償の請求を受ける可能性がありますし、紛争解決手続きにより、ドメイン名の登録が取り消されることがあります。

2. 著作権侵害のリスク

著作権は、言うまでもなく文学、音楽、芸術作品などの創作物を保護するための権利です。
他人が創作した独自の名称やキャッチフレーズをドメイン名に使用すると、著作権侵害となる可能性があります。
著作権者から損害賠償や是正措置を求められる事態に発展することがあり、信用を大きく損ないます。

3. 避けるべきURL

4. 商標・著作権侵害を防ぐために

完璧にやるのは難しいでしょう。
でも、次のように事前調査の徹底を心がけると良いです。
どーしても心配なら…
ちゃんとお金を支払って弁理士や知的財産に詳しい弁護士に相談するのが最も安全です。
法的なリスクを正確に把握し、適切なアドバイスを受けることができます。

せっかくの独自ドメインです。
独自のブランド価値を高めるためにも、唯一無二の名称を目指しましょう！
人のふんどしで相撲を取るより、たとえ拙くとも自分だけのURLのほうが、何倍もカッコいいですよ？
私のURLはありきたりなものですが、サイトの規模が拡大するにつれて「フェインアトリエ」といろんな人が覚えてくれるでしょう。

5. 信頼のおける情報源と参照サイト

独自ドメイン取得や商標・著作権に関する詳細な情報は、次のような公的機関や専門団体のサイトで入手できます。

独自ドメインはウェブサイトの顔とも言える重要な要素です。
法的な問題を避け、信頼性の高いサイトを運営するためにも、商標や著作権の侵害には十分な注意が必要です。

とは言え、ぶっちゃけ…

独自ドメイン購入は後回しでもいい

AIの言いなりでDNS設定はNG

障害発生の原因になる

DNSレコードは、ウェブサイトやメールサーバーの正しい動作を保証します。
例えば、AレコードやCNAMEを誤って設定すると、ウェブサイトが表示されなくなったり、メールが受信できなくなることがあります。
特にNS（ネームサーバー）やSOAレコードを誤って変更すると、ドメイン全体が無効になりかねません。

トラブルシューティングが困難

DNSの仕組みを理解していないと、問題が発生しても原因を特定できません。
その結果、ウェブサイトが長時間にわたって停止する可能性があります。

セキュリティリスク

不適切なTXTレコードの設定（例えばSPFやDKIM）が原因で、スパムやフィッシングの問題が発生する可能性があります。

パフォーマンスへの悪影響

TTL（Time To Live）の設定を適切にしないと、不要な負荷がサーバーにかかる場合があります。

自分でググって調べて、多少なりとも意味が分かった上で操作するなら、無事に設定できるケースが多いのです。
でもAIの言いなりというのは、何も知らないまま重要な部品を触っていることになります。
独自ドメインはお金がかかっていますし、とてもリスクが高いです。

意図しない変更のリスク

AIが提供するアドバイスが正しくても、初心者がその影響を理解していない場合、無意識のうちに重要な設定を上書きしてしまう可能性があります。

予期せぬサービス停止

NSやAレコードを誤って変更すると、ウェブサイトやメールが使用できなくなることがあります。
このような状況では、元の設定を復元するための知識が必要になります。
バックアップがあればいいのですが、たいてい、やってないことが多いよね…

依存の危険性

AIに頼りすぎると、管理者自身が問題解決のスキルを身に付ける機会を失い、長期的な運用に支障をきたす可能性があります。

独自ドメイン設定に失敗しないために

あまりにも一般的な内容に過ぎますが、次の3つを守っていれば、円滑な独自ドメイン設定が可能となるでしょう。

知識の習得

設定を変更する前に、DNSレコードの種類や役割（Aレコード、CNAME、TXTなど）を理解することが重要です。

バックアップ

設定を触る前に、現在のレコードをバックアップ（コピー）しておくことで、誤って変更した場合にも復旧が可能です。

専門家に相談

自信がない場合は、プロバイダのサポートや専門家に相談するのが最善です。

適切な知識を持ち慎重に扱えば、独自ドメインとDNS設定はウェブ運営に欠かせない、非常に便利なツールなのですよ。
次はDNS設定後の、このサイトの状況のお話です。

独自ドメイン設定が完了した当サイトの状況

私のサイトは現在、次のような独自ドメイン設定となっています。
難しいことはやっていません。
でも、十分な事前準備と移行期間を確保して行いました。

リダイレクト設定に関しては、従来のURLも使えるため利用者には関係ありません。
でもシステム的に可能であれば、やっておくと良いですね。─ 後述します ─

.org ドメインにした理由

Eロン禍でSNS業界が不安定になり、AI学習を嫌って「個人サイト欲しい」と言う人が増えてきました。
特にクリエイター系の人たちはその傾向が強いですね。
そういう個人サイトを作ろうとしている人のために、あの手この手でシステム開発して拡散している人もいます。
そんな中で私は、単純素朴なソースコードを書くタイプの、自由なWebアプリケーションの作り方を書いてます。

いろんな巡り合わせで、リアルSEになったことだし。
プライベートで作りたいものを好きなように作って、それが見知らぬ人の役に立つというだけで、十分過ぎると思いませんか？
自分が勉強してきた技術の活かし方として、これ以上のものはないと思います。
だから .org ドメインなのですよ。

個人でやってる非営利活動だからさ。
サブのサイトでゲームや釣りのことを書いてたっていいじゃん？
お金のために自分がしたいことを犠牲にせずに済む、理想の形なのです。

.orgドメインの一般的な解説

.org ドメインは、その名前が示すとおり「organization」の略で、インターネットの黎明期から存在する歴史あるトップレベルドメインです。
当初は非営利組織や団体向けに設計されていて、営利企業は .com、教育機関は .edu、政府機関は .gov といった具合に使い分けられていました。
しかしインターネットの普及と共に、これらのドメインの登録ポリシーが緩和されてきました。
正式には .orgドメインを登録するための厳格な制限がなかったため、個人や営利企業でも自由に取得できるようになったんです。

このドメインを使用することで、サイト訪問者に対して親近感や信頼感を伝えることができます。
営利目的ではない、純粋な情報提供やコミュニティの価値観といったものの強調と言えば良いでしょうか。
社会的に意義ある情報を発信したい、またはコミュニティとのつながりを深めたいと考えているのであれば、.org ドメインはその思いを表現する手段になるでしょう。

独自ドメインに関連する知識

IT系の中でもネットワークは特に難しく、全てを完璧に網羅するのは難しいです。
ただ、ある程度の基礎くらいは押さえておくと、いざ設定画面がでてきても安心して必要事項を入力できるでしょう。

IPアドレス (Internet Protocol Address)

インターネット上のすべてのデバイスやウェブサイトは一意のIPアドレスを持っています。
これはコンピュータが通信するための「住所」のようなものです。
しかし、IPアドレスは「192.168.1.1」などという数値の羅列なので覚えにくいです。

DNS (Domain Name System)

DNSは「電話帳」のようなもので、人が覚えやすいドメイン名 ─ 例えばexample.com ─ と対応するIPアドレスを変換します。
人はドメイン名を入力してウェブサイトにアクセスしますが、実際にはその背後でDNSがIPアドレスを使って通信を行っています。

このサイトとDNSのケース

特別なことはやっていませんが、実例を見つつお話しすると分かりやすいと思う。

1. ドメイン名登録

このサイトが使っている独自ドメイン feinatelier.org はドメイン登録機関を通じて登録され、PIRがそのドメインを管理します。
ドメイン名を取得する際に、ICANNとJPNICの規定に従い、重複がないように管理されます。

2. DNS（Domain Name System）

ドメイン名は人間が覚えやすい住所ですが、コンピュータはIPアドレスという数字で通信します。
DNSは、ドメイン名とIPアドレスを結び付ける仕組みです。
たとえば、「feinatelier.org」を入力すると、DNSがそのドメインに対応するIPアドレスを見つけて接続します。

3. このサイトの動作

ユーザーがブラウザでこのサイトのドメイン名 feinatelier.org を入力すると、DNSがそのドメイン名をIPアドレスに変換し、そのアドレスに対応するウェブサーバーに接続します。
そして、ユーザーはこのサイトにアクセスできるわけです。

このように、ICANNやJPNIC、PIR、ドメイン登録機関が連携してインターネット上のドメイン名を管理し、DNSがドメイン名とIPアドレスを結び付けることで、スムーズなウェブアクセスが実現しています。

DNSサーバーとネームサーバー

DNSサーバーとネームサーバーは関連していますが、厳密には違う概念です。
実際のDNSレコードを見る前に、ここで改めて整理しておきましょう。

DNSサーバー

役割

DNSサーバーは、インターネット上のドメイン名（このサイトなら feinatelier.org）をIPアドレス（例えば: 192.0.2.1）に変換するシステムを管理・提供するサーバーです。

用途

ドメイン名を入力したときに、その名前がどのサーバーに対応するかを解決する仕組みです。たとえば、ウェブサイトの閲覧やメールの送受信で使われます。

例

キャッシュDNSサーバー（プロバイダー提供のものなど）は、ユーザーがアクセスするリクエストを一時保存し、アクセスを高速化します。

ネームサーバー

役割

ネームサーバーは、特定のドメインに関するDNS情報を保持しているサーバーです。
たとえば、feinatelier.org にどんなDNSレコード（A、MX、CNAMEなど）が設定されているかを指し示します。

用途

「このドメインの詳細なDNS情報はどこにありますか？」と尋ねられたときに、その場所を教える役割を果たします。

例

ns1.dns.ne.jpやns2.dns.ne.jpのようなものです。

つまり、ネームサーバーは、特定のドメインについての情報源を指す役割を持っており、DNSサーバーはその情報をもとに問い合わせを処理するものと言えます。

自分のサイトの所有権

ドメインの所有権を証明するためには、特定の方法でドメインを確認する必要があります。

DNSレコードの設定

ドメインのDNS設定に特定のTXTレコードを追加する。

ファイルアップロード

指定されたファイルをドメインのウェブサーバーにアップロードする。

メール認証

ドメインに関連付けられたメールアドレスに送られる確認リンクをクリックする。

このようにして、独自ドメインの設定が正しく行われ、ドメインの所有権が証明されます。

ドメインレジストラもしくはドメイン登録機関

ICANN（アイキャン）

ICANN（Internet Corporation for Assigned Names and Numbers）は、インターネットのドメイン名やIPアドレスの管理を担当する国際的な組織です。
世界中のドメイン名やIPアドレスが重複しないように調整しています。

JPNIC（ジェーピーニック）

JPNIC（日本ネットワークインフォメーションセンター）は、日本におけるインターネットのドメイン名やIPアドレスの管理を行う組織です。
ICANNと連携して、日本国内のインターネット資源の調整や管理をしています。

簡単にまとめると、次のようになります。

ICANN

世界中のインターネット資源の調整・管理を行います。

JPNIC

日本国内でICANNと連携してドメイン名やIPアドレスの管理を行います。

ドメイン登録機関

ユーザーにドメイン名を提供し、PIRなどの管理組織に登録する役割を果たします。

このように、ICANNを頂点とした多層的な仕組みがインターネット上のドメイン名の一貫性と管理を保っています。
次は、特に.orgドメインを管理している非営利組織であるPublic Interest Registry（PIR）を見ていきます。
このサイトが.orgドメインだからね。

Public Interest Registry (PIR)

次のようなサイトも参考になります。
ドメインはいっぱい種類があるのですよ。

• Public Interest Registry
• About the Public Interest Registry (PIR)
• Root Zone Database

ドメイン名の構成

例えば、このサイトの feinatelier.org があります。
このドメインは次のような構成となっています。

このドメインに関する理解は、とても重要です。
一方、サブドメインはセカンドレベルドメインのさらに左に位置する部分で、ルートドメインの特定の部分を指します。
例えば www、mail、blog などがよく見るサブドメインです。
ここに「portal.feinatelier.org」というURLがあります。
私のポータルサイトのURLです。
このURLは次のような構成となっています。

サブドメインは下記のような用途で使われることが多いですね。
ちなみに当サイトは支部なんて持っておりません😆ww

異なるサービスの運用

サブドメインを使って、異なるサービスを運用することができます。
例えば、blog.feinatelier.orgはブログサービス、mail.feinatelier.orgはメールサービス、shop.feinatelier.orgはオンラインショップを示します。

異なる部門や地域の管理

大企業や組織では、サブドメインを使って異なる部門や地域を管理することができます。
例えば、us.feinatelier.orgはアメリカ支部、jp.feinatelier.orgは日本支部を示します。

テスト環境の作成

サブドメインを使って、テスト環境や開発環境を作成することができます。
例えば、test.feinatelier.orgやdev.feinatelier.orgはテスト環境や開発環境を示します。

このように、サブドメインは特定のサービスや部門を示すために使用され、ドメイン名全体の管理を柔軟に行うことができます。

ルートドメイン / サブドメインのDNS設定

ここでは、ルートドメインとサブドメインに関するDNSレコードの一般的な設定方法について説明します。
ルートドメインは通常TXTレコードが使用され、ドメインの所有権確認やメールのセキュリティに役立ちます。
一方、サブドメインは通常CNAMEレコードが使用され、別名として他のドメイン名を指すことができます。
これが、ルートドメインとサブドメインのDNSレコードの違いです。

1. ルートドメイン（example.com）

ルートドメインに対してよく使用されるDNSレコードの種類の一つがTXTレコードです。
TXTレコードは、ドメイン所有権の確認やメール送信のセキュリティ（SPFレコードなど）のために使われます。
たとえば、Google Search ConsoleやOffice 365のドメイン所有権確認ではTXTレコードの追加が求められることがあります。

TXTレコードの設定手順

1. ドメイン管理画面にログインします。
2. DNS設定やDNS管理の項目を見つけます。
3. 「TXTレコードの追加」または「新しいレコードの追加」を選びます。
4. ドメイン名を指定し、提供された値を入力します。
5. 設定を保存します。

2. サブドメイン（sub.example.com）

サブドメインに対してよく使用されるDNSレコードの一つがCNAMEレコードです。
CNAMEレコードは、あるドメイン名が他のドメイン名に別名として設定されていることを示します。
たとえば、www.example.com が example.com にCNAMEとして設定されることがあります。

CNAMEレコードの設定手順

1. ドメイン管理画面にログインします。
2. DNS設定やDNS管理の項目を見つけます。
3. 「CNAMEレコードの追加」または「新しいレコードの追加」を選びます。
4. サブドメイン名 sub を指定し、ターゲットドメイン名 example.com を入力します。
5. 設定を保存します。

ここからは当サイトでの設定事例です

実際の設定を見ながら、DNS設定に必要な事柄を見ていきます。

Google App Engineでカスタムドメインを設定する

画面の指示に従っていれば大丈夫です。
Google Search Consoleの設定もお忘れなく。
wwwとサブドメインについては、プロパティの追加から所有権の確認をしないと、DNSが無効のままです。

Google Search Consoleによる所有権証明

私はGoogle App Engine と Google Sites を使っているのですが、少し紛らわしい箇所があります。
Google Search Console の扱い方が少し違っていて、特に独自ドメイン設定で経路が違うんだよね。
では、この2つのクラウドサービスと所有権の証明方法について説明します。

Google Search Consoleは、ウェブマスターが自分のウェブサイトのパフォーマンスを監視し、最適化するためのツールです。
所有権を証明する方法として、次のような方法があります。

• HTMLファイルのアップロード
• HTMLタグの追加
• DNSレコード（TXTレコード）の設定

Google Search Consoleを使用する理由は、検索エンジンに対する所有権の証明とサイトの管理を一元化するためです。
このツールによって、Google検索結果におけるサイトのパフォーマンスやインデックス状況を詳しく把握でき、SEOの最適化が容易になります。

1. Google App Engineによる静的ウェブサイト

Google App Engineは、Google Cloud Platformの一部で、アプリケーションやウェブサイトをホストするためのサービスです。
Google Cloud Consoleを使用して管理し、ウェブサイトの設定やデプロイを行います。
Google Cloud Consoleでは、すでにウェブサイトがGoogleアカウントに紐づけられているため、追加の所有権の証明は必要ありません。
ただし、サブドメインの www については、改めてSearch Consoleで所有権を確認するプロセスを挟む必要があります。

2. Google Sitesによる静的ウェブサイト

Google Sitesは、ユーザーが簡単にウェブサイトを作成できるツールです。
Google Sites自体は所有権の証明を要求しませんが、サイトがインデックスされるためにはGoogle Search Consoleに登録する必要があります。
Google Search Consoleを使用することで、サイトの所有権を証明し、サイトのパフォーマンスや検索エンジンの最適化の状況等を管理できます。

さくらのドメインコントロールパネル

メインコントロールパネル登録情報

ここは分かりやすいでしょうね。
サービスコードはドメインや契約に紐づいた固有の識別子です。
問い合わせやサポート時に特定の契約情報を確認するために使われるため、あるいはノートなどに書いておくと良いかも。
レジストラは上述したように、ドメイン名を登録・管理する企業や組織のことです。
JPRS（日本レジストリサービス）は日本のドメイン名の管理を担っている主要な機関となっています。
ドメイン名の登録情報や利用ルールを統括している組織です。

ゾーン情報のレコード設定

エントリ名: @、タイプ: NS

この設定は、ドメインの名前解決（DNS）に関するものです。
NS（Name Server）レコードは、ドメイン名に関連付けられたネームサーバーを指定するためのDNSレコードです。
ネームサーバーは、インターネット上で「このドメインの情報はどこにあるか」を教える役割を果たします。
しかし、ここでns1とns2があります。
なぜ2つあるのでしょうか。

さくらインターネットのようなドメイン管理サービスでは、ドメインを購入した際に、デフォルトでそのサービスのネームサーバーが設定されます。
ユーザーが特に設定を変更しなくても、基本的なDNS機能が利用できるようになっているわけです。
通常、特別な理由がない限り、この設定を変更する必要はありません。
ただし、独自のネームサーバーを使用したい場合や、特定のDNSプロバイダーを利用したい場合には、これらのNSレコードを変更することがあります。

エントリ名: @、タイプ: TXT

これはドメインの所有権を確認するための、Googleのサイト確認レコードです。
TXT（Text）レコードは、ドメインに関する補足情報を記述するためのDNSレコードです。
主に認証や確認目的で使われます。
特定のサービス、このWebサイトの場合はGoogleに対して、ドメインが私の管理下にあることを証明するために設定されます。

ここの意味がちょっと分かりにくいのですよ。
いろんなWebサービスを経由するからね。
Googleサービスを利用する際に、ドメイン所有者であることを証明することが求められるのです。
このTXTレコードを登録することで、Googleがこのドメインが私のものであることを、確認できるということです。

複数のTXTレコードを設定するケース

DNSレコードには複数の TXT（テキスト）レコードを設定することが可能です。
ドメインの所有者は、一つのドメインに対して複数の TXT レコードを追加して、異なる用途に利用できます。
このTXTレコードが含む情報として、次のようなケースが考えられるでしょう。

エントリ名: @、タイプ: AとAAAA

「A」や「AAAA」といった名前は、DNS（ドメインネームシステム）の設計時に、それぞれのレコードタイプが果たす役割をシンプルに表現するための命名規則として採用されました。
「A」は、Address（アドレス）を意味します。
ドメイン名に関連付けられたIPv4アドレスを解決するための、最も基本的なDNSレコードとして設計されたためです。
初期のDNS設計時に、もっとも重要な役割である「アドレス解決」を担当するレコードとして「A」という簡単な文字が割り当てられました。
「AAAA」は、IPv6アドレスを表します。
IPv6アドレスは、IPv4に比べて長いアドレス形式（128ビット）を使用するため、「4倍のA（Address）」という意味で「AAAA」と名付けられています。

私の場合、Aレコードが4つあり、IPアドレスが4つ入力されます。
Google App Engineにデプロイされた静的ウェブサイトでIPアドレスが複数ある理由は、スケーラブルで信頼性の高いウェブサイトホスティングを実現するためです。
次のような特徴があるんですよね。

IPv6の場合、アドレス空間が非常に広大なので、複数のアドレスを用いてこれらの効果を強化しつつ、より最新のインフラストラクチャとネットワーク設計に対応しているという特徴もあります。
IPv4とIPv6が両方同時に使われているのも、デバイスやネットワークによってIPv4しか使えない場合があるため、互換性を維持するためですね。

エントリ名: www、タイプ: CNAME

こういうところ、重要なポイントです。
このCNAMEレコード（www → ghs.googlehosted.com.）は、www.feinatelier.orgがfeinatelier.orgとは別のサブドメインとして扱われ、Google App Engineのホスティングに対応させるための設定です。

CNAME（Canonical Name）レコードは、あるドメイン名を別のドメイン名に紐づけるDNSレコードです。
www.feinatelier.orgは、ghs.googlehosted.com.（Googleのホスティングサービス、ここではapp engine）にマッピングされています。
この設定により、www.feinatelier.orgにアクセスしたユーザーは、自動的にGoogleの指定されたホスティングサービスにリダイレクトされます。

ここで、すでにfeinatelier.orgがあるのに、なぜwww.feinatelier.orgが必要なのか、考えていきます。

このように、Google App Engineや他のホスティングサービスは、ルートドメイン（feinatelier.org）とwwwサブドメインを個別に設定することが一般的です。
各サブドメインを独自に扱うことで、DNSエラーやリダイレクトの問題を防げます。
feinatelier.orgだけでなく、www.feinatelier.orgもホスティングに結びつけることで、ユーザーのアクセスパターン全般をカバーできるということです。

エントリ名: portal、タイプ: CNAME

ここは2カ所をまとめて書いていきます。
2つともfein's portalに関する設定です。

エントリ名: example123、タイプ: CNAME

それぞれの CNAME レコードは、別々の目的のために設定されています。
2つとも正しく設定しないとfein's portalへサブドメインを設定できません。

1. エントリ名: portal の CNAME レコード

このレコードは、portal.feinatelier.org にアクセスするユーザーのリクエストを、Google Sites のホスティングサーバーである ghs.googlehosted.com. に正しく振り分けるためのものです。
つまり、実際にウェブサイトを表示するための「道しるべ」として機能します。

2. エントリ名: example123 の CNAME レコード

このレコードは、Googleサーチコンソールなどの Google のサービスが、設定したサブドメインに対して所有権の確認や設定情報の検証を行うために発行したものです。
これがないと、Google Sites側でDNSに関する何かしらエラーが発生するはずです。
だってportal.feinatelier.org というサブドメインに対して所有権の確認が取れないから。
ゆえに追加の検証用情報として example-placeholder.googlehosted.com を示すレコードを入れることで、正しい設定と所有権を確認し、最終的に portal.feinatelier.org が問題なく表示されるというわけですね。

portal のレコードは、実際のサイトへのアクセスを Google のホスティングサービスに結びつけるためにあるんですよ。
一方、example123 のレコードは、Googleの検証プロセスの一環として追加されたものであり、サイト設定や所有権の確認が正しく行われるために必要な情報なのです。
同じサブドメインに対して複数の CNAME レコードが存在するように見えますが、実際はそれぞれ全く異なる役割を担っているというわけです。

エントリ名: _atproto、タイプ: TXT

Bluesky側の設定については How to verify your Bluesky account にあります。

このDNSレコードは、BlueskyがカスタムドメインとBlueskyアカウントを連携させるために用いる認証情報です。
_atproto は、Bluesky（ATプロトコル）の仕様で定められた特定の名前空間です。
Blueskyは、この名前（ホスト名）のTXTレコードを探して、ドメインの認証や紐付けを行います。
TXTレコードは、任意のテキスト情報をDNSに登録でき、所有権の確認や認証情報の提供によく使われます。これは上述しましたね。
did から始まる文字列に記載されている情報は、ドメインがBluesky側で発行された分散型識別子（DID: Decentralized Identifier）と連携していることを示しています。
つまり、Blueskyアカウントに対応する識別子です。

BlueskyはこのTXTレコードをチェックすることで、「_atproto.feinatelier.org」というサブドメインに対して、正しいDID（分散型識別子）が設定されているかを確認し、私のドメインが所有され、Bluesky用の設定が完了していると認証します。
このようにして、Bluesky側のシステムは私のドメインを正しく認識・連携することができるようになります。

SOAレコード

次はここの説明ですね。
SOA（Start of Authority）レコードは、DNSゾーンファイルに含まれる重要な情報のひとつで、DNSゾーンの管理に関するデータを提供します。
DNSゾーンの同期や信頼性、効率性を保つために重要な設定を含んでいるので、通常はプロバイダやゾーン管理者が調整します。

セカンダリDNSサーバーとプライマリDNSサーバー

上述している「セカンダリDNSサーバーとプライマリDNSサーバー」について、見ていきます。
これらは、DNS（Domain Name System）における役割を持った2種類のサーバーで、ゾーンデータの管理と提供に関与しています。

これらのネームサーバーは、ドメインに対する名前解決を提供するサーバーとして、外部からのクエリに対応します。
例えば、ドメイン名をIPアドレスに変換するといったお仕事ですよ。
こうすることで、システムの信頼性や可用性を向上させています。

ここらへんは深みにハマるとキリがないのですが、もうちょっと詳しく見ておく必要があります。
ぼんやりとでも良いから意味が分かっていないと、トラブル発生時に対処できなくなることはもちろん、そもそも設定時にヒントを探すべくググることさえ難しいケースが出てくるんだよね。

プライマリDNSサーバー (Primary DNS Server)

ゾーンデータの「元データ」を管理する主要なサーバーです。
このサーバー上でゾーン情報（Aレコード、CNAMEレコード、NSレコードなど）を作成・編集します。
ゾーンファイルを直接編集できるのはプライマリDNSサーバーのみ。
言い変えると、サイト管理者がDNS設定をしているのは、このプライマリDNSサーバーを触っているということです。
このサーバーはSOA（Start of Authority）レコードを含む全てのゾーンデータを保持します。
データが更新されると、セカンダリDNSサーバーに通知し、データの同期を行います。

セカンダリDNSサーバー (Secondary DNS Server)

プライマリDNSサーバーからコピーされたゾーンデータを保持し、クライアント（例えばWebブラウザや他のサーバー）のクエリに応答します。
ゾーンデータの編集はできず、プライマリDNSサーバーからデータを取得して保持します。
プライマリDNSがダウンしても、セカンダリDNSが引き続き名前解決を提供するため、可用性と信頼性を向上させます。
「更新間隔（Refresh）」の設定に従い、プライマリDNSから最新のゾーンデータを取得します。

ドメインとレコードタイプの対応関係

私の独自ドメイン運用のように、ルートドメインとサブドメインを使い分けるような設定にしている場合、それらの対応関係を把握しておく必要があります。
いろんな事例があるけども、私の運用はわりと単純な部類かと思います。
ここまでの説明文と多少重複する場面もありますが、リダイレクトのソースコードを見る前に、復習ついでに見ておいて頂けると良いかと思います。

メインサイトとBlueskyの関係

DNSの仕組みでは、同じドメイン名に対して複数のレコードタイプ（A、AAAA、NS、TXT、CNAMEなど）を独立して設定できるため、一見するとルートドメインが2カ所に設定されているように見えても、それぞれは全く別の役割を持っているのです。
例えば私の場合、https://feinatelier.org/ と https://bsky.app/profile/feinatelier.org で、ルートドメインを2つ使っているわけではありません。
https://feinatelier.org/ はルートドメイン（トップレベルのドメイン）ですが、https://bsky.app/profile/feinatelier.org はサブドメインではなく、別のドメイン（bsky.app）の特定のページになります。

ルートドメイン

feinatelier.org のように、ドメインの基本部分（親）を指します。この場合、 https://feinatelier.org/ はそのドメインのルート（トップ）です。

サブドメイン

www.feinatelier.org や blog.feinatelier.org のように、ルートドメインの前に名前（www や blog）を付けることで、同じドメイン内の異なる部分を示します。

一方で、 bsky.app は完全に別のドメインです。
URL https://bsky.app/profile/feinatelier.org に含まれている feinatelier.org は、あくまで bsky.app 上のプロファイルページの一部として使われているだけです。
つまり、feinatelier.org はこのURLの中でサブドメインの一部ではありません。

つまり、さくらのDNSゾーン設定で「_atproto」TXTレコードを追加しても、これは「_atproto.feinatelier.org」というサブドメイン用の設定であって、メインの「feinatelier.org」には設定されているAやAAAAレコードなどと全く別物です。
そのため、ホームページ（feinatelier.org）の動作に影響は出ず、Bluesky用の認証などでのみ使われるという仕組みになっています。

メインサイトとポータルサイトの関係

次に、App Engineのサイトで「feinatelier.org」を設定していると、 Google Sitesのサイトでは「feinatelier.org」を設定できないのはなぜでしょうか。

一つのルートドメイン（この場合「feinatelier.org」）は、DNS設定上、基本的にひとつのサービスにしかマッピングできません。
たとえば、App Engine側で「feinatelier.org」を使うように設定している場合、そのドメインはApp Engineのサーバーを指すことになります。
そのため、同じルートドメインをGoogle Sites側でカスタムドメインとして設定することはできず、重複して使用することはできません。

「メインサイト + ポータルサイト」の場合

もし feiinatelier.org を A レコードや CNAME を使って別のウェブサイト（App Engine のサイト）に割り当てている状態で、さらに Google Sites のサイトに同じドメインを割り当てようとすると、DNS がどちらにトラフィックを送ればよいかわからなくなってしまいます。
DNSでは1つのドメイン名に対して複数のウェブ向けレコードが併存することはできないため、結果的にどちらか一方にしかマッピングできません。
同じドメインを2つ以上のウェブサービス（DNSの A/CNAME レコードで方向付けされるサービス）に割り当てることはできないんだよね。
どちらにするかを選ぶ必要があります。

「メインサイト + bluesky」の場合

Bluesky の設定で利用されるのは、主に TXT レコードなど追加の検証情報であって、ウェブトラフィック（HTTP/HTTPS の接続）の向き先には直接影響しません。
つまり、feinatelier.org は A や CNAME レコードによって App Engine のサイトに向けられており、その一方で、Bluesky 用の認証・検証情報を TXT レコード（または特定のサブドメインの TXT レコード）として設定しているため、両方を同時に使うことができるのです。
ウェブサイト用の A/CNAME レコードはそのまま使用しつつ、TXT レコードなどでBlueskyの検証用の情報を追加することになるので、両者は役割が異なり、干渉しません。

Google SitesとBlueskyの共通点

Bluesky の場合、通常のウェブサイトのようにそのドメイン上で直接コンテンツをホスティングするわけではないため、A レコードなどのIPアドレスへのマッピングが必要ない仕組みになっています。
分散型プロトコルでもサーバーは必要ですよ？
でも、Twitterの中央集権型のようにすべてを1カ所で管理するわけではなく、複数の場所に分散して動いています。
各ユーザーが自分のサーバーを持つ自由度が高く、サービス提供者に依存しない形でデータを保持できます。

Bluesky では、アカウントがドメインの所有権を証明するための TXT レコードだけがあれば、そのドメイン（やサブドメイン）をサービスに関連付けることができ、従来のウェブサイトのように DNS によるホスティングの設定（A/CNAME レコードなど）を変更する必要がない、という仕組みになっています。

これが、Bluesky で A レコードなどを設定せずに、TXT レコードだけでカスタムドメインの認証や紐付けが可能な理由です。
Google Sitesも、基本的な考え方は似ています。

Google SitesのようなSaaSプラットフォームでは、サービス提供側がバックエンドのインフラを管理しているため、ユーザー側が直接サーバーのIPアドレス（つまりAレコード）を指定する必要はありません。
そのため、CNAMEレコードを使って自分のサブドメインをサービス側のドメインにエイリアスする形で設定できます。
たとえば、次の設定を改めて見ておきます。

これは、portal.feinatelier.org へのアクセスを ghs.googlehosted.com に転送する、という仕組みです。
GHS（Google Host Hosted Service）側でIPアドレスの管理がされるので、利用者は単にCNAMEで仕向ければ済むのです。

Blueskyも同様に、ドメインの所有権確認やサービス連携はTXTレコードなどで行われ、ウェブトラフィック自体は中心となるBlueskyのサービス側で処理される仕組みになっています。
つまり、直接Aレコードでそのドメインをポイントする必要がないため、同じように簡易な設定で済んでいると言えます。

両者とも、サービス提供側でインフラ管理がなされているため、ユーザー側はカスタムドメイン設定においてAレコードを直接書く必要がなく、CNAME（もしくはTXT認証）を利用してドメインをサービスに紐付けられる仕組みになっています。
そのため、Google Sitesでサブドメインを設定する場合も、Blueskyの場合も、本質的には「サービス側に任せる」という方法で動いているので、利用者にとっては設定がシンプルになるという点で同じ考え方なのです。

メインサイトだけでAレコードが必要

これは、DNSの仕様とサービス毎のカスタムドメインの設定方法の違いにあります。

1. DNS仕様の制約

ルートドメイン（@）にはCNAMEを使えない

DNSの仕様上、ルートドメイン（たとえば「feinatelier.org」そのもの）に対してはCNAMEレコードを設定できません。
そのため、ルートドメインにアクセスさせたい場合、Aレコード（IPv4）やAAAAレコード（IPv6）を使って、どのIPアドレスに向けるかを明示的に指示する必要があります。

2. App Engineのカスタムドメイン設定の要件

所有権の検証

TXTレコード（例："google-site-verification=example1234567890"）は、Googleがサイト作成者のドメインの所有権を確認するために必要です。

ルートドメインのマッピング

App Engine（あるいは一般的なGoogle Cloudのサービス）で静的なウェブサイトをホスティングする場合、ルートドメインでのアクセスを適切に処理するために、Google側から提供された特定のIPアドレスにルートドメインを向けなければなりません。
このため、ルートドメイン「@」には、Aレコード（例：123.123.123.123）とAAAAレコード（例：2001:db8::1234）を設定する必要があるのです。

3. サブドメインとCNAMEの違い

サブドメイン（wwwなど）はCNAMEでOK

サブドメインについては、CNAMEレコードを使って、たとえば「www」のアクセスを ghs.googlehosted.com. にエイリアスするように設定できます。
これは、Google Sitesや一部SaaSプラットフォームが内部でそのCNAMEを見てサービスに振り分ける仕組みになっているため、柔軟に利用できます。

Google SitesやBlueskyの場合、サービス提供側がそのサブドメインの背後にあるインフラのIPアドレス管理を完璧に行っているため、ユーザー側は単にサービスにエイリアスさせるためのCNAMEやTXTレコードだけで済むのです。
つまり、内部でGoogle（またはBluesky）が適切にリクエストをルーティングしているため、Aレコードで直接IPアドレスを指定する必要がないということです。

これが、App Engineにデプロイされた静的ウェブサイトだけでA/AAAAレコードを書く理由です。
DNSの仕様やサービスがどのようにドメインを管理するかという点で、各サービスの仕組みが違うため、設定方法も異なるのです。

リダイレクト機能を追加する

独自ドメインを設定したら、次はリダイレクトの機能も実装したほうが良いです。
しかし、このページに書くにはあまりにも長文になる上に、サーバーサイドスクリプトです。
よって、「独自ドメイン設定後にリダイレクト機能を追加する」にジャンプしてください。
そこにApp Engineをデプロイ先としたリダイレクト機能の追加方法とソースコードを書いてあります。

個人サイトはスタート前の計画が大切

Eロン禍で「時代は個人サイト」という言葉を頻繁に耳にするようになりました。
自分でサイトを作ろうとしたとき、おおよそ次のように話題が移るものです。

1. どのサービスがいいか？
2. 自分で作れないか？
3. でもコーディングとプログラミングが…

更新の継続

そもそも計画段階からプロジェクト構成と話題選びがマズいと、後から変更するのが非常に難しいケースが多いです。
でも構成と話題が適切かどうかなんて、経験を積まないと分からないんだよ…

独自ドメイン設定

初めから独自ドメインにしてスタートの場合、更新が継続できないと、いろいろもったいないことになります。
欲が出てきて後から独自ドメインにする場合、想像以上に難航する可能性があります。

このサイトの場合、もう初めっから全て計画済みで、たっぷりと時間を取りながら、段階的に一手ずつ進めていったのです。
.orgドメイン取得のタイミングなどなど、サイト構築前から全て決まっていました。

個人サイトはスタート前の計画がとっても大切だと私は思います。
ベストプラクティスであろう計画を立ててからスタートすれば、こんなにおもしろくてお金がかからない遊びも珍しいと思いますよ？

---

サイトマップ

全ページをリスト化したサイトマップも用意していますが、けっこうなページ数があります。
下記の「カテゴリー分けサイトマップ」のほうが使いやすいでしょう。

アナザーエデン関連ページ・サイトマップ

アナザーエデンの強敵戦やストーリーコンテンツのリスト、お勧めバッジなどを掲載したコーナーです。
期間限定のない普通のRPGですので、初心者でも安心して続けていけるゲームとなっています。
もっとも重要なグラスタについては、場所別に網羅した表があります。

個人サイトのホスティングとコンテンツ作成

個人でウェブサイトを作るにはどうすればいいか。
HTML・CSS・JavaScriptの書き方はもちろん、無料かつ広告なしでホームページを作る方法を掲載したコーナーです。
Webデザインやレイアウトについても書いてあります。

魚釣りなどアウトドアのエリア

ゲームとパソコンだけじゃなく、アウトドアも趣味なんです。
このコーナーでは魚釣りの記録とか、魚料理のレシピ、はたまたサイクリングなどなど。
アウトドアに関連するコンテンツが詰め込まれています。

ページ上部へ戻る