ダウンタイムなしの移行

エンド顧客がすでに別の CDN で稼働している場合、CNAME を Cloudflare のフォールバックオリジンへ切り替えると、Cloudflare がそのトラフィックをまだプロキシできない短い期間が生じます。事前検証を使うと、DNS 切り替えの前にホスト名の所有権を確認し、必要に応じて TLS 証明書を事前発行できます。移行は途切れなく進みます。

1. API でカスタムホスト名を作成します。
2. HTTP トークンまたは DNS TXT レコードで、ホスト名の所有権を事前検証します。
3. DNS 切り替えの前に TLS 証明書を事前発行します。
4. ホスト名が active であることを確認します。
5. エンド顧客の CNAME を更新します。トラフィックはダウンタイムなしで切り替わります。

Create Custom Hostname エンドポイントを呼び出します。レスポンスの ownership_verification と ownership_verification_http フィールドを控えてください。次の手順で使います。

curl https://api.cloudflare.com/client/v4/zones/{zone_id}/custom_hostnames \
  --header "Authorization: Bearer <API_TOKEN>" \
  --header "Content-Type: application/json" \
  --data '{
    "hostname": "app.example.com",
    "ssl": {
      "method": "http",
      "type": "dv",
      "settings": {
        "http2": "on",
        "min_tls_version": "1.2"
      }
    }
  }'

{
  "result": {
    "id": "24c8c68e-bec2-49b6-868e-f06373780630",
    "hostname": "app.example.com",
    "status": "pending",
    "verification_errors": ["custom hostname does not CNAME to this zone."],
    "ownership_verification": {
      "type": "txt",
      "name": "_cf-custom-hostname.app.example.com",
      "value": "0e2d5a7f-1548-4f27-8c05-b577cb14f4ec"
    },
    "ownership_verification_http": {
      "http_url": "http://app.example.com/.well-known/cf-custom-hostname-challenge/24c8c68e-bec2-49b6-868e-f06373780630",
      "http_body": "48b409f6-c886-406b-8cbc-0fbf59983555"
    },
    "created_at": "2020-03-04T20:06:04.117122Z"
  }
}

この段階では verification_errors に custom hostname does not CNAME to this zone が表示されます。想定どおりの動作です。事前検証が完了すると、このエラーは消えます。

エンド顧客の状況に合う方法を選びます。

エンド顧客が権威 DNS を更新できない場合や、検証をこちらで行う場合に使います。

1. Create Custom Hostname のレスポンスにある ownership_verification_http オブジェクトから、http_url と http_body をコピーします。

2. エンド顧客のオリジンサーバーで、http_url のパスに http_body の値を配信してもらいます。nginx の例は次のとおりです。

   location /.well-known/cf-custom-hostname-challenge/24c8c68e-bec2-49b6-868e-f06373780630 {
       return 200 "48b409f6-c886-406b-8cbc-0fbf59983555\n";
   }

   Cloudflare は User-Agent: Cloudflare Custom Hostname Verification でこの URL をクロールします。オリジンはステータス 200 と、本文にトークンの値そのものを返す必要があります。

3. Cloudflare がトークンをクロールするまで、数分待ちます。所有権が確認されると、ホスト名のステータスは pending から active に変わります。

エンド顧客が権威 DNS プロバイダーに DNS レコードを追加できる場合に使います。

1. Create Custom Hostname のレスポンスにある ownership_verification オブジェクトから、name と value をコピーします。

2. エンド顧客に、DNS プロバイダーで TXT レコードを追加してもらいます。

   タイプ	名前	値
   TXT	_cf-custom-hostname.app.example.com	0e2d5a7f-1548-4f27-8c05-b577cb14f4ec

3. Cloudflare がレコードを検出するまで、数分待ちます。所有権が確認されると、ホスト名のステータスは active になります。

4. ホスト名が active になったら、エンド顧客は TXT レコードを削除できます。

証明書を事前発行しておくと、切り替え時に TLS エラーが起きません。この手順を省くと、エンド顧客の CNAME が Cloudflare を向くまで証明書は発行されません。そのため、DNS 変更のあいだ ssl.status は pending のままです。次のいずれかの方法を選びます。

• Delegated DCV - 1 回限りの CNAME レコードで _acme-challenge を SaaS ゾーンに委譲すると、以降の更新は Cloudflare が自動で処理します。エンド顧客は、自身の権威 DNS に委譲用 CNAME を置けます。顧客の DNS を直接ホストしている場合は、自ゾーンに置くこともできます。
• TXT 検証 - エンド顧客に、権威 DNS へ TXT レコードを追加してもらいます。ワイルドカードのカスタムホスト名では必須です。
• 手動 HTTP 検証 - オリジンの /.well-known/ パスで DCV トークンファイルを配信します。エンド顧客の操作は不要です。

DNS を更新する前に、ホスト名と証明書の両方が準備できていることを確認します。

curl https://api.cloudflare.com/client/v4/zones/{zone_id}/custom_hostnames/{custom_hostname_id} \
  --header "Authorization: Bearer <API_TOKEN>"

{
  "result": {
    "id": "24c8c68e-bec2-49b6-868e-f06373780630",
    "hostname": "app.example.com",
    "status": "active",
    "ssl": {
      "status": "active"
    }
  }
}

進める前に、result.status と result.ssl.status の両方が active になるまで待ちます。どちらかが pending のままなら、待ってから再度ポーリングします。

result.status が active になったら（手順 3 で証明書を事前発行した場合は ssl.status も active）、エンド顧客に CNAME をフォールバックオリジンへ向けてもらいます。

DNS が伝播すると、トラフィックはすぐに Cloudflare 経由でプロキシされます。ホスト名はすでに検証済みで、証明書も発行済みなので、移行中にダウンタイムや証明書エラーは発生しません。

• 事前検証の方法
• 証明書検証の方法
• 検証ステータス
• Cloudflare for SaaS のスタートガイド