syncsync.jp
セキュリティ構築手順書

0エグゼクティブサマリ

結論を3行で

実測で判明した4つの重要事実

本書の作成にあたり、権威DNSに対して実測を行いました。事前の想定と食い違う点が4つあります。

syncsync.jp が「プロダクトサイト」であることの意味

syncsync.jp は工場・現場向けのペーパーレス化SaaS 「SyncSync Form」 の製品サイトで、料金プラン・問い合わせフォーム・モバイルアプリ／Web両対応を持ちます。これは synon.co.jp（コーポレートサイト）と決定的に性格が違います。

費用

やってはいけないこと（先に読む）

1実測した現状（2026-08-17 時点）

DNS レコード

syncsync.jp
  NS        ns1〜ns5.xserver.jp
  SOA       ns1.xserver.jp. root.xserver.jp.
  A         198.51.100.10        （PTR: svXXXXX.xserver.jp）
  *  (A)    198.51.100.10        ★ワイルドカードが存在
  www (A)   198.51.100.10
  mail      CNAME → svXXXXX.xserver.jp   ★明示レコードあり
  api       CNAME → ghs.googlehosted.com ★Google Sites / Workspace 系
  MX        0 syncsync.jp.        ★apex 自身を指している
  TXT       "v=spf1 +a:svXXXXX.xserver.jp +a:syncsync.jp +mx include:spf.sender.xserver.jp ~all"
  TXT       "google-site-verification=（Search Console 発行の43文字。現行値をそのまま転記）"
  _dmarc    "v=DMARC1; p=none; rua=mailto:noreply@syncsync.jp,mailto:sample@synon.co.jp;"
  default._domainkey   "v=DKIM1; k=rsa; p=XXXXXXXXXXXXXXXXXXXXXXXXXXXX..."  ★RSA 2048bit
  _adsp._domainkey     "dkim=unknown"        （ADSP は RFC 6686 で Historic。移管不要）
  DS / CAA / AAAA      なし
  _mta-sts / _smtp._tls / default._bimi   なし

診断結果

MTA-STS を「入れてはいけない」理由

synon.co.jp 版の手順書では MTA-STS を Workers でホストする方法を推奨しましたが、syncsync.jp では推奨しません。

MTA-STS の enforce モードは、受信MXホストが提示するTLS証明書の名前が MX ホスト名と一致することを要求します。ところが Xserver の公式FAQは、独自ドメイン名をメールサーバ名に指定した場合について次のように明記しています。

つまり メールサーバの証明書は sv***.xserver.jp 系であり、syncsync.jp とは一致しない可能性が極めて高い。この状態で MTA-STS を enforce で公開すると、受信メールが配送不能になる恐れがあります。

echo | openssl s_client -starttls smtp -connect syncsync.jp:25 -servername syncsync.jp 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

2synon.co.jp との比較 本書の中核

全体比較表

「同じ手順が使えるもの / 使えないもの」

どちらを先にやるべきか

2ドメイン運用で新たに発生する論点

synon.co.jp 版文書への訂正事項

本調査で、既存の synon.co.jp 版文書に精度不足が2点見つかりました。次回改訂時に反映してください。

3実施順序

全体像

syncsync.jp の作業は 4フェーズ・約8週間です。synon.co.jp 版と最も違うのは、「NS切替」と「プロキシ有効化」を意図的に2〜3日離す点です。Xserver は共有サーバでオリジン側の制御余地がほとんどなく、両方を同時にやると障害の切り分けが不可能になります。

「NS切替」と「プロキシ有効化」を分ける理由

これは syncsync.jp 版で特に強調したい設計判断です。

作業カレンダー（例：着手週を W0 とする）

4Step 1 — ①DNS移管 ＋ WAF / DDoS / CDN / SSL（Xserver 版）

4.1 フェーズ0：事前準備（ここを飛ばすと必ず事故ります）

4.1.1 DKIM レコードの退避 🔴 最優先

Xserver の DKIM 公開鍵は Xserver の DNS にしか自動投入されません。Cloudflare へ NS を切り替えた瞬間、このレコードは世界から消えます。

# 取得例（値はダミー。RSA 2048bit の公開鍵は 392 文字前後になる）
Name : default._domainkey.syncsync.jp
Type : TXT
Value: v=DKIM1; k=rsa; p=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
       ... （以下略・必ずサーバーパネルから実値を取得すること）

4.1.2 全 DNS レコードの棚卸し

一次情報（正）： サーバーパネル > 「DNSレコード設定」 の全レコードを CSV / スクリーンショットで保存。併せて外部から実測して突合します（自動スキャンの取りこぼしを検出するため）。

# 権威DNSに直接問い合わせる
for t in A AAAA MX TXT NS CAA SOA; do
  dig @ns1.xserver.jp $t syncsync.jp +noall +answer
done

for h in www api mail ftp smtp pop imap autodiscover autoconfig cpanel webmail; do
  dig @ns1.xserver.jp A     $h.syncsync.jp +noall +answer
  dig @ns1.xserver.jp CNAME $h.syncsync.jp +noall +answer
done

# 特殊レコード
dig @ns1.xserver.jp TXT default._domainkey.syncsync.jp +noall +answer
dig @ns1.xserver.jp TXT _dmarc.syncsync.jp +noall +answer

# ワイルドカードの確認（存在すれば何でも解決する）
dig @ns1.xserver.jp A zzq7x9-nonexistent.syncsync.jp +noall +answer

さらに、実在サブドメインの棚卸し（ワイルドカード対策）。ワイルドカードがあるため「DNS を見れば実在サブドメインが分かる」という前提が成立しません。以下3つを突き合わせます。

現時点で判明しているもの： @(apex) / www / api / mail / ftp（要確認：ワイルドカード由来の可能性）

4.1.3 メールサーバ証明書の SAN 確認（MTA-STS の可否を確定させる）

echo | openssl s_client -starttls smtp -connect syncsync.jp:25 -servername syncsync.jp 2>/dev/null \
  | openssl x509 -noout -subject -issuer -ext subjectAltName

# 465 (SMTPS) でも確認
echo | openssl s_client -connect syncsync.jp:465 -servername syncsync.jp 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

4.1.4 現行 SSL 証明書の有効期限を記録

echo | openssl s_client -connect 198.51.100.10:443 -servername syncsync.jp 2>/dev/null \
  | openssl x509 -noout -dates -issuer -subject

notAfter の日付をカレンダーに登録します。Xserver の無料独自SSL は有効期間90日で、自動更新は「期限の30日前・25日前・20日前」の3回試行されます。この更新ウィンドウが、フェーズ3以降の最重要監視ポイントになります（4.5節）。

4.1.5 TTL を下げる

サーバーパネル > DNSレコード設定 で、主要レコード（A / MX / TXT）の TTL を 300秒に変更します。切替の48時間前までに実施してください。切り戻しが必要になった際の復旧時間がここで決まります。

4.1.6 Xserver 側セキュリティ機能の棚卸し 🔴 Cloudflare と衝突します

4.1.7 訪問者の実IPを復元する準備

Xserver は共有サーバのため mod_remoteip / ngx_http_realip_module を利用者が設定できません。Cloudflare 経由だとアクセスログもアプリも「全員が Cloudflare のIP」に見えます。

WordPress の場合（推奨）：Cloudflare 公式プラグイン（Cloudflare by Cloudflare, Inc.）を導入して REMOTE_ADDR を CF-Connecting-IP で置換するか、wp-config.php の先頭に以下を記述します。

<?php if (isset($_SERVER['HTTP_CF_CONNECTING_IP']))
  $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_CF_CONNECTING_IP'];

4.2 フェーズ1：Cloudflare ゾーン作成（NS はまだ切り替えない）

4.2.1 ゾーン追加

4.2.2 レコードの1:1再現（★このフェーズの本体）

原則：フェーズ1では全レコードを「DNS only（グレー雲）」で作成します。切替時の変数を最小化するためです。

4.2.3 CNAME Flattening の確認 🔴

DNS > Settings > CNAME Flattening が 「Flatten CNAME at root」（デフォルト） であることを確認します。

4.2.4 切替前の突合検証 ★ここで差分ゼロにする

NS を切り替える前に、Cloudflare の NS に直接問い合わせて内容を検証します。これができるのが「NS切替を後回しにする」最大の利点です。

CFNS=xxx.ns.cloudflare.com    # Cloudflare が割り当てたNSに置き換える
OLDNS=ns1.xserver.jp

# 主要レコードを新旧で並べて比較
for t in A MX TXT NS SOA; do
  echo "=== $t ==="
  echo "--- OLD ---"; dig @$OLDNS $t syncsync.jp +noall +answer
  echo "--- NEW ---"; dig @$CFNS  $t syncsync.jp +noall +answer
done

# DKIM（最重要）— 値が完全一致することを目視確認
dig @$OLDNS TXT default._domainkey.syncsync.jp +noall +answer
dig @$CFNS  TXT default._domainkey.syncsync.jp +noall +answer

# ワイルドカード
dig @$CFNS A zzq7x9-nonexistent.syncsync.jp +noall +answer

チェックリスト（全項目にチェックが入るまで NS を切り替えない）

• apex A が 198.51.100.10
• MX の内容が意図どおり（案A / 案B のどちらか）
• SPF TXT が1文字も違わず一致
• google-site-verification= TXT が存在
• DKIM TXT が旧NSと完全一致（p= の base64 を先頭20文字／末尾20文字まで目視確認）
• _dmarc TXT が存在
• www / api / mail / ftp が旧NSと同じ先を指す
• api が CNAME として返る（A に化けていない）
• ワイルドカードが機能している（存在しないホスト名が 198.51.100.10 を返す）
• 全レコードの Proxy status が DNS only

4.3 【最重要】MX が apex を指している問題 — 案A / 案B の判断

4.3.1 何が起きるのか

MX  syncsync.jp.  →  0 syncsync.jp.     ← MX が apex 自身を指している
A   syncsync.jp.  →  198.51.100.10

4.3.2 案A：MX をメール専用ホストに付け替える（★推奨）

swaks --server 198.51.100.10 --to postmaster@syncsync.jp --from test@example.com \
      --h-Subject "MX pre-flight test" --body "test"

4.3.3 案B：apex をグレー雲のままにする（安全だが機能を捨てる）

• MX / SPF は現状のまま無変更で動きます
• apex → www のリダイレクトは Xserver 側の .htaccess で実施
• 欠点：apex がプロキシされないため 198.51.100.10 が公開され続け、DDoS / WAF の保護外になります

4.3.4 どちらを選ぶか

4.4 フェーズ2〜3：NS切替とプロキシ有効化

4.4.1 NS 切替（フェーズ2）

Xserverアカウント（サーバーパネルではありません）で操作します。

4.4.2 切替後30分以内に必ず実施する確認

4.4.3 プロキシ有効化（フェーズ3）

4.5 SSL 設計 — synon.co.jp とは別物になる 🔴

4.5.1 なぜ synon.co.jp の設計が使えないのか

4.5.2 採用する構成

ブラウザ ──[Universal SSL（Cloudflare 発行・無料）]──> Cloudflare
Cloudflare ──[Full (strict)：Xserver の無料独自SSL = Let's Encrypt を検証]──> Xserver

4.5.3 🔴 本件最大の未確定リスク：Let's Encrypt の自動更新がプロキシ下で回るか

4.5.4 リスク回避策（必ず全部やる）

(a) ACME を絶対に妨げない設定を先に入れる

(b) 更新ウィンドウを監視する（恒久運用）

#!/bin/bash
# check-origin-cert.sh ── cron で毎日実行
EXP=$(echo | openssl s_client -connect 198.51.100.10:443 -servername syncsync.jp 2>/dev/null \
      | openssl x509 -noout -enddate | cut -d= -f2)
DAYS=$(( ($(date -d "$EXP" +%s) - $(date +%s)) / 86400 ))
echo "origin cert expires in $DAYS days ($EXP)"
if [ "$DAYS" -lt 18 ]; then
  echo "ALERT: origin certificate not renewed. 526 risk imminent." >&2
  exit 1
fi

(c) フォールバック手順を用意しておく

(d) 代替策の確認（サポートに問い合わせる価値あり）

サーバーパネル > SSL設定 の 「他社ネームサーバーでのDNS認証」（DNS-01） が更新時にも選択可能かを Xserver サポートに確認してください。DNS-01 ならプロキシの影響を一切受けません。公式マニュアルはこのオプションを「他社サーバーからの移転時の事前発行」の文脈でしか説明しておらず、継続的な自動更新に使えるかは不明です。

4.5.5 段階導入の順序

Flexible（使わない）
  ↓
Full          ← まずここで開始。オリジン証明書の内容を検証しないので 526 が出ない
  ↓  （プロキシ安定を48時間確認）
Full (strict) ← 昇格。ここで初めて 526 のリスクが顕在化する

4.5.6 オリジンIP秘匿（.htaccess による Cloudflare IP 制限）

サーバーパネルの「アクセス拒否設定」は拒否（ブラックリスト）専用で許可リスト機能がなく、「アクセス制限」機能は SSL 自動更新を壊すので使えません。→ .htaccess で実装します（サーバーパネル > 「.htaccess編集」）。

# ---- Cloudflare 以外からの HTTP アクセスを拒否（Apache 2.4 系）----
<RequireAny>
  Require ip 173.245.48.0/20
  Require ip 103.21.244.0/22
  Require ip 103.22.200.0/22
  Require ip 103.31.4.0/22
  Require ip 141.101.64.0/18
  Require ip 108.162.192.0/18
  Require ip 190.93.240.0/20
  Require ip 188.114.96.0/20
  Require ip 197.234.240.0/22
  Require ip 198.41.128.0/17
  Require ip 162.158.0.0/15
  Require ip 104.16.0.0/13
  Require ip 104.24.0.0/14
  Require ip 172.64.0.0/13
  Require ip 131.0.72.0/22
</RequireAny>

# ---- ACME チャレンジは無条件許可（SSL自動更新を守る）★絶対に消さない ----
<Files ~ "^\.well-known">
  Require all granted
</Files>

4.6 WAF 設計 — プロダクトサイト向けに再配分する

4.6.1 Free プランの制約

4.6.2 syncsync.jp 用の5本

4.6.3 🔴 Bot Fight Mode は OFF

4.6.4 Xserver WAF との二重化 — 切り分けられるようにしておく

1. 防御の主戦場は Cloudflare WAF に一本化（Free でも Cloudflare Free Managed Ruleset は使えます）
2. Xserver WAF は「オリジン直叩き」への最終防衛として残す。誤検知が出たら該当ルールのみ OFF
3. Xserver WAF の検知ルールは6種：XSS / SQL / ファイル / メール / コマンド / PHP。シグネチャが素朴で、WordPress 管理画面（テーマ編集、記事本文に ls や mail を含む等）で誤検知が多いことが知られています
4. 移行直後の1〜2週間は、Cloudflare の Custom Rules を Block ではなく Managed Challenge で運用し、Security > Events を毎日確認してから Block へ

4.6.5 その他の推奨設定

4.7 api.syncsync.jp の扱い 🔴

dig CNAME api.syncsync.jp +short
# → ghs.googlehosted.com. が CNAME として返ること（A レコードに化けていないこと）

dig TXT syncsync.jp +short | grep google-site-verification
curl -sI https://api.syncsync.jp/ | head -1

4.8 ワイルドカード * の扱い

4.8.1 リスク

4.8.2 Cloudflare での挙動（公式仕様）

4.8.3 🔴 ワイルドカードをオレンジ雲＋Full (strict) にしてはいけない

Total TLS（深い階層をカバー）は Advanced Certificate Manager（有料アドオン）が必要で、しかもオリジン側の問題は解決しません。

4.8.4 段階的な廃止手順（フェーズ4以降）

5Step 2 — ②メール認証（Xserver 版）

5.1 現状と到達目標

5.2 DKIM — 「設定する」のではなく「守る」

5.2.1 何をするのか

syncsync.jp の DKIM は既に動いています。この章の目的は新規設定ではなく、移管の過程で壊さないことと、将来静かに壊れるのを防ぐことの2点です。

5.2.2 手順

# 値が旧NSと完全一致すること
dig @ns1.xserver.jp        TXT default._domainkey.syncsync.jp +short > /tmp/old.txt
dig @<CloudflareのNS>      TXT default._domainkey.syncsync.jp +short > /tmp/new.txt
diff /tmp/old.txt /tmp/new.txt && echo "MATCH"

# 実際の署名検証（NS切替後）— Gmail の「メッセージのソースを表示」で確認
#   Authentication-Results: mx.google.com;
#     dkim=pass header.i=@syncsync.jp header.s=default

5.2.3 🔴 恒久運用：鍵の突合を月次タスクにする

■ 月次（毎月第1営業日・所要5分）
  1. サーバーパネル > DKIM設定 >［表示］で現在の公開鍵を取得
  2. dig +short TXT default._domainkey.syncsync.jp と突合
  3. 不一致なら Cloudflare の TXT を更新

■ Xserver の以下の操作を行った直後は、必ず即日で上記を実施
  - DKIM設定の ON/OFF 操作
  - 新サーバー簡単移行
  - プラン変更

#!/bin/bash
# dkim-drift-check.sh ── cron で月次実行
CUR=$(dig +short TXT default._domainkey.syncsync.jp | tr -d '"' | tr -d ' ')
KNOWN=$(cat /etc/syncsync/dkim-known-good.txt)
if [ "$CUR" != "$KNOWN" ]; then
  echo "ALERT: DKIM record for syncsync.jp changed." >&2
  exit 1
fi
echo "DKIM record OK"

5.3 SPF — 6ルックアップを4に減らす

5.3.1 現状の何が問題か

v=spf1 +a:svXXXXX.xserver.jp +a:syncsync.jp +mx include:spf.sender.xserver.jp ~all

# 実測した展開結果
syncsync.jp          A → 198.51.100.10
svXXXXX.xserver.jp   A → 198.51.100.10
MX = syncsync.jp     → A → 198.51.100.10     ← 3つとも同じIP

include:spf.sender.xserver.jp
  → spf.sender.xserver.jp   "v=spf1 include:_spf.sender4.xserver.jp include:_spf.sender5.xserver.jp ~all"
  → _spf.sender4.xserver.jp  ip4:183.181.94.185/.186/.187/.188, 183.181.99.206/.207/.208, 183.181.94.252
  → _spf.sender5.xserver.jp  ip4:183.90.235.128/25, 202.233.64.0/24, 85.131.196.0/24, ...

198.51.100.10 は上記の送信リレー群（183.x / 202.x / 85.x）に含まれていません。つまり「サーバ自身のIP」と「Xserver の送信リレー」は別物で、両方を書く現在の構成には理由がある可能性があります（5.3.3 で実測して確定させます）。

5.3.2 🔴 Cloudflare プロキシで SPF が壊れる仕組み

これは 4.3節の MX 問題と表裏一体です。apex をプロキシすると、受信（MX）と送信認証（SPF）が同時に壊れます。

5.3.3 実測して確定させる

Received: from svXXXXX.xserver.jp (svXXXXX.xserver.jp. [198.51.100.10])
        by mx.google.com with ESMTPS id ...
                                          ↑ ここのIPが 198.51.100.10 か 183.x/202.x/85.x か

補助ツール：check-auth@verifier.port25.com へ送信すると SPF/DKIM/DMARC の判定結果が自動返信されます。Cloudflare DMARC Management のレポートで送信元IPを網羅的に把握し、1ヶ月運用してから SPF を確定させるのが最も確実です。

5.3.4 推奨する移管後の値

v=spf1 mx include:spf.sender.xserver.jp ~all       # 案A（MX付替え）採用時
v=spf1 a:mail.syncsync.jp include:spf.sender.xserver.jp ~all   # 案B の場合はこちら

5.4 DMARC — rua の修正と Cloudflare DMARC Management

5.4.1 現状の問題

_dmarc.syncsync.jp  TXT  "v=DMARC1; p=none; rua=mailto:noreply@syncsync.jp,mailto:sample@synon.co.jp;"

5.4.2 なぜ届かないのか（RFC 9990 §4）

5.4.3 ガバナンス上の問題

5.4.4 即時のアクション（フェーズ4）

(1) DMARC レコードを差し替える

Name   : _dmarc
Type   : TXT
Content: v=DMARC1; p=none; rua=mailto:dmarc-reports@syncsync.jp; adkim=r; aspf=r

• 🔴 外部ドメイン宛の rua を削除（届いていないうえに宛先として不適切）
• dmarc-reports@syncsync.jp を Xserver でメールアドレス／転送先として新規作成
• 🔴 pct= は書かないこと。RFC 9989 Appendix A.6「Removal of the 'pct' Tag」で削除されました

(2) Cloudflare DMARC Management を有効化する（無料）

(3) CAA を追加

syncsync.jp.  CAA  0 issue "letsencrypt.org"      # Xserver の無料独自SSL
syncsync.jp.  CAA  0 issue "pki.goog"             # Google（api.syncsync.jp 用）
syncsync.jp.  CAA  0 issue "ssl.com"              # Cloudflare Universal SSL
syncsync.jp.  CAA  0 issuewild ";"                # ワイルドカード証明書の発行を禁止
syncsync.jp.  CAA  0 iodef "mailto:security@syncsync.jp"

5.4.5 段階的強化ロードマップ

DMARCbis（RFC 9989 / 9990 / 9991、2025年）での主な変更点

5.4.6 rua に外部の解析SaaSを使う場合

dig +short TXT syncsync.jp._report._dmarc.<受信ドメイン>
# → "v=DMARC1" が返ること。返らなければレポートは届きません

✅ rua=mailto:dmarc-reports@syncsync.jp のように自ドメイン宛なら、この検証レコードは不要です。

5.5 TLS-RPT のみ導入し、MTA-STS は導入しない

5.5.1 判断の根拠

• MX = syncsync.jp（apex）／案A採用後は mail.syncsync.jp
• Xserver 公式FAQ：独自ドメイン名をメールサーバ名に指定した場合、「SMTP/POP3/IMAP over SSLには対応しておりません」
• → メールサーバの証明書は sv***.xserver.jp 系であり、syncsync.jp とは一致しない可能性が極めて高い
• → この状態で MTA-STS を enforce で公開すると、準拠する送信者からのメールが配送不能になります

5.5.2 TLS-RPT の導入（低リスク・単独で有効）

Name   : _smtp._tls
Type   : TXT
Content: v=TLSRPTv1; rua=mailto:tlsrpt@syncsync.jp

• tlsrpt@syncsync.jp を Xserver で作成（dmarc-reports@ と同じ受け皿に転送してもOK）
• レポートは JSON 形式で、1日1回程度しか届きません（DMARC ほど多くない）
• これで「誰かがうちにメールを送る際に TLS が失敗している」ことが分かります

5.5.3 将来 MTA-STS を導入する場合の条件

1. TLS-RPT を先に入れて1ヶ月観測（失敗がゼロであることを確認）
   ↓
2. MTA-STS を mode: testing で公開（強制しない・レポートだけ取る）
   ↓
3. さらに1ヶ月、レポートで失敗ゼロを確認
   ↓
4. mode: enforce へ

5.5.4 BIMI は対象外

p=quarantine 到達が先であり、50名規模で VMC 費用を投じる価値があるかは別途経営判断です。フェーズ1の対象外とします。

5.6 メールクライアント設定（50台展開用の確定値）

6Step 3 — ⑤Turnstile（syncsync.jp が最大の適用先）

6.1 なぜ syncsync.jp が最優先の適用先なのか

6.2 ウィジェットの構成（syncsync.jp 用）

ウィジェット設定（社内標準値）

6.3 syncsync.jp 側の実装で変える点

(1) hostname 検証の許可リスト

// ★ syncsync.jp 用に変更する2箇所
$allowedHosts = ['syncsync.jp', 'www.syncsync.jp'];
if (!in_array($result['hostname'] ?? '', $allowedHosts, true)) {
    error_log('[Turnstile] hostname mismatch: ' . ($result['hostname'] ?? ''));
    return ['ok' => false, 'errors' => ['hostname-mismatch']];
}
if (($result['action'] ?? '') !== 'product-inquiry') {   // ← フォームごとに変える
    return ['ok' => false, 'errors' => ['action-mismatch']];
}

action はフォームごとに別の値を使ってください。同じウィジェットのトークンを別フォームで使い回す攻撃を防げます。

(2) Xserver 環境でのシークレットキーの置き場所

synon.co.jp 版では getenv('TURNSTILE_SECRET_KEY') を使っていますが、Xserver の共有サーバでは環境変数の設定方法が限られます。

/home/<アカウント>/syncsync.jp/
├── secrets.php          ← ★ ここ（Web からアクセスできない）
└── public_html/
    ├── index.php
    └── contact.php      ← require __DIR__ . '/../secrets.php';

<?php
// /home/<アカウント>/syncsync.jp/secrets.php
return [
    'turnstile_secret' => '0x4AAAAAAA...',
];

<?php
// public_html/contact.php の冒頭
$secrets = require __DIR__ . '/../secrets.php';
$turnstileSecret = $secrets['turnstile_secret'];

(3) WordPress / Contact Form 7 を使っている場合

(4) Cloudflare 経由での実IP（remoteip）

siteverify の remoteip パラメータには、$_SERVER['REMOTE_ADDR'] ではなく CF-Connecting-IP を渡してください。4.1.7 の実IP復元を入れていれば REMOTE_ADDR が置換されているので、そのままで正しく動きます。入れていない場合は全リクエストが Cloudflare のIPになり、remoteip が無意味になります。

6.4 Pre-clearance — syncsync.jp では有効

6.5 検証チェックリスト

7Step 4 — ⑥Web Analytics ／ ⑦Tiered Cache ／ ⑧Security Center

7.1 ⑥ Web Analytics

手順は同じ：アカウントレベルのダッシュボード > Web Analytics > Add a site → プロキシ済みゾーンならホスト名を選んで Done。JSビーコンは Cloudflare が自動注入するため、オリジン側のコード変更は不要です。

curl -s https://syncsync.jp/ | grep -i "cloudflareinsights\|cf-beacon"
# DevTools の Network タブで beacon.min.js の読み込みと /cdn-cgi/rum への POST を確認

7.2 ⑦ Tiered Cache ＋ Cache Rules — syncsync.jp で最も効く施策

パス：Caching > Tiered Cache → トグルを On。Smart Tiered Cache は Free でも利用できます。レイテンシデータを用いてオリジンごとに最も近い上位層を1つ自動選択します。

7.2.1 Cache Rules（Free は10本・上から順に評価）

# ルール1：管理系・動的パスを完全バイパス（最上位）
(http.request.uri.path contains "/wp-admin/")
or (http.request.uri.path contains "/wp-login.php")
or (http.request.uri.path contains "/wp-cron.php")
or (http.request.uri.path contains "/wp-json/")
or (http.request.uri.path contains "/xmlrpc.php")
or (http.request.uri.path contains "/.well-known/")     ← ACME 保護。絶対に外さない
or (http.request.uri.path contains "/contact")          ← フォーム保護
or (http.request.uri.path contains "/inquiry")
→ Cache eligibility: Bypass cache

# ルール2：ログイン中ユーザーをバイパス（Cookie 判定）
(http.cookie contains "wordpress_logged_in_")
or (http.cookie contains "wp-postpass_")
or (http.cookie contains "comment_author_")
→ Cache eligibility: Bypass cache

# ルール3：静的アセットを長期キャッシュ
(http.request.uri.path.extension in
  {"css" "js" "jpg" "jpeg" "png" "gif" "webp" "avif" "svg" "ico"
   "woff" "woff2" "ttf" "eot" "mp4" "pdf"})
→ Cache eligibility: Eligible for cache
  Edge TTL   : Ignore cache-control header and use this TTL = 1 month
  Browser TTL: Override origin = 1 year

# ルール4：HTML をエッジキャッシュ（効果大／リスク中・必ずルール1,2より下）
(http.host eq "syncsync.jp" or http.host eq "www.syncsync.jp")
→ Cache eligibility: Eligible for cache
  Edge TTL   : Ignore cache-control header and use this TTL = 2 hours
  Browser TTL: Respect origin
  Cache Key  : Cache deception armor ON

7.2.2 🔴 Xserver 側のキャッシュを OFF にして責任分界点を1箇所にする

7.2.3 検証

# 静的アセット：2回叩いて MISS → HIT を確認
curl -sI https://syncsync.jp/assets/style.css | grep -i "cf-cache-status\|age\|cache-control"
curl -sI https://syncsync.jp/assets/style.css | grep -i "cf-cache-status"

# フォームページ：BYPASS になること（キャッシュされていたら事故）
curl -sI https://syncsync.jp/contact/ | grep -i "cf-cache-status"

7.3 ⑧ Security Center

syncsync.jp では synon.co.jp より重要度が上がります。理由はワイルドカードの存在です。

82ドメイン共通の運用に足すこと

8.1 Zero Trust は追加作業ゼロ

8.2 🔵 どちらのゾーンを Pro（約$20/月）にするか

8.2.1 どちらを Pro にすべきか

8.2.2 Pro 化しない場合の代替

8.3 恒久タスクへの追加項目

【社内ルール】Xserver で以下を操作したら、必ず Cloudflare 側も確認する
  □ 新サーバー簡単移行 / プラン変更          → DKIM 突合・mail A レコードのIP・SPF
  □ DKIM設定の ON/OFF                        → DKIM 突合
  □ ドメイン設定 / サブドメイン設定の追加削除 → Cloudflare に明示レコードを作る／消す
  □ SSL設定の操作                            → 証明書の notAfter を再記録
  □ WordPressセキュリティ設定の変更           → Cloudflare WAF との整合を確認

8.4 WAF ルールの二重管理をどうするか

8.5 Turnstile ウィジェットの枠管理

8.6 DMARC ランプアップは2系統で別スケジュール

8.7 障害時の切り分けフロー（2ドメイン共通）

最速の切り戻し手段（覚えておくこと）

9未確定事項（着手前に潰すこと）

本書は公式ドキュメントと実測に基づいて書いていますが、以下は確定できていません。着手前に、この表を1つずつ埋めてください。

9.1 🔴 最優先（これが崩れると設計が変わる）

9.2 ⚠️ 重要（作業手順に影響する）

9.3 📋 Free プラン制約の実機確認（2ゾーン分）

9.4 synon.co.jp 版文書への訂正

10付録：作業前後に流すコマンド集

10.1 移管前の記録（フェーズ0）

#!/bin/bash
# snapshot-before.sh ── 移管前の状態を丸ごと記録する
OUT="syncsync-before-$(date +%Y%m%d).txt"
NS=ns1.xserver.jp

{
  echo "=== apex records ==="
  for t in A AAAA MX TXT NS CAA SOA; do dig @$NS $t syncsync.jp +noall +answer; done

  echo "=== subdomains ==="
  for h in www api mail ftp smtp pop imap autodiscover autoconfig webmail; do
    dig @$NS A     $h.syncsync.jp +noall +answer
    dig @$NS CNAME $h.syncsync.jp +noall +answer
  done

  echo "=== special ==="
  dig @$NS TXT default._domainkey.syncsync.jp +noall +answer
  dig @$NS TXT _dmarc.syncsync.jp +noall +answer

  echo "=== wildcard test ==="
  dig @$NS A zzq7x9-nonexistent.syncsync.jp +noall +answer

  echo "=== origin certificate ==="
  echo | openssl s_client -connect 198.51.100.10:443 -servername syncsync.jp 2>/dev/null \
    | openssl x509 -noout -dates -issuer -subject

  echo "=== mail server certificate ==="
  echo | openssl s_client -starttls smtp -connect syncsync.jp:25 -servername syncsync.jp 2>/dev/null \
    | openssl x509 -noout -subject -ext subjectAltName
} | tee "$OUT"

echo "saved to $OUT"

10.2 切替前の突合（フェーズ1）

#!/bin/bash
# compare-ns.sh <CloudflareのNS>
CFNS="$1"
OLDNS=ns1.xserver.jp
[ -z "$CFNS" ] && { echo "usage: $0 <cloudflare-ns>"; exit 1; }

diff_check() {
  local desc="$1"; shift
  local a b
  a=$(dig @$OLDNS "$@" +short | sort)
  b=$(dig @$CFNS  "$@" +short | sort)
  if [ "$a" == "$b" ]; then
    echo "  OK   $desc"
  else
    echo "  DIFF $desc"
    echo "    old: $a"
    echo "    new: $b"
  fi
}

echo "=== record comparison ==="
diff_check "apex A"    A     syncsync.jp
diff_check "MX"        MX    syncsync.jp
diff_check "TXT"       TXT   syncsync.jp
diff_check "www"       A     www.syncsync.jp
diff_check "api CNAME" CNAME api.syncsync.jp
diff_check "mail"      A     mail.syncsync.jp
diff_check "DKIM"      TXT   default._domainkey.syncsync.jp
diff_check "DMARC"     TXT   _dmarc.syncsync.jp
diff_check "wildcard"  A     zzq7x9-nonexistent.syncsync.jp

10.3 切替直後の確認（フェーズ2）

#!/bin/bash
# verify-after.sh
echo "=== NS ===";  dig +short NS syncsync.jp
echo "=== MX ===";  dig +short MX syncsync.jp
echo "=== mail A (must be 198.51.100.10) ==="; dig +short A mail.syncsync.jp
echo "=== apex A ==="; dig +short A syncsync.jp

echo "=== DKIM (must not be empty) ==="
dig +short TXT default._domainkey.syncsync.jp | head -c 80; echo "..."

echo "=== SPF ==="; dig +short TXT syncsync.jp | grep spf1
echo "=== google-site-verification ==="; dig +short TXT syncsync.jp | grep google-site-verification

echo "=== api must be CNAME (not flattened to A) ==="
dig CNAME api.syncsync.jp +short

echo "=== HTTP ==="
for u in https://syncsync.jp/ https://www.syncsync.jp/ https://api.syncsync.jp/; do
  printf "%-32s %s\n" "$u" "$(curl -sI -o /dev/null -w '%{http_code}' "$u")"
done

そして必ず手作業で：

• Gmail から info@syncsync.jp へ送信 → 着信
• info@syncsync.jp から Gmail へ送信 → ソース表示で spf=PASS dkim=PASS dmarc=PASS
• メールクライアント（IMAP 993 / SMTP 465）の送受信

10.4 恒久監視（cron）

#!/bin/bash
# daily-guard.sh ── 毎日1回実行し、異常があれば非ゼロで終了する
FAIL=0

# --- 1. オリジン証明書の期限（526 リスク） ---
EXP=$(echo | openssl s_client -connect 198.51.100.10:443 -servername syncsync.jp 2>/dev/null \
      | openssl x509 -noout -enddate | cut -d= -f2)
DAYS=$(( ($(date -d "$EXP" +%s) - $(date +%s)) / 86400 ))
echo "[cert] expires in $DAYS days ($EXP)"
if [ "$DAYS" -lt 18 ]; then
  echo "  ALERT: origin certificate not renewed. 526 risk imminent." >&2
  FAIL=1
fi

# --- 2. mail が Cloudflare IP に化けていないか ---
MAILIP=$(dig +short A mail.syncsync.jp | head -1)
echo "[mail] $MAILIP"
if [ "$MAILIP" != "198.51.100.10" ]; then
  echo "  ALERT: mail.syncsync.jp is not pointing to the origin. Mail may be broken." >&2
  FAIL=1
fi

# --- 3. DKIM レコードのドリフト ---
CUR=$(dig +short TXT default._domainkey.syncsync.jp | tr -d '" ')
KNOWN=$(cat /etc/syncsync/dkim-known-good.txt 2>/dev/null | tr -d '" ')
if [ -n "$KNOWN" ] && [ "$CUR" != "$KNOWN" ]; then
  echo "  ALERT: DKIM record changed." >&2
  FAIL=1
else
  echo "[dkim] OK"
fi

# --- 4. api が CNAME のまま返っているか ---
APICN=$(dig CNAME api.syncsync.jp +short)
echo "[api] $APICN"
if [ -z "$APICN" ]; then
  echo "  ALERT: api.syncsync.jp is no longer a CNAME. Check CNAME Flattening setting." >&2
  FAIL=1
fi

exit $FAIL

11まとめ

この文書の要点

着手順序（最短経路）

【今すぐ・DNS移管を待たずにできること】
  synon.co.jp: Google Workspace DKIM の有効化 ＋ SPF に include:_spf.google.com を追加
               → Gmail の配信に直接影響するため、これだけは最優先
  syncsync.jp: 9.1 の #1〜#4 を潰す（サポート問い合わせ・openssl・swaks・送信テスト）

【W0〜W1】 syncsync.jp フェーズ0〜2（DKIM退避 → ゾーン作成 → NS切替）
【W2〜W3】 syncsync.jp フェーズ3（www → apex の順にプロキシ）
【W4〜W8】 syncsync.jp フェーズ4（SPF・DMARC・Turnstile・キャッシュ・⑥⑦⑧）
【W6〜】   synon.co.jp の移管に着手（syncsync.jp で運用に慣れてから）

関連文書