既知の問題と制約事項

ここでは、IBM Cloud® Internet Services (CIS) を使用する場合の制限事項と、エクスペリエンスを向上させるためにお勧めする操作方法について説明します。

Chrome を使用することをお勧めします。
無料トライアル・プランは 1 アカウントにつき 1 インスタンスに制限されています。リソース・インスタンスを作成してドメインを追加すると、CIS の新しいリソース・インスタンスを追加できなくなります。この制限は、試用ドメインを削除してから再び同じリソース・インスタンスにドメインを追加しようとした場合にも適用されます。この操作を行うと、エラーが表示されます。
このサービスの場合、別のプロバイダーで NS レコードを使用するサブドメインの委任だけをサポートしています。 CNAME による委任はサポートしていません。
A、AAAA、CNAMEのワイルドカードレコード（"*"）はプロキシできません。
専用証明書を削除するときには、削除が完了するまでの短時間、それがリストに再表示されることがあります。
カスタムの専用証明書を注文した後にそのホスト名を変更するには、新しい証明書を注文してから、以前の証明書を削除する必要があります。
2 文字の国別コードを使用して作成される IP ルールは、Challengeアクションによってのみ作成できます。ある国からの訪問者をブロックするには、エンタープライズ・プランにアップグレードするか、完全にブロックするためのルールをサーバーに設定します。

証明書

Universal CA: CISは、Universal 証明書の CA を事前の通知なく変更することができ、かかる変更について利用者に通知しない。独自の発行認証局を選択したい場合は、アドバンスド証明書を注文する。
証明書のピン留め： 証明書のピン留めはCISではネイティブにサポートされていません。証明書のピン留めを使用する場合は、カスタム証明書を使用する必要があります。
フルセットアップユニバーサル SSL 証明書は、ルートまたは「example.com」や「www.example.com ような第 1 レベルのサブドメインの SSL のみをサポートする。 dev.www.example.com」や「app3.dev.www.example.com ような第2、第3、第4レベルのサブドメインでSSLサポートを有効にするには、高度な証明書またはカスタム証明書を使用します。
CNAME（部分）セットアップ： CNAME設定ゾーンでは、各サブドメインは独自のユニバーサルSSL証明書を持ち、追加の機能や購入は必要ありません。
範囲： Universal SSLは'CISRangeアプリケーションと互換性がありません。 Rangeを使用する場合は、アドバンスド証明書またはカスタム証明書を使用してください。

DNS

DNS レコードのエクスポートには、非表示にする必要のある Cloudflare CNAME レコードが含まれています。これらのレコードは _ で始まり、通常は、名前が同じで _ が除去されている 2 番目のレコードがあります。
```
Ex.
_cf.generate.yourdomain.com 0   IN  CNAME address.alias.com
cf.generate.yourdomain.com 0    IN  CNAME address2.alias.com
```
適切にインポートするためには、これらのレコードをゾーン・ファイルから削除する必要があります。
CAA DNS レコードのエクスポートは正しく機能しません。 <tag> および <value> は HEX でエンコードされます。

CAA <flags> <tag> <value>
```
Ex.
Original CAA record
caa.yourdomain.com. 1 IN CAA 0 issue "letsencrypt.org"

Exported CAA record
caa.yourdomain.com. 1 IN CAA 0 6973737565 "6c657473656e63727970742e6f7267"
```
これらのレコードは、インポートする前に、16 進から文字列に変換するか、または削除してから手動で追加する必要があります。

エッジ機能

エンタープライズ・プランの CIS インスタンスを標準プランに変更するには、まず、エッジ機能のアクションとトリガーをすべて削除する必要があります。エンタープライズ・プランから標準プランに持ち込まれたエッジ機能のアクションとトリガーは編集できません。それらによって、ドメインの通常のデータ・パス動作に悪影響が及ぶ可能性があります。プランのダウングレードが完了したら、新しいプランでエッジ機能のアクションとトリガーを再作成できます。

グローバル・ロード・バランサー

Cloud Internet Services ではロード・バランサーのホスト名に下線文字 _ を使用できます。ただし、 Kubernetes クラスタは _ を使うことができない。
標準プランでは、最大 5 つのロード・バランサー、プール、およびヘルス・チェックが許可されます。各プールには合わせて 6 つの起点を配置できますが、各 CIS インスタンスでは全体で 6 つの固有の起点だけが許可されます。
削除されたプールとオリジンのヘルスチェックイベントはフィルタリングできませんが、テーブルに表示されます。
ヘルス・チェック・イベントをPool Healthによってフィルターに掛けた場合、Degradedプールは、技術的に正常であるため含まれます。ただし、それには 1 つ以上のクリティカルな起点が含まれている可能性があります。
ヘルス・チェックに要求ヘッダー名を追加するときには、先頭を大文字にした Host を使用してください。ヘルス・チェックに小文字の host を使用すると失敗します。

ページ・ルール

ページ・ルール ID が更新対象の JSON ストリングまたは JSON ファイルに含まれていない場合、IBM Cloud CLI 用の CIS プラグインを使用してページ・ルール設定を更新すると、エラーが発生することがあります。この回避策として、ID を含むページ・ルール用の完全な JSON 構成ファイルを使用して更新をサブミットします。
CIS UI を使用してページ・ルール設定を削除すると、UI で更新の成功が報告された場合でも、設定が削除されていないことがあります。この問題の回避策として、IBM Cloud CLI 用の CIS プラグインを使用して設定を削除し、ページ・ルール ID を JSON 更新文書に含めます。
```
$> ibmcloud cis page-rule-update <domain-id> <rule-id> -j <file>
```
JSON ファイルには、ID を含む完全なページ・ルール構成、および必要な更新が含まれている必要があります。