vania-janet/multiturn-rag-retrieval-data huggingface dataset:
[Menu icon](https://cloud.ibm.com/docs-content/v1/content/991f60ddbe3ab0a9aa69481a07a0a73b359fa329/icons/icon_hamburger.svg)> Resource List.
2. From the list of services, select your instance of Secrets Manager.
3. In the Secrets engines page, click the Public certificates tab.
4. In the DNS providers table, click Add.
5. Select the DNS provider that you want to use.

Currently, you can add configurations for Cloud Internet Services (CIS) and IBM Cloud classic infrastructure.
6. Grant service access between Secrets Manager and your selected DNS provider.



1. If you choose CIS, grant access by selecting from a list of authorized CIS instances or by entering an API key.

Don't have an authorization yet? You can [create one in the IAM console](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-prepare-order-certificatesauthorize-cis). Optionally, you can grant access to CIS by providing an API key and the instance CRN. You can find the CRN in the Overview page of your CIS service instance. For more information about creating an API key for CIS, see [Granting service access by using an API key](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-prepare-order-certificatesauthorize-cis-another-account)
2. If you choose classic infrastructure, enter the [username and API key](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-prepare-order-certificatesauthorize-classic-infrastructure) that is associated with your account.



7. Click Add.







 Adding a DNS provider configuration from the CLI 

You can add DNS provider configurations to your service instance by using the Secrets Manager CLI. Manual DNS providers can be configured only by using the API.
Release notes for DNS Services 

Use these release notes to learn about the latest updates to IBM Cloud® DNS Services that are grouped by date.



  21 June 2023 

Platform metrics feature enabled
:   Added support for platform metrics to DNS Services.

Madrid region support added
:   Added Madrid multi-zone region support.





  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 secondary zone features for UI, CLI, and API.





  24 June 2022 

Cross account access and linked zones
:   Added cross-account access and linked zones features for UI, CLI, and API.





  18 April 2022 

Import and export DNS records
:   Added UI support for importing and exporting DNS records.





  23 March 2022 

Toronto and Sau Paulo supported across DNS Services
:   Added support for Toronto and Sao Paulo regions.





  17 November 2021 

GA release of custom resolver
:   General availability release of custom resolver feature for UI, CLI, and API.

Improved workflow
:   Improve workflow and add tooltips for enhanced user experience.

High Availability recommendations
:   Update custom resolver High Availability recommendations from beta release.

End of custom resolver beta program
:   Custom resolver beta program ending on 1 December 2021.





  14 July 2021 

Custom resolver beta
:   Add the custom resolver beta feature for UI, CLI, and API.

Import and export of resource records
:   Add import and export of resource records for the CLI and API.

New region support for permitted networks
:   Add Sao Paulo region support for permitted networks.





  18 May 2021 

Service clock synchronization
:   Add service clock synchronization information.





  29 March 2021 

New region support
:   Added the Osaka region to list of available DNS Services resolver regions.
Enhancing your data by defining custom indexed fields 

In IBM Cloud Activity Tracker, you can create custom fields that you can use in advanced searches and in filtering queries by using parsing rules. You define parsing templates through the UI to add custom fields to your records.



 Step 1: Create a parsing rule 

There are occasions when you might want to reference information that is available in log records. Parsing rules maps information from a log line to a field that can be used in other configuration settings.



1. [Make sure you are logged in to the IBM Cloud and have accessed the IBM Cloud Activity Tracker web UI](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-launchlaunch_cloud_ui).
2. Select the view with the fields you want to use. Your view will be listed under the category where it was created, or under UNCATEGORIZED if you didn't specify a category when the view was created. For example, the following shows a view named "My View" that was created without an assigned category.

![Navigation example](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker//images/uncategorized_myview.png)
3. Click the selected view name. The following example shows the view named "My View".

![My View view](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker//images/myview.png)
4. Click the view name. The menu is displayed. Click Edit view properties.

!
Migration tutorial for Heroku apps
: See [Migrating Heroku apps to Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-heroku-migrate).

Supported TLS versions and ciphers
: See [Supported TLS versions and cipher suites](https://cloud.ibm.com/docs/codeengine?topic=codeengine-securesecure-tls).

CLI version 1.40.3 released
: See [CLI version history](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cli_versions).

Updated versions for buildpacks
: See [Choosing a build strategy](https://cloud.ibm.com/docs/codeengine?topic=codeengine-plan-buildbuild-strategy).





 01 December 2022 

CLI version 1.40.2 released
: See [CLI version history](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cli_versions).

Updated versions for buildpacks
: See [Choosing a build strategy](https://cloud.ibm.com/docs/codeengine?topic=codeengine-plan-buildbuild-strategy).







 November 2022 

Review the release notes for November 2022.



 17 November 2022 

Added more information about certificates and considerations when you use Cloud Internet Services (CIS) with custom domain mappings
: See [How can I obtain a certificate for my custom domain?](https://cloud.ibm.com/docs/codeengine?topic=codeengine-domain-mappingsprepare-custom-domain-cert) and [Can I use Cloud Internet Services (CIS) for domain management when I am using custom domain mapping with Code Engine?](https://cloud.ibm.com/docs/codeengine?topic=codeengine-domain-mappingsprepare-use-cis)

Updated versions for buildpacks
GSLB might be implemented for a number of purposes. Some of these could be:



* Load sharing/distribution: To distribute resources efficiently and smartly between multiple locations.
* Disaster recovery: Used when the main or primary location goes down or is unable to render the service. In this scenario an alternate/backup location can take over.
* Performance/shaping: This allows you to position content closer to end systems, or in a way that enhances the service in question.



The main components or entities in the GSLB process/deployment are:



* Virtual servers: A VIP is an IP address to which clients send requests, NetScaler terminates the client connection at the VIP and then it initiates a connection with a server configured in the (local) load balancing service.
* DNS (Domain Name System) and Name servers: Name resolution on GSLB works very much like regular DNS. The difference is the logic/criteria used to determine the address(es) resolved, GSLB uses a pre-configured load balancing method to handle this resolution. NetScaler can be configured to interact with DNS in different ways:



* Authoritative DNS (ADNS). NetScalers using ADNS mode are authoritative for a particular domain and all records on it.
* DNS sub-delegation. Occurs when a DNS server (authoritative of the domain) delegates the responsibility of a sub-domain to a NetScaler system.
* DNS proxy. When configured in this mode, NetScalers forward DNS requests to another server (external) handling the name resolution.



* Method: The method is an algorithm that the GSLB virtual server uses to select the best GSLB service from the topology. The algorithm assesses performance aspects that correspond to the actual selection criteria. The following methods are available:



* Round Robin: Alternates incoming requests to be handled between the GSLB sites/services regardless of their load.
* Round Trip Time (RTT): A measure of time or delay between the client’s local DNS server and the (GSLB) sites. NetScaler uses different mechanisms such as ICMP echo request/reply (PING), UDP, and TCP, to gather the RTT metrics.
This certificate expires on 2023-02-01.
These files will be updated when the certificate renews.
NEXT STEPS:
- This certificate will not be renewed automatically. Autorenewal of --manual certificates requires the use of an authentication hook script (--manual-auth-hook) but one was not provided. To renew this certificate, repeat this same certbot command before the certificate's expiry date.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
* Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
* Donating to EFF: https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Your certificate is ready.





 Can I use Cloud Internet Services (CIS) for domain management when I am using custom domain mapping with Code Engine? 

Yes, you can use IBM Cloud Internet Services for domain management with custom domain mapping with Code Engine.

To enable a domain that is managed by CIS to point to a Code Engine application, set the TLS encryption mode to [End-to-End CA signed](https://cloud.ibm.com/docs/cis?topic=cis-cis-tls-optionstls-encryption-modes-end-to-end-ca-signed) within CIS. This mode requires that you obtain a certificate that is generated and signed by a public and trusted CA, outside of CIS.

Because origin certificates ordered in CIS are not signed by a public and trusted CA, those certificates cannot be used for a domain mapping in Code Engine. You must obtain a CA signed certificated, outside of CIS.
You can configure the load balancers for HTTPS, refer to [Secure with HTTPS](https://cloud.ibm.com/docs/vpc-on-classic?topic=solution-tutorials-vpc-multi-regionvpc-multi-region-6) to configure an SSL certificate and enable HTTPS.





 Test the load balancers 

Complete this procedure for each load balancer.



1. Wait until the status of the load balancer changes to Active.
2. Click the Hostname to copy the hostname and open it in a web browser.
3. Save the address for future reference.









 Step 4: Provision a IBM Cloud Internet Services instance and configure custom domain 

In the following section, you create an IBM Cloud Internet Services instance, configure a custom domain by pointing it to CIS name servers and later configure a global load balancer.



1. Navigate to the [IBM Cloud Internet Services](https://cloud.ibm.com/catalog/services/internet-services) in the IBM Cloud catalog.
2. Enter a Service name, select a resource group, and click Create to provision an instance of the service. You can use any pricing plans for this tutorial.
3. After the service instance is provisioned, set your domain name by clicking Let's get started, enter your domain name, and click Connect and continue.
4. Click Next step. When the name servers are assigned, configure your registrar or domain name provider to use the name servers listed. If you are using the IBM Cloud domain service, see [Getting started with Domain Name Registration](https://cloud.ibm.com/docs/dns?topic=dns-getting-started).
5. After you configured your registrar or the DNS provider, it might require up to 24 hours for the changes to take effect.
6. After the domain's status on the overview page changes from Pending to Active, use the dig <mydomain.com> ns command to verify that the new name for the servers took effect.







 Step 5: Configure a global load balancer
A default forwarding rule is automatically created along with the custom resolver to forward DNS queries to DNS Services servers.





 Use cases and workflows 

The most common use cases of custom resolvers are:



* Forwarding DNS queries from an IBM Cloud VPC to your on-premises DNS servers, or the reverse.
* Forwarding DNS queries from an IBM Cloud VPC to public resolvers.
* Forwarding DNS queries from one IBM Cloud VPC to another.



You can perform the following workflows from the DNS Services dashboard. Navigate to the Custom resolver tab to view your custom resolvers.



 Creating a custom resolver with forwarding rules 

Follow this workflow to create a custom resolver with forwarding rules:



1. Create a custom resolver by selecting the region, VPC, and adding at least two locations for high availability.
2. The default forwarding rule is automatically created to forward all DNS queries to DNS Services servers.
3. Create a forwarding rule to specify where the DNS queries on a DNS zone should be forwarded to, and on which DNS servers.
4. Enable the custom resolver.



The default forwarding rule is always used last if the query name doesn't match any of the preceding forwarding rules.



 Custom resolver with forwarding rules example 

For example, suppose you have a Private DNS zone defined as ibmcloud.example.com and that you configured the permitted network as the VPC appvpc deployed in the Dallas region. The zone ibmcloud.example.com has the following A records:



* app.ibmcloud.example.com A 10.20.30.40
* database.ibmcloud.example.com A 10.20.30.50



You also have a zone onprem.example.com, which is defined in the on-premises DNS server 192.168.5.2, and that zone has the following A records:



* w3.onprem.example.com A 192.168.4.10
* customerdb.onprem.example.com A 192.168.4.40
* Dallas (us-south) - 14 November 2022









 Instructions 

If you already have a valid SSL certificate for your custom domain, you need to upload it into a Secret Manager instance an authorise Cloud Foundry service to access it as per instructions in [Importing SSL certificates into IBM Cloud Secrets Manager](https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-ssl_csrssl_certificate_secrets_manager).

If you don't have a valid SSL certificate for your customs domains, you need to order one via a Certificate Authority before you can proceed with operations. Use the instructions in [Creating certificate signing requests](https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-ssl_csr) to order it. Upon you will have the certificate, please follow instruction reported above in this paragraph.

Upload your application's custom domain SSL certificate before the deadline.

When done, ensure your custom domain URL redirect is working and your required steps are completed.

SSL certificate import is a region specific operation. If you are using the same custom domain and SSL cert across multiple regions, you need to update certificate for each one.





 FAQ 

How does this relate to the IBM Cloud Foundry Deprecation announcement? I still have until June 1, 2023 to run my IBM Cloud Foundry applications, right?
: Yes, this step is separate from the IBM Cloud Foundry Deprecation announcement. This custom domain SSL certificate upload step needs to be done by the [deadline as listed above.](https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-custom_domain_usagecd_deadline) The IBM Cloud Foundry End-of-Support date is still 1 June 2023, as described in this [IBM Cloud Foundry deprecation announcement](https://ibm.biz/ibmcf-announce).

Does each application that has a custom domain forward SSL certificate need to be updated, or just one for the IBM Cloud account in which the application is running?
You can use this Ingress controller to create private routes for your app that are accessible only from within your hosts' private network. To set up public routes in clusters that have private network connectivity only, first [set up your own third-party load balancer](https://cloud.ibm.com/docs/openshift?topic=openshift-sat-expose-appssat-expose-byolb) that has public network connectivity in front of your private Ingress controller before completing the following steps.

Health checks
: DNS registration management is provided by default for your cluster's Ingress controller. For example, if you remove a host that was assigned to your cluster from your location and replace it with a different host, IBM updates the host IP addresses in your Ingress controller's DNS record for you. Note that while the DNS registration for routes are provided for you, no load balancer services are deployed in front of the Ingress controller in your cluster. To health check the IP addresses of the hosts that are registered in the Ingress controller's DNS records, you can [set up your own third-party load balancer](https://cloud.ibm.com/docs/openshift?topic=openshift-sat-expose-appssat-expose-byolb) in front of your Ingress controller before completing the following steps.

To create routes for your apps:



1. Create a Kubernetes ClusterIP service for your app deployment. The service provides an internal IP address for the app that the Ingress controller can send traffic to.

oc expose deploy <app_deployment_name> --name my-app-svc
2. Set up a domain for your app.



* IBM-provided domain: If you don't need to use a custom domain, a route hostname is generated for you in the format <service_name>-<project>.<cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud. Continue to the next step.
* Custom domain: Work with your DNS provider to create a custom domain.
Ensure that you define an HTTPS port in your Kubernetes LoadBalancer service that configures the VPC NLB.
* To use the SSL certificate to access your app via HTTPS, your app must be able to terminate TLS connections.



To register VPC NLB IP addresses with a DNS subdomain,



1. Retrieve the external IP address of your load balancer.

oc get svc -o wide

Example output

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
...
myapp-vpc-nlb-jp-tok-3 LoadBalancer 172.21.xxx.xxx 169.xx.xxx.xx 8080:30532/TCP 1d run=webserver
2. Create a custom or IBM-provided DNS subdomain for the IP address.



* Custom domain:



1. Register a custom domain by working with your Domain Name Service (DNS) provider or [IBM Cloud DNS](https://cloud.ibm.com/docs/dns?topic=dns-getting-started).
2. Define an alias for your custom domain by specifying the load balancer IP addresses as A records.



* IBM-provided subdomain: Use nlb-dns commands to generate a subdomain with an SSL certificate for the IP addresses. IBM Cloud takes care of generating and maintaining the wildcard SSL certificate for the subdomain for you.



1. Create a DNS subdomain and SSL certificate.

ibmcloud oc nlb-dns create vpc-gen2 --type public --cluster <cluster_name_or_id> --ip <vpc_nlb1_ip> --ip <vpc_nlb2_ip> --ip <vpc_nlb3_ip>
2. Verify that the subdomain is created. For more information, see [Understanding the subdomain format](https://cloud.ibm.com/docs/openshift?topic=openshift-loadbalancer_hostnameloadbalancer_hostname_format).
In this section we will use Secrets Manager. With Secrets Manager, you can create, lease, and centrally manage secrets that are used in IBM Cloud services or your custom-built applications. Secrets are stored in a dedicated Secrets Manager instance and you can use built in features to monitor for expiration, schedule or manually rotate your secrets. In this tutorial, we will use a Kubernetes Operator to retrieve the TLS certificate from Secrets Manager and inject into a Kubernetes secret.

You can use an existing instance if you already have one or create a new one by following the steps outlined in [Creating a Secrets Manager service instance](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-create-instance&interface=ui).

Now, import your certificate into the Secrets Manager instance.



1. Access the Secrets Manager service instance from the [Resource List](https://cloud.ibm.com/resources) Under Security.
2. Click on Secrets in the left navigation.
3. Click Add and then TLS certificates.
4. You can select either Import certificate, Order a public certificate or Create a private certificate. Detailed steps are available in the [Adding SSL or TLS certificates](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-certificates&interface=ui) topic. If you selected to import a certificate, make sure to upload the certificate, private key and intermediate certificate files using the Add file button for each.
5. Locate the secret entry for the imported or ordered certificate and click on it.



* Verify the domain name matches your $CUSTOM_DOMAIN. If you uploaded a wildcard certificate, an asterisk is included in the domain name.
* Click the copy symbol next to the secret's ID.
* Create an environment variable pointing to the secret ID:



export SECRET_ID=<secret ID>
6. In Secrets Manager, certificates that you import to the service are imported certificates (imported_cert). Certificates that you order through Secrets Manager from a third-party certificate authority are public certificates (public_cert).
DNS terminology 

Review the following terms to help you understand and use DNS.



  Caching and time to live 

Because of the huge volume of requests generated by a system like DNS, the designers provided a mechanism to reduce the load on individual DNS servers. When a DNS resolver (that is, a client) receives a DNS response, it caches that response for a given period of time, called the time to live, or TTL. The value of TTL is set by the administrator of the DNS server handing out the response. After a response goes into the cache, the resolver consults its cached (stored) answer; only when the TTL expires (or when an administrator manually flushes the response from the resolver's memory) will the resolver contact the DNS server for the same information again.





  Start of Authority (SOA) record parameters 

Generally, the time to live is specified in the Start of Authority (SOA) record. SOA parameters are:



*  Serial: The revision number of this zone file. Increment this number each time the zone file is changed so that the changes are distributed to any secondary DNS servers.
*  Refresh: The amount of time in seconds that a secondary name server should wait to check for a new copy of a DNS zone from the domain's primary name server. If a zone file has changed, then the secondary DNS server updates its copy of the zone to match the primary DNS server's zone.
*  Retry: The amount of time in seconds that a domain's primary name server (or servers) should wait if an attempt to refresh by a secondary name server failed before attempting to refresh a domain's zone with that secondary name server again.
*  Expire: The amount of time in seconds that a secondary name server (or servers) holds a zone before it is no longer considered authoritative.
*  Minimum: The amount of time in seconds that a domain's resource records are valid. This is also known as a minimum TTL, and can be overridden by an individual resource record's TTL.
*  TTL (time to live): The number of seconds a domain name is cached locally before expiration and return to authoritative names servers for updated information.