CNAMEとTarget

Adobe ClientCareと連携して、Adobe TargetでCNAME（正規名）サポートを実装する手順。 CNAMEを使用して、広告ブロックの問題やITP関連(Intelligent Tracking Prevention)Cookieポリシーを処理します。 CNAMEを使用すると、Adobeが所有するドメインではなく、顧客が所有するドメインが呼び出されます。

TargetでのCNAMEサポートのリクエスト

1. SSL証明書に必要なホスト名のリストを決定します（以下のFAQを参照）。

2. 各ホスト名に対して、通常のTargetホスト名clientcode.tt.omtrdc.netを指すCNAMEレコードをDNSに作成します。

   例えば、クライアントコードが「cnamecustomer」で、指定したホスト名がtarget.example.comの場合、DNS CNAMEレコードは次のようになります。

   target.example.com.  IN  CNAME  cnamecustomer.tt.omtrdc.net.
   

   重要

   Adobeの認証局であるDigiCertは、この手順が完了するまで証明書を発行できません。 したがって、この手順が完了するまで、AdobeはCNAME実装のリクエストを満たすことができません。

3. CNAMEサポートをリクエ ストする AdobeClientCareチケットを開く際は、次のフォームに入力して含めてください。

   • AdobeTargetクライアントコード：
   • SSL証明書ホスト名(例：target.example.com target.example.org):
   • SSL証明書の購入者(Adobeを強くお勧めします。FAQを参照してください):Adobe/顧客
   • 顧客が証明書(「自分の証明書を持ち込む」(BYOC)とも呼ばれる)を購入する場合は、次の追加情報を入力します。
     • 証明書の組織(例：Example Company Inc):
     • 証明書の組織単位(オプション、例：マーケティング):
     • 証明書の国(例：米国):
     • 証明書の状態/地域(例：（カリフォルニア州）:
     • 証明書の市区町村(例：サンノゼ):

4. Adobeが証明書を購入する場合、AdobeはDigiCertと連携して証明書を購入し、Adobeの実稼動サーバーにデプロイします。

   顧客が証明書(BYOC)を購入している場合は、Adobe ClientCareから証明書署名要求(CSR)が送信されます。 CSRは、任意の認証局から証明書を購入する場合に使用します。 証明書が発行されたら、証明書と中間証明書のコピーをAdobe Client Careに送信してデプロイします。

   Adobe 実装の準備が整うと、ClientCareから通知されます。

5. at.jsの新しいCNAMEにserverDomainを更新します。

よくある質問

次の情報は、TargetでのCNAMEサポートのリクエストと実装に関するよくある質問に回答します。

私は自分の証明書を提供することはできますか（Bring Your Own CertificateまたはBYOC）?

独自の証明書を指定できます。 ただし、Adobeはこの方法を推奨しません。 AdobeとAdobeが証明書を購入して制御する場合に、SSL証明書のライフサイクルを管理する方が簡単です。 SSL証明書は、毎年更新する必要があります。 したがって、新しい証明書を適時に入手するには、Adobe ClientCareから毎年ご連絡いただく必要があります。 更新された証明書をタイムリーに作成するのが困難な場合があります。 ブラウザーが接続を拒否するので、証明書の有効期限が切れるとTarget実装が危険にさらされます。

新しいSSL証明書の有効期限が切れるまで、どれくらいかかりますか？

2020年9月1日より前に発行された証明書は、2年間の証明書です。 2020年9月1日以降に発行された証明書は1年間の証明書です。

どのホスト名を選択する必要がありますか。 ドメインごとにホスト名をいくつ選択すればよいですか。

Target CNAME実装では、SSL証明書およびお客様のDNSで、ドメインごとに1つのホスト名のみが必要です。Adobeでは、1つのホスト名を推奨します。 独自の目的（例えば、ステージングでのテスト）のために、ドメインごとにより多くのホスト名が必要なお客様もいます。これはサポートされています。

ほとんどのお客様はtarget.example.comのようなホスト名を選択します。 Adobeはこの方法に従うことをお勧めしますが、最終的にはお客様の選択になります。 既存のDNSレコードのホスト名を要求しないでください。 この場合、競合が発生し、Target CNAMEリクエストの解決に時間がかかります。

Adobe AnalyticsのCNAME実装は既にありますが、同じ証明書またはホスト名を使用できますか。

いいえ。Targetには別のホスト名と証明書が必要です。

現在のTargetの実装はITP 2.xの影響を受けますか？

Safari ブラウザーでは、Target JavaScript ライブラリを持つ Web サイトにナビゲートします。Target CookieがCNAMEのコンテキストで設定されている（例：analytics.company.com）場合、ITP 2.xの影響は受けません。

Analytics CNAMEのみを使用して、TargetのITPの問題を解決できます。 Targetがブロックされる広告ブロックシナリオでのみ、別のTarget CNAMEが必要です。

ITPについて詳しくは、Apple Intelligent Tracking Prevention(ITP)2.xを参照してください。

CNAME実装がデプロイされると、どのようなサービス中断が予想されますか。

証明書がデプロイされた際に、サービスの中断は発生しません（証明書の更新を含む）。

ただし、Target実装コード（at.jsのserverDomain）のホスト名を新しいCNAMEホスト名(target.example.com)に変更すると、Webブラウザーでは再訪問者が新しい訪問者として扱われます。 以前のホスト名(clientcode.tt.omtrdc.net)で以前のCookieにアクセスできないので、再訪問者のプロファイルデータは失われます。 ブラウザーのセキュリティモデルにより、以前のCookieにアクセスできなくなります。 この中断は、新しいCNAMEへの最初の切り替え時にのみ発生します。 ホスト名が変更されないので、証明書の更新は同じ効果を持ちません。

CNAME実装で使用されるキータイプと証明書署名アルゴリズムは何ですか？

すべての証明書はRSA SHA-256で、キーはデフォルトでRSA 2048ビットです。 2048ビットを超えるキーサイズは、現在サポートされていません。

CNAME実装のトラフィックに対する準備ができていることを検証するには、どうすればよいですか。

次のコマンドセットを使用します（macOSまたはLinuxのコマンドライン端末では、bashとcurl 7.49+を使用）。

1. このbash関数をターミナルに貼り付けます。

   function validateEdgeFpsslSni {
       domain=$1
       for edge in mboxedge{31,32,{34..38}}.tt.omtrdc.net; do
           echo "$edge: $(curl -sSv --connect-to $domain:443:$edge:443 https://$domain 2>&1 | grep subject:)"
       done
   }
   

2. 次のコマンドを貼り付けます（target.example.comをホスト名に置き換えます）。

   validateEdgeFpsslSni target.example.com
   

   実装の準備が整ったら、次の出力が表示されます。 重要な点は、すべての行にCN=target.example.comが含まれ、これは目的のホスト名に一致します。 行にCN=*.tt.omtrdc.netが含まれる場合、実装は​対応していません。

   $ validateEdgeFpsslSni target.example.com
   mboxedge31.tt.omtrdc.net: *  subject: C=US; ST=California; L=San Jose; O=Adobe Systems Incorporated; CN=target.example.com
   mboxedge32.tt.omtrdc.net: *  subject: C=US; ST=California; L=San Jose; O=Adobe Systems Incorporated; CN=target.example.com
   mboxedge34.tt.omtrdc.net: *  subject: C=US; ST=California; L=San Jose; O=Adobe Systems Incorporated; CN=target.example.com
   mboxedge35.tt.omtrdc.net: *  subject: C=US; ST=California; L=San Jose; O=Adobe Systems Incorporated; CN=target.example.com
   mboxedge36.tt.omtrdc.net: *  subject: C=US; ST=California; L=San Jose; O=Adobe Systems Incorporated; CN=target.example.com
   mboxedge37.tt.omtrdc.net: *  subject: C=US; ST=California; L=San Jose; O=Adobe Systems Incorporated; CN=target.example.com
   mboxedge38.tt.omtrdc.net: *  subject: C=US; ST=California; L=San Jose; O=Adobe Systems Incorporated; CN=target.example.com
   

3. 別のcurlリクエストを使用して新しいDNS CNAMEを検証します。このリクエストにはCN=target.example.comも表示されます。

   curl -sSv https://target.example.com 2>&1 | grep subject:
   

   メモ

   このコマンドが失敗し、上記のvalidateEdgeFpsslSniコマンドが正常に実行された場合は、DNSの更新が完全に反映されるまで待ちます。 DNSレコードには、TTL（有効期間）🔗が関連付けられており、これらのレコードのDNS応答のキャッシュ有効期限を指定します。 その結果、少なくともTTLが設定されている間は待つ必要が生じる場合があります。 dig target.example.comコマンドまたはG Suite Toolboxを使用して、特定のTTLを検索できます。

CNAME でのオプトアウトリンクの使用方法

CNAMEを使用している場合、オプトアウトリンクには次のように「client=clientcode」パラメーターを含める必要があります。
https://my.cname.domain/optout?client=clientcode.

clientcodeをクライアントコードに置き換え、オプトアウトURLにリンクするテキストまたは画像を追加します。

既知の制限事項

• CNAMEとat.js 1.xがサードパーティCookieに基づいているので、QAモードは定着ではありません。 回避策は、移動先の各URLにプレビューパラメーターを追加することです。 CNAMEとat.js 2.xを使用している場合、QAモードは定着です。
• 現在、at.js 1.8.2およびat.js 2.3.1より前のバージョンを使用している場合、overrideMboxEdgeServer設定はCNAMEでは正しく機能しません。古いバージョンのat.jsを使用している場合は、リクエストの失敗を防ぐために、この設定をfalseにする必要があります。 または、at.jsを新しいサポート対象バージョンに更新することを検討してください。
• CNAMEを使用すると、Target呼び出しのCookieヘッダーのサイズが大きくなる可能性が高くなります。 Adobe cookieのサイズを8 KB未満に保つことをお勧めします。