vania-janet/multiturn-rag-retrieval-data huggingface dataset:
4. After you've completed one of the validation steps from the section on how to address a Domain Validation Challenge, your CDN moves into Deploying certificate status. During this time, Akamai distributes your validated certificate to their edge servers. Deploying a certificate can take 2 - 4 hours.

When this process is complete, all domains, regardless of the validation method used, move into a CNAME configuration required state.







 Domain Control Validation 

To get your CDN domain name added to the SAN certificate, you must prove that you have administrative control over your domain. This process of proof is referred to as addressing the Domain Control Validation (DCV). You must address the DCV within 48 hours. If you fail to do so, your request expires, and you must begin the order process again. The four different ways to address DCV are described in the sections that follow.



 CNAME 

This method is recommended ONLY if your CDN is not serving live traffic. If your domain is serving live traffic, it is recommended to use one of the other three methods to validate your domain.

To use this method, add a CNAME record for your CDN domain into your DNS configuration. The [IBM CNAME](https://cloud.ibm.com/docs/CDN?topic=CDN-next-steps-after-orderingibm-cname) can be used as the record value. No other action is required by you. The DCV progresses automatically from this point. Validation can take 2 - 4 hours. After the certificate is deployed, your CDN moves directly to Running status.

For the CDN domain cdn.example.com, you can add a CNAME type record to point this domain to IBM CNAME:

Scroll for more

Scroll for more



Table 1. Add CNAME type record to point to CNAME

 Resource Type Host Points to (CNAME) TTL 

 CNAME cdn.example.com example.cdn.appdomain.cloud. 15 minutes 



--------------------





 Challenge domain
IAM and Activity Tracker actions by API 

List of IAM actions and Activity Tracker actions by API method.



 Overview 



Table 1. Overview

 Action Method IAM ACTION AT ACTION 

 Get overview GET /v2/{crn}/zones/{domain_id}/overview internet-svcs.zones.read internet-svcs.overview.read 







 DNS Domains 



Table 2. DNS Domains

 Action Method IAM ACTION AT ACTION 

 List domains or get domain details GET /v1/{crn}/zones internet-svcs.zones.read internet-svcs.zones.read 
 Create a domain POST /v1/{crn}/zones internet-svcs.zones.manage internet-svcs.zones.create 
 Update a domain PATCH /v1/{crn}/zones/{domain_id} internet-svcs.reliability.update internet-svcs.zones.update 
 Delete a domain DELETE /v1/{crn}/zones/{domain_id} internet-svcs.reliability.manage internet-svcs.zones.delete 
 Perform activation check on a domain PUT /v1/{crn}/zones/{domain_id}/activation_check internet-svcs.reliability.update internet-svcs.zones-activation-check.update 
 Get DNSSEC configuration GET /v1/{crn}/zones/{domain_id}/dnssec internet-svcs.reliability.read internet-svcs.dnssec.read 
 Enable / Disable DNSSEC PATCH /v1/{crn}/zones/{domain_id}/dnssec internet-svcs.reliability.update internet-svcs.dnssec.update 







 DNS Records 



Table 3. DNS Records

 Action Method IAM ACTION AT ACTION 

 Get DNS records GET /v1/{crn}/zones/{domain_id}/dns_records internet-svcs.reliability.read internet-svcs.dns-records.read
[112-Developer-tools.svg](https://cloud.ibm.com/media/docs/images/homepage/112-Developer-tools.svg)](https://developer.ibm.com/depmodels/cloud/)[Architecture Center<br><br>Discover the architecture references available for this product.<br><br>![190-Application-Platform.svg](https://cloud.ibm.com/media/docs/images/homepage/190-Application-Platform.svg)](https://www.ibm.com/cloud/architecture)[IBM Training<br><br>Build your skills with IBM Cloud training.<br><br>![83-Elements-of-the-cloud.svg](https://cloud.ibm.com/media/docs/images/homepage/83-Elements-of-the-cloud.svg)](https://www.ibm.com/training/cloud)[Community<br><br>Join the IBM Cloud community and collaborate with others.<br><br>![35-Connectivity.svg](https://cloud.ibm.com/media/docs/images/homepage/35-Connectivity.svg)](https://community.ibm.com/community/user/publiccloud/home)

 Latest updates 

[View more](https://cloud.ibm.com/docs/dns-svcs?topic=dns-svcs-release-notes)21 June 2023 | Platform metrics, Madrid support

Added support for platform metrics feature and Madrid multi-zone region.

24 August 2022 | Resolver locations

Added UI feature to the custom resolver location settings. You can now change resolver location priority by clicking up or down arrows to reorder the list.

20 July 2022 | Secondary zones

Added support for secondary zones feature.
Click the Classic infrastructure tab to manage your classic infrastructure permissions.
2. In the Services section, ensure that the Manage DNS permission is selected.



6. Complete the steps to [add a DNS configuration](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-add-dns-provider) to your Secrets Manager instance.









 Next steps 

Now you're ready to add engine configurations to your instance.

First, [add a certificate authority configuration](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-add-certificate-authority) then, [add a DNS provider configuration](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-add-dns-provider).
Ingress Subdomain: mycluster-<hash>-0000.us-south.containers.appdomain.cloud
Ingress Secret: mycluster-<hash>-0000
5. Ensure that the Ingress controller IP address is registered with your cluster's IBM-provided Ingress subdomain. For example, in a multizone cluster, the public Ingress controller IP in each zone where you have worker nodes must be registered under the same subdomain.

host <ingress_subdomain>

Example output

mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.XX.XX.XXX
mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.XX.XXX.XX
6. If you use a custom domain, verify that you used your DNS provider to map the custom domain to the IBM-provided subdomain or the Ingress controller's public IP address.



* IBM-provided subdomain CNAME: Check that your custom domain is mapped to the cluster's IBM-provided subdomain in the Canonical Name record (CNAME).

host www.my-domain.com

Example output

www.my-domain.com is an alias for mycluster-<hash>-0000.us-south.containers.appdomain.cloud
mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.XX.XX.XXX
mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.XX.XX.XXX
* Public IP address A record: Check that your custom domain is mapped to the Ingress controller's portable public IP address in the A record.

host www.my-domain.com

Example output

www.my-domain.com has address 169.XX.XX.XXX
www.my-domain.com has address 169.XX.XX.XXX
5WtYTzMzqh8l1+MFFDl9xDBnvULuCIIrglM5MeS/qnSg1uMoH2oVPj9TVst/ir8CgYEAxrI7Ws9Zc4Bt70N1As+UnlySjaEVZCMkqvHJ6TCuVZFfQoE0r0whdLdRLU2PsLFP+q7qaeZQqgBaNSKeVcDYRn9B+nY/jOmQoPewPVsp/vQTCnE/R81spu0mp0YI6cIheT1Z9zAy322svcc43JaWB7nmEbeqyLOP4Z4qSOcmghZBSECgYACvR9Xs0DGn+wCsW4vze/2ei77MD4OQvepPIFXndFZtlBy5ADcgE9z0cuVB6CiL8DbdK5kwY9pGNr8HUCI03iHkW6Zs+0L0YmihfEVenPG19PSzK9CaDdhD9KFZSbLyVFmWfxOt50H7YRTTiPMgjyFpfi5j2q348yVT0tEQSnfhRqaQKBgAcWPokmJ7EbYQGeMbS7HC8eWO/RyamlnSffdCdSc7ue3zdVJxpAkQ8Wnqu80pEIF6raIQfAf8MXiiZ7auFOSnHQTXUbhCpvDLKi0Mwq3G8Pl07l+2s6dQG6Tnlv6XTQaMyf6n1yjzL+fzDrH3qXMxHMO/b13EePXpDMpY7HQpoLDin-----END RSA PRIVATE KEY-----n", "bundle_method": "compatible"}' -i "cis-demo"
Show more
<-- </section "id="section-upload-cert-examples" "> --><-- </section "id="section-upload-cert" "> --><-- <section "id="section-update-cert" "> --> ibmcloud cis certificate-update Update a custom certificate for a DNS domain.
Domain Routing for IBM Cloud Object Storage static website hosting 

A static website hosted with IBM Cloud® Object Storage can be configured using IBM Cloud Internet Services. Configuring routing rules for domains hosted in IBM Cloud Object Storage will be explored in this advanced "how to."

These instructions are subject to change and are provided here for review.



 Overview 

When hosting static website content on IBM Cloud Object Storage, you can configure how the public accesses your site by specifying a custom domain. Using IBM Cloud Internet Services configures Object Storage to modify the HTTP host header in response to public requests of your content. For this example, we will use example.com as the domain configured in Cloud Internet Services (CIS), and a desired subdomain, web that you wish your public visitors to view as web.example.com.





 Before you start 

Prerequisites:



* An account for the IBM Cloud Platform
* An instance of Cloud Internet Services (CIS) with an applicable plan and permissions
* An instance of Object Storage with a bucket configured as a hosted static website
* An Internet domain managed through IBM Cloud Internet Services



These instructions require an account with the correct [plan](https://cloud.ibm.com/docs/cis?topic=cis-multi-domain-support) in order to access the services as described.





 IBM Cloud Internet, Domain, and Delivery Services 



 Create a Page Rule to target your bucket 

Creating a "Page Rule" in your instance of IBM Cloud Internet Services will take several steps, and require your [endpoint](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-endpoints) information



1. Select Performance from the Navigation
2. Select the Page rules Tab from the options.
3. In the table of rules (empty if this is the first), Select the "Create rule" button.
4. In the URL match field Enter <sub-domain>.<custom-domain>/. For example, web.example.com/.
5. Select from the options for "Rule Behavior Setting" the "Host Header Override."
From here, you can review the "How to" topics to further configure and manage your CDN.





 For a SAN HTTPS CDN 

Follow these steps to get your CDN up and running:



1. Address the domain validation challenge. For instructions, see [Completing Domain Control Validation for HTTPS with DV SAN](https://cloud.ibm.com/docs/CDN?topic=CDN-completing-domain-control-validation-for-https-with-dv-san).
2. Verify whether CDN traffic works as expected. For instructions, see [Verifying that your CDN is working before pointing to IBM CNAME](https://cloud.ibm.com/docs/CDN?topic=CDN-verify-cdn-before-pointing-domain-to-ibm-cname).
3. After you verify that CDN traffic is working, you must change your DNS record to point your domain to [IBM CNAME](https://cloud.ibm.com/docs/CDN?topic=CDN-next-steps-after-orderingibm-cname). Most DNS providers can give you instructions on setting up or changing the CNAME.

Check with your DNS provider to find out when the changes become active. Then, add a CNAME record for your CDN domain in DNS. To do so, on the DNS configuration page for your CDN domain, create a CNAME record with your CDN domain name as the Host and the IBM CNAME you used to configure the CDN as the CNAME.
4. When the CNAME chaining is complete, highlight the table row of the CDN and click Get status from the Overflow ![Overflow menu](https://cloud.ibm.com/docs-content/v1/content/006fd22ab2811b7d19804c763a00568b3da4c03a/CDN/images/overflow.png) menu until your CDN shows Running status. Alternatively, if you are on the CDN's details page, click Actions > Get status.
For instructions, see [Verifying that your CDN is working before pointing to IBM CNAME](https://cloud.ibm.com/docs/CDN?topic=CDN-verify-cdn-before-pointing-domain-to-ibm-cname).
2. After you verify that CDN traffic is working, you must change your DNS record to point your domain to [IBM CNAME](https://cloud.ibm.com/docs/CDN?topic=CDN-next-steps-after-orderingibm-cname). Most DNS providers can give you instructions on setting up or changing the CNAME.

Check with your DNS provider to find out when the changes become active. Then, add a CNAME record for your CDN domain in DNS. To do so, on the DNS configuration page for your CDN domain, create a CNAME record with your CDN domain name as the Host and the CDN CNAME you used to configure the CDN as the CNAME.
3. When the CNAME chaining is complete, highlight the table row of the CDN and click Get status from the Overflow ![Overflow menu](https://cloud.ibm.com/docs-content/v1/content/006fd22ab2811b7d19804c763a00568b3da4c03a/CDN/images/overflow.png) menu until your CDN shows Running status. Alternatively, if you are on the CDN's details page, click Actions > Get status.



Your CDN is now running. From here, you can review the "How to" topics to further configure and manage your CDN.





 For a SAN HTTPS CDN 

Follow these steps to get your CDN up and running:



1. Address the domain validation challenge. For instructions, see [Completing Domain Control Validation for HTTPS with DV SAN](https://cloud.ibm.com/docs/CDN?topic=CDN-completing-domain-control-validation-for-https-with-dv-san).
2.
* [ibmcloud oc ingress domain credential set cloudflare](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cliingress-domain-credential-set-cloudflare)
* [ibmcloud oc ingress domain default replace](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cliingress-domain-default-replace)
* [ibmcloud oc ingress domain get](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cliingress-domain-get)
* [ibmcloud oc ingress domain ls](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cliingress-domain-ls)
* [ibmcloud oc ingress domain rm](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cliingress-domain-rm)
* [ibmcloud oc ingress domain secret regenerate](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cliingress-domain-secret-regenerate)
* [ibmcloud oc ingress domain secret rm](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cliingress-domain-secret-rm)
* [ibmcloud oc ingress domain update](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cliingress-domain-update)
Manage secondary zones by using the following secondary zone commands.



 ibmcloud dns secondary-zone-create 

Create a secondary zone for given custom resolver.

ibmcloud dns secondary-zone-create RESOLVER_ID --name NAME --transfer-from ADDRESS1,ADDRESS2 [--description DESCRIPTION] [--enabled true|false] [-i, --instance INSTANCE] [--output FORMAT]



 Command options 

RESOLVER_ID
: The ID of the custom resolver. Required.

--name value
: The domain name of the secondary zone.

--transfer-from value
: The source addresses of the secondary zone.

--description value
: The description of the secondary zone.

--enabled value
: Whether the secondary zone is enabled.

-i, --instance value
: Instance name or ID. If not set, the context instance specified by ibmcloud dns instance-target INSTANCE is used.

--output value
: Specify output format. Currently, json is the only supported format.





 Examples 

Create a secondary zone for custom resolver f1aba936b94213e5b8dca0c0dbf1f9cc.

ibmcloud dns secondary-zone-create f1aba936b94213e5b8dca0c0dbf1f9cc --name "test.com" --transfer-from 169.13.12.10 -i "dns-demo"







 ibmcloud dns secondary-zone-update 

Update a secondary zone.

ibmcloud dns secondary-zone-update RESOLVER_ID SECONDARY_ZONE_ID [--transfer-from ADDRESS1,ADDRESS2] [--description DESCRIPTION] [--enabled true|false] [-i, --instance INSTANCE] [--output FORMAT]



 Command options 

RESOLVER_ID
: The ID of the custom resolver. Required.

SECONDARY_ZONE_ID
: The ID of the secondary zone. Required.

--transfer-from value
: The source addresses of the secondary zone.

--description value
: The DNS zone that exists in your external account and is specified in your Cloudflare credentials. This value is a GUID.



 Example ingress domain credential set cloudflare command 

ibmcloud oc ingress domain credential set akamai --cluster mycluster [--access-token TOKEN] [--client-secret SECRET] [--client-token TOKEN] [--host HOST] [-q] [--domain-zone ZONE]







 ibmcloud oc ingress domain default replace 

Change a cluster's default Ingress domain.

ibmcloud oc ingress domain default replace --cluster CLUSTER --domain DOMAIN [-q]

Minimum required permissions
: Operator platform access role for the cluster in IBM Cloud Kubernetes Service.

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster where the domain is applied.

--domain DOMAIN
: Required. The domain that you want to specify as the new default domain for the cluster. You must specify an existing domain.

-q
: Optional: Do not show the message of the day or update reminders.



 Example ingress domain default replace command 

ibmcloud oc ingress domain default replace --cluster CLUSTER --domain DOMAIN [-q]







 ibmcloud oc ingress domain get 

View the details of an Ingress domain.

ibmcloud oc ingress domain get --cluster CLUSTER --domain DOMAIN [--output OUTPUT] [-q]

Minimum required permissions
: Viewer platform access role for IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster where the domain is applied.

--domain DOMAIN
: Required. The domain that you want to view details for.

--output OUTPUT
: Optional: Prints the command output in JSON format.

-q
: Optional: Do not show the message of the day or update reminders.



 Example ingress domain get command
* UI
* CLI
* API







 Adding custom resolver forwarding rules 

Use forwarding rules to configure where to forward DNS queries for resolution.

Forwarding rules are configurations that you can set up to direct DNS queries to specific DNS resolvers. There are 3 parameters that need to be provided in order to setup a forwarding rule:



* Rule Type: Currently only DNS Zone is supported.
* Match: The DNS Zone for which you want the DNS query forwarded.
* Forwarding IP addresses: The IP addresses of the DNS resolvers to which the query is forwarded. If multiple addresses are provided, the Custom Resolver goes through the list using a sequential policy that selects hosts based on sequential ordering, until a resolver responds.

VPC network behavior and your VPC network configurations can also affect traffic to and from custom resolvers located on your VPC. For example, if you want to create a forwarding rule to a DNS resolver on the external internet for DNS queries matching a certain DNS zone, you must create a public gateway to allow external connectivity for your custom resolvers. See [About networking for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-about-networking-for-vpc) for more information on VPC networking.



After a rule is configured and the Custom Resolver is enabled, DNS query requests go to the Custom Resolver first.

Then, the Custom Resolver checks if the query is for any rules that have been configured by comparing against the Match value. If there is a rule for the DNS query, the Custom Resolver forwards the DNS query to the specified DNS resolver in the configured rule. If there is not a rule that matches the DNS query, the Customer Resolver forwards the DNS query to the specified DNS resolver in the default forwarding rule.

Custom resolvers support two types of forwarding rules:



* DNS Zone rules apply for a zone name.
* The Default rule is configured to forward queries to DNS Services DNS resolvers (161.26.0.7, 161.26.0.8).
For linked instances, each instance contains an Active Directory server that sits in the forest root replica ring. The DNS zone files are also replicated on the Active Directory servers.





 vSphere Single Sign On (SSO) domain 

The vSphere Single Sign On (SSO) domain is used as the initial authentication mechanism for a single instance or multiple linked instances. The SSO domain also serves to connect a VMware instance or multiple linked instances to the MSAD server. The following SSO configuration is applied:



* The SSO domain of vsphere.local is always used.
* For VMware instances that are tied to an existing instance, the integrated PSC is joined to the existing instance’s SSO domain.
* The SSO site name is the root domain that was chosen when you deployed your instance.







 Integration with existing forest 

Merging of Active Directory forests is a complex process. If you want to integrate your instance with an existing Active Directory forest, IBM Cloud recommends that you add your existing Active Directory infrastructure as an additional identity source to VMware vCenter Server® rather than attempting to merge forests. IBM Cloud automation requires that you choose a root domain for your instance with at least three qualifiers to reduce the likelihood of conflict with your existing domain.

You have several options for reference to your existing domain as an identity source:



* If you have connectivity to your domain controllers in or from IBM Cloud, you can reference them directly.
* You can deploy read-only replica controllers in IBM Cloud.
* You can add one-way trust from the domain controllers deployed by IBM Cloud to your domain controllers.









 Domain name services 

Domain name services (DNS) in this design is for the cloud management and infrastructure components only.



 Primary vCenter Server instance 

The vCenter Server deployment uses the deployed AD VSIs or VMs as DNS servers for the instance. All deployed components (vCenter with embedded PSC, NSX, ESXi hosts) are configured to point to the AD as their default DNS. You can customize the DNS zone configuration if it does not interfere with the configuration of the deployed components.

This design integrates DNS services on the AD VMs in the following configuration:



* The domain structure is specified by the user.
This token is provided by Akamai.

--host HOST
: The host for the Akamai API Client credentials.

-q
: Optional: Do not show the message of the day or update reminders.

--domain-zone ZONE
: The DNS zone that exists in your external account and is specified in the Akamai credentials. Specify the full zone name, such as example.external.adppdomain.cloud.



 Example ingress domain credential set akamai command 

ibmcloud ks ingress domain credential set akamai --cluster mycluster [--access-token TOKEN] [--client-secret SECRET] [--client-token TOKEN] [--host HOST] [-q] [--domain-zone ZONE]







 ibmcloud ks ingress domain credential set cloudflare 

Add external Cloudflare domain credentials to your cluster.

ibmcloud ks ingress domain credential set cloudflare --cluster CLUSTER [-q] [--token TOKEN] [--domain-zone ZONE]

Minimum required permissions
: Administrator platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster where you want to add the credentials.

-q
: Optional: Do not show the message of the day or update reminders.

--token TOKEN
: The access token for Cloudflare credentials. This token is provided by Cloudflare.

--domain-zone ZONE
: The DNS zone that exists in your external account and is specified in your Cloudflare credentials. This value is a GUID.



 Example ingress domain credential set cloudflare command 

ibmcloud ks ingress domain credential set akamai --cluster mycluster [--access-token TOKEN] [--client-secret SECRET] [--client-token TOKEN] [--host HOST] [-q] [--domain-zone ZONE]







 ibmcloud ks ingress domain default replace 

Change a cluster's default Ingress domain.