カスタムドメインとTLSを5分でセットアップする方法（Elidoを使用）

HTTPSを使ったカスタムドメインのセットアップには、2つのDNSレコードと伝播待ちの約3分が必要です。残りの時間は通常、レコードの意味、なぜ両方が必要なのか、そして追加後に何が起きるかを理解することに費やされます。この記事は実践的なバージョンです：5つの具体的なステップ、正確なAPIコール、そして何か問題が起きたときに何をすべきかわかるよう証明書の仕組みの説明も含みます。

ショートリンクに対してTLSが特に重要な理由#

HTTPSなしのショートリンクは、HTTPSなしの通常のURLよりも深刻な問題をもたらします。

リダイレクトレスポンス - Locationヘッダーを持つ301または302 - がペイロード全体です。最初のHTTPリクエストがプレーンHTTPで送信される場合、ネットワークパス上の誰でもクライアントがそれを辿る前に遷移先URLを読むことができます。つまり、キャンペーンの遷移先、アフィリエイトURL、または内部ツールのリンクが最初のホップで任意のネットワーク観察者に見えてしまうということです。現代のブラウザは、このような露出パターンのために、HTTPのショートリンクにセキュリティ警告を表示し始めています。

QRコードはこの問題を複雑にします。物理的なスペースでコードをスキャンする人は、そのURLと事前の関係がありません - コードが唯一の信頼シグナルです。最初のロードでのブラウザ警告は最悪の摩擦ポイントです：印刷、イベント配置、または屋外メディアにすでにコストをかけており、スキャン時のセキュリティ警告は好奇心のある人を最も遠ざける可能性が高いものです。自社ドメインの有効なTLS証明書は、QRベースのキャンペーンにとって最も安価な信頼シグナルです。

s.elido.meやb.elido.meでは、TLS証明書はElidoに属しています。南京錠は本物ですが、ドメインはあなたのものではありません。つまり、ブランドの信頼はあなたではなくプラットフォームに積み上げられます。go.acme.comのカスタムドメインは証明書にあなたの名前を入れます。

DNSとTLSの基礎については、コーナーストーン記事カスタムドメインショートリンク：DNS、TLS、エッジで動くもので詳しく説明しています。

ステップ1：ホスト名を選ぶ#

最も一般的な選択は、プライマリドメインの短いサブドメインです：go.example.com、links.example.com、またはs.example.com。短い方が良いです - サブドメインのプレフィックスは送信するすべてのリンクに表示されます。

決定前に知っておくべき2つの制約：

DNSプロバイダーがALIASレコードをサポートしない限り、サブドメインのみ。 RFC 1034 §3.6.2は、ゾーンアペックス（example.com）でのCNAMEレコードを禁止しています。ベアアペックスをリダイレクトしたい場合、DNSプロバイダーはALIASまたはANAMEレコードをサポートする必要があります（Route 53 ALIAS、CloudflareのCNAMEフラット化、DNSimple ALIAS）。これらは公開前にルックアップをフラット化する非標準の拡張です。プロバイダーのドキュメントを確認してください。機能名は異なり、すべてのプロバイダーが提供しているわけではありません。

他のものに使用していないサブドメインを選ぶ。 Elido経由でリダイレクトされるlinks.example.comは、Webサーバーを指すAレコードや既存のCNAMEを持っていてはいけません。同じ名前のDNSレコードは一貫している必要があります。

ほとんどのチームにとって：go.example.comまたはlinks.example.comで十分です。決めたらメモを取り、ステップ2に進みます。

ステップ2：Elidoにドメインを登録する#

ダッシュボードで設定 → カスタムドメイン → ドメインを追加を開き、ホスト名を入力して追加をクリックします。レスポンスには2つのDNSレコード値があります：検証トークンとCNAMEターゲット。両方をステップ3で使用します。

これをスクリプト化している場合 - 新しいクライアントワークスペースのオンボーディング、デプロイパイプラインの一部として実行、またはTerraformプロバイダーで管理 - APIコールは：

curl -X POST https://api.elido.app/v1/workspaces/{workspace_id}/domains \
  -H "Authorization: Bearer $ELIDO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "hostname": "go.example.com",
    "is_wildcard": false
  }'

レスポンスボディにはverification_token（ランダムな16進文字列）と正確なDNSレコード値を含むinstructionsが含まれます：

{
  "domain": {
    "id": 42,
    "hostname": "go.example.com",
    "status": "pending_verification"
  },
  "instructions": {
    "txt_record": "_elido-verify.go.example.com TXT \"verify=<token>\"",
    "cname_record": "go.example.com CNAME edge.elido.me"
  }
}

カスタムドメインは有料プランで利用可能です。Businessプランがカスタムドメインのエントリーポイントです。1つの組織で複数のクライアントドメインを管理するエージェンシーは、エージェンシーソリューションページのワークスペースモデルを確認してください。

ステップ3：2つのDNSレコードを追加する#

DNSプロバイダーのコントロールパネルに移動し、instructionsオブジェクトの両方のレコードを追加します。両方必要です - CNAMEはトラフィックをElidoのエッジにルーティングします。TXTレコードはElidoがサービスを提供することに同意する前にドメインの所有権を証明します。

通常のサブドメインの場合：

go.example.com              CNAME  edge.elido.me.
_elido-verify.go.example.com  TXT    "verify=<your-token>"

ワイルドカードドメインの場合（Businessプラン、*.go.example.comをカバー）：

*.go.example.com            CNAME  edge.elido.me.
_elido-verify.go.example.com  TXT    "verify=<your-token>"

_elido-verifyプレフィックスは標準的なDNSチャレンジ規約です - 検証されるホスト名のサブドメインに所有権の証明を置くことで、TXTレコードがCNAMEと衝突しないようになっています。

いくつかのプロバイダー固有の注意事項：

Cloudflare： 両方のレコードを追加します。CNAMEのプロキシトグルをオフ（グレーのクラウド、DNSのみ）のままにしておきます。CloudflareのHTTPプロキシはリクエストがElidoのエッジに到達する前に元のホスト名を書き換えてしまい、CaddyAskの認可チェックが失敗します。DNSのみモードはリクエストを修正せずに通過させます。
AWS Route 53： アペックスが必要な場合はALIASレコードを使用します。サブドメインには通常のCNAMEが正しいです。Route 53はゾーンアペックスでCNAMEをサポートしていませんが、外部ターゲットへのALIASはサポートしています。
GoDaddy / Namecheap / ほとんどのレジストラDNS： 標準的なCNAMEとTXT - 特別な設定は不要です。

プロバイダーが許可する場合、両方のレコードのTTLを300秒（5分）に設定します。多くのマネージドゾーンのデフォルトTTLは3600秒です。短いTTLは伝播確認が速くなり、後でレコードを変更する必要がある場合の回復も速くなります。

CNAMEレコードはgo.example.comをedge.elido.meに向けてトラフィックをルーティングし、_elido-verifyのTXTレコードはdomain-managerがドメインを検証済みとしてマークする前にゾーンの所有権を証明します。

ステップ4：検証を待つ#

レコードが設置されると、domain-managerはGoogleの公開リゾルバー（8.8.8.8）を使って短い間隔で自動的にポーリングします。「今すぐ確認」をクリックする必要はありません。

サービスはドメインをアクティブとしてマークする前に2つの条件を確認します：

_elido-verify.go.example.comが値verify=<token>のTXTレコードを返す - これによりDNSゾーンを管理していることが確認されます。
go.example.comがCNAME経由でedge.elido.meに解決される - これによりトラフィックがElidoのエッジに到達することが確認されます。

両方のチェックが通ると、statusがpending_verificationからverifiedに移行します。自分でポーリングすることもできます：

curl https://api.elido.app/v1/workspaces/{workspace_id}/domains/42 \
  -H "Authorization: Bearer $ELIDO_API_TOKEN"

statusフィールドを確認してください。300秒のTTLで設定されたレコードの典型的な伝播時間は5分未満です。デフォルトの3600秒のTTLのレコードは、リゾルバーがキャッシュに積極的な地域では最大1時間かかることがあります。

検証が止まっている場合、レコードが正しく公開されているか確認してください：

dig TXT _elido-verify.go.example.com +short
dig CNAME go.example.com +short

TXTルックアップは"verify=<your-token>"を返すはずです。CNAMEルックアップはedge.elido.me.（末尾のドットは正常です）を返すはずです。

ステップ5：最初のリクエストで証明書が自動的に発行される#

domain-managerがドメインを検証済みとしてマークしてCaddyに登録すると、あなた側での作業は完了です。TLSはそれ以上のアクションなしに機能します。

メカニズムはCaddyのオンデマンドTLS（ADR-0012）です：検証済みのすべてのドメインに対して証明書を事前発行するのではなく、Caddyは新しいホスト名への最初のTLSハンドシェイクで証明書を発行します。ACME発行を試みる前に、Caddyはdomain-managerのCaddyAskエンドポイントを呼び出します - プレーンHTTPのGET ?domain=go.example.comです。domain-managerが200を返す（ドメインが検証済みまたはアクティブ状態にある）と、Caddyは進みます。404を返すと、TLSハンドシェイクは失敗し、証明書は一切リクエストされません。このゲートは認識されていないホスト名に対する証明書の誤発行に対する最後の防衛線です。

Caddyが進む場合、ACMEフロー（RFC 8555）はHTTP-01チャレンジを実行します：

CaddyはLet's Encryptに新しい注文をリクエストします。
Let's Encryptはチャレンジトークンで応答します：http://go.example.com/.well-known/acme-challenge/<token>に配置するよう指示されます。
CaddyはそのトークンをインメモリのHTTPハンドラーに配置します。
Let's EncryptはプレーンなHTTP経由でトークンを取得して検証します。
証明書が発行され、Caddyの証明書キャッシュに保存され、元のHTTPSリクエストが提供されます。

ステップ1〜5は、新しく検証されたドメインへの最初のリクエストに約2〜3秒のレイテンシーを追加します。以降のすべてのリクエストはキャッシュされた証明書を使用し、オーバーヘッドはありません。Caddyは期限切れ前に自動的に更新を処理します。

Elidoはすべてのカスタムドメインに対してECDSA P-256証明書を発行します。P-256の署名はRSA-2048より小さく検証が速く、TLSハンドシェイクがホットパスにあるエッジでは重要です。

最初のTLSハンドシェイク時にCaddyはCaddyAskゲートを呼び出します。404は発行を停止し、検証済みドメインに対する200はLet's EncryptのHTTP-01チャレンジとキャッシュされたECDSA P-256証明書の処理に進みます。

よくある落とし穴#

CAAレコードがLet's Encryptをブロックする。 Certification Authority Authorization（CAA）レコードは、ドメインに対して証明書を発行することが許可されている認証局を指定します。DNSゾーンにexample.com CAA 0 issue "digicert.com"がある場合、Let's Encryptはgo.example.comに証明書を発行することを拒否します。アペックスのCAAポリシーを継承するためです。修正：go.example.com CAA 0 issue "letsencrypt.org"を追加するか、セキュリティポリシーが許可する場合はアペックスの制限を削除します。domain-managerのステータスエンドポイントはエラーボディにCAAエラーを返します。

Cloudflareのプロキシが有効になっている。 ステップ3を参照 - CNAMEはDNSのみ（グレーのクラウド）でなければなりません。オレンジクラウド（プロキシ）モードはリクエスト内のホスト名を書き換え、CaddyAskの認可が失敗します。

アペックスでのCNAMEフラット化。 CloudflareのCNAMEフラット化はほとんどのユースケースで機能しますが、1つの微妙な効果があります：CloudflareのネームサーバーからのDNSレスポンスはCNAMEではなくAレコード（解決されたIP）です。ElidoのCNAMEレコードの検証はプロバイダーのネームサーバーが合成されたCNAMEレスポンスを提供する場合にLookupCNAMEで成功します。DNSプロバイダーのフラット化が最終的なAレコードのみを提供しCNAMEを含まない場合、CNAMEチェックは通りません。実際には、Cloudflareのフラット化はApex以外のレコードのレスポンスチェーンにCNAMEを含みます。Apexではプロバイダーの実装に依存します。バグがあると結論する前に、標準リゾルバーからdig CNAME go.example.comでテストしてください。

ワイルドカードTLSはHTTP-01ではなくDNS-01。 Elidoは標準の自動フロー経由でワイルドカード証明書（*.go.example.com）を発行しません - RFC 8555 §8.4によると、ワイルドカード証明書はDNS-01チャレンジを必要とし、これはDNSゾーンへの書き込みアクセスを必要とします。ElidoはあなたのDNSゾーンを管理していません。Businessプランのワイルドカードドメインはすべてのサブドメインのルーティングをカバーする1つのCNAMEを意味しますが、各ホスト名（client1.go.example.com、client2.go.example.com）は最初のリクエスト時にHTTP-01経由でそれぞれ独自の証明書を取得します - 単一のワイルドカード証明書ではありません。運用上の結果は同じです：サブドメインは自動的に機能します。証明書ストアは比例して増加します。

検証後にCNAMEを削除する。 DNSチームがマイグレーションやクリーンアップ中にCNAMEを削除すると、domain-managerの定期的なヘルスチェックが欠損レコードを検出し、ドメインをdegraded状態に移行します。通知が届き、ドメインが停止される前にグレースピリオドがあります。CNAMEを復元すると、ヘルスチェックがドメインを自動的にアクティブに戻します。

BitlyやRebrandlyとの違い#

Bitlyのカスタムドメインセットアップでは、TLS証明書をアップロードするか、マネージド証明書フローを使用する必要があります。古いプランティアでは手動の証明書リクエストステップが含まれます。自動化のレベルはBitlyのプランによって異なります。エンタープライズアカウントはより管理されたパスを取得します。

RebrandlyのセットアッププロセスはUIが洗練されています - オンボーディングウィザードがプロバイダー固有のCNAME指示を提供し、ブラウザ内で伝播を検証します。基礎となるTLSメカニズムはCloudFront経由です：RebrandlyはAWS CloudFrontのカスタムドメイン機能を使用しており、これは証明書局と証明書のライフサイクルがAmazonのACMによって管理されることを意味します。これは正常に動作しますが、カスタムドメインのトラフィックがデフォルトでAWS US-Eastインフラを通じてルーティングされることを意味し、EUデータ居住地を評価している場合に関連します（完全なデータ居住地比較についてはElido vs Rebrandlyを参照）。

Elidoのアプローチ - domain-manager認可ゲートを備えたCaddyのオンデマンドTLS - は、完全な証明書ライフサイクルを社内で保持し、セルフホストデプロイメントでも同様に機能し、証明書管理のためのサードパーティCDNへの依存を作りません。最初のリクエストのレイテンシーコスト（ACMEチャレンジの2〜3秒）がトレードオフです。以降のリクエストにはオーバーヘッドはありません。

Elido、Bitly、Rebrandlyを、証明書のトリガー、証明書機関、サードパーティCDN依存、セルフホストの同等性、デフォルトのEU居住地の観点で比較したマトリクス。

検証が完了したら、リンク作成コールにdomain_idを渡してカスタムドメインでリンクを作成します - またはダッシュボードやモバイルアプリのドメインピッカーから選択します。リンクは有効な証明書を持つhttps://go.example.com/<slug>ですぐに使用可能になります。

参考文書：カスタムドメインショートリンク：DNS、TLS、エッジで動くものでは、エッジキャッシュメカニクス、レート制限、本番環境の障害モードを含む完全なアーキテクチャを説明しています。CAAの推奨とAPIリファレンスを含む完全なドメイン設定ガイドは/docs/guides/custom-domainsにあります。

Marius VoßはElidoのDevRel + エッジインフラ担当です。edge-redirectとdomain-managerサービスを担当しています。

ブログの関連記事#

Elidoを試す

URLを貼り付けて短縮リンクを取得

登録不要。リンクは30日間有効。永久に保存するには登録してください。

Free、登録不要 · 1日あたり2件