CNAME と Adobe Target

Adobe ClientCareと連携して、Adobe TargetでCNAME（正規名）サポートを実装する方法について説明します。 CNAMEを使用して、広告ブロッキングの問題やITP関連（インテリジェントトラッキング防止）cookieのポリシーを処理します。 CNAMEを使用すると、Adobeが所有するドメインではなく、顧客が所有するドメインに対して呼び出しが行われます。

ターゲットでのCNAMEサポートの要請

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

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

   例えば、クライアントコードが「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/顧客
   • 顧客が証明書(「Bring Your Own Certificate」(BYOC)とも呼ばれる)を購入する場合は、次の追加情報を入力します。
     • 証明書の組織(例：Example Inc):
     • 証明書の組織単位(オプション、例：マーケティング):
     • 証明書の国(例：US):
     • 証明書の状態/地域(例：カリフォルニア):
     • 証明書の市区町村(例：サンノゼ):

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

   お客様が証明書(BYOC)を購入する場合、Adobe ClientCareから証明書署名要求(CSR)が送信されます。 CSRは、任意の認証機関で証明書を購入する場合に使用します。 証明書が発行されたら、証明書のコピーと中間証明書をAdobe ClientCareに送信して、展開します。

   Adobe 導入の準備が整ったら、ClientCareからお知らせします。

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

よくある質問

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

自分の証明書を提供できますか（「自分の証明書を持って来る」または「BYOC」）。

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

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

2020年9月1日以前に発行された証明書は2年間の証明書です。 2020年9月1日以降に発行された証明書は1年間の証明書です。 1年間の証明書への移行について詳しくお読みください。

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

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

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

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

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

現在のターゲットの実装はITP 2.xの影響を受けているか。

Safari ブラウザーでは、Target JavaScript ライブラリを持つ Web サイトにナビゲートします。analytics.company.comなど、CNAMEのコンテキストにTarget cookieが設定されている場合、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 (time-to-live)が関連付けられており、これらのレコードのDNS応答のキャッシュ有効期限を指示します。 そのため、少なくともTTLで待つ必要が生じる場合があります。 dig target.example.comコマンドまたはG Suite Toolboxを使用して、特定のTTLを検索できます。

既知の制限事項

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