vania-janet/multiturn-rag-retrieval-data huggingface dataset:
A great tool for reviewing domain information is offered by [CentralOps.net](http://centralops.net/co/)

TTL is listed in seconds. Divide by 60 to convert TTL to minutes, or by 3600 to convert to hours.





 After transferring a domain, how long does it take for the domain and the changes made to become visible? 

Your domain and/or changes to it are visible on IBM Cloud DNS servers immediately after the transfer completes. Due to the propagation nature of DNS, there will be a delay before changes are visible on other DNS servers.





 Can I complete AXFR requests on the private network? 

Currently, IBM Cloud does not support AXFR request on the private network. All AXFR requests must be completed on the public network.





 How can I run my own name servers? 

The easiest way to run and manage your own name servers is to use a control panel tool such as Plesk or cPanel. Both of these products have built in domain name servers that allow you to add, modify, or delete domain names.

To begin, register your domain name as a name server with your domain name registrar and assign two IP addresses from your server IP ranges.





 Are zone update notifies supported for secondary DNS zones? 

Zone update notifies are not supported at this time.





 How immediate is the transfer now button for secondary DNS zones? 

After clicking the transfer now button, the domain will be transferred at the beginning of the next minute.





 Can a master be configured on the private network or does it have to go through the public? 

All AXFR requests are made over the public network at this time.





 Is 1 minute the lowest transfer frequency for secondary DNS zones? 

The lowest transfer frequency is 1 minute.





 If frequency is set to 1920 minutes, then back to 10, will the 1920 minutes expire before the new frequency goes into effect? 

The system calculates the retransfer queue by taking the time of our last transfer attempt and adding the frequency to it. So, if you have frequency set to 1920 and you then change it to 10 minutes, as long as it's been at least 10 minutes since the system last tried to transfer, it retries immediately and then every 10 minutes thereafter.
* Add a DNS CNAME record for vpc-lb-region2.



2. Now adjust the global load balancer to use the new CNAME records.



* Open Reliability panel and choose Global Load Balancers.
* Find and edit the Origin Pools to change the OriginsOrigin Address to vpc-lb-region1.example.com.
* Repeat the above steps for vpc-lb-region2.example.com.



3. Turn on end-to-end security.



* Open the Security panel and choose TLS.
* For the Mode choose End-to-end CA signed. This will terminate HTTPS connections at the global load balancer and use HTTPS connections to the VPC load balancer.





In a browser open [https://lb.example.com](https://lb.example.com) to verify success





 Alternative 2: DNS-only mode, traffic flows directly from the client to the VPC Load Balancers 

In this alternative you will order an SSL certificate for lb.example.com from [Let's Encrypt](https://letsencrypt.org/) through Secrets Manager and configure the global load balancer.

It is not currently possible to order a certificate directly for a CIS global load balancer, but it is possible to order one for a CNAME record. So we will create a CNAME to order the certificate.



1. Open the CIS service you created by earlier, you can find it in the [Resource list](https://cloud.ibm.com/resources)
2. Navigate to Global Load Balancers under Reliability and click DNS.
3. Scroll down to DNS Records section and create a new record:



* Type: CNAME
* Name: lb
* TTL: default (Automatic)
* Alias Domain Name: zzz.example.com
* Click Add Record



4. Order a certificate in Secrets Manager



* Open the Secrets Manager service and select Secrets on the left.
* Click Add and then TLS certificates.
* Click on the Order a public certificate tile.
* Complete the form:



* Name - zzz alias.
* Locate the global load balancer created earlier and turn on Proxy.



4. In a browser open [https://lb.example.com](https://lb.example.com) to verify success.



Next configure HTTPS from CIS to the VPC load balancer.

Add an HTTPS listener to the VPC load balancers:



1. Navigate to VPC then Load balancers and click vpc-lb-region1.
2. Choose Front-end listeners.
3. Click Create listener.
4. Select HTTPS and enter for Port a value of 443.
5. Select the Default back-end pool: region1-pool or region2-pool.
6. Select the Secrets Manager instance you created earlier, the SSL Certificate drop down should show the certificate name that you ordered using your Secrets Manager instance earlier from Let's Encrypt. Click on Create.

If the SSL Certificate drop down does not have example.com you may have missed the authorization step above that gives the VPC load balancer access to the Secrets Manager service. Verify that the Secrets Manager service has a certificate for example.com.
7. Repeat the above steps for the vpc-lb-region2 load balancer.



The wildcard certificate created will allow access to domain name like vpc-lb-region1.example.com. Open the the Overview tab of the VPC load balancer vpc-lb-region1 and notice that the Hostname is xxxxxxx-REGION.lb.appdomain.cloud. The wildcard certificate is not going to work. Fix that problem by creating an alias and then update the configuration.



1. A DNS CNAME record can be created to allow clients to look up vpc-lb-region1.example.com and resolve xxxxxxx-REGION.lb.appdomain.cloud.



* In the CIS, open Reliability panel and choose DNS.
* Scroll down to DNS Records and create a record of Type: CNAME, Name: vpc-lb-region1, TTL: Automatic and Alias Domain Name: VPC load balancer Hostname.
3. Click Create listener.
4. Select HTTPS and enter for Port a value of 443.
5. Select the Default back-end pool: region1-pool or region2-pool.
6. Select the Secrets Manager instance you created earlier, the SSL Certificate drop down should show the certificate name that you ordered using your Secrets Manager instance earlier from Let's Encrypt. Click on Create.

If the SSL Certificate drop down does not have example.com you may have missed the authorization step above that gives the VPC load balancer access to the Secrets Manager service. Verify that the Secrets Manager service has a certificate for example.com.
7. Repeat the above steps for the vpc-lb-region2 load balancer.



The wildcard certificate created will allow access to domain name like vpc-lb-region1.example.com. Open the the Overview tab of the VPC load balancer vpc-lb-region1 and notice that the Hostname is xxxxxxx-REGION.lb.appdomain.cloud. The wildcard certificate is not going to work. Fix that problem by creating an alias and then update the configuration.



1. A DNS CNAME record can be created to allow clients to look up vpc-lb-region1.example.com and resolve xxxxxxx-REGION.lb.appdomain.cloud.



* In the CIS, open Reliability panel and choose DNS.
* Scroll down to DNS Records and create a record of Type: CNAME, Name: vpc-lb-region1, TTL: Automatic and Alias Domain Name: VPC load balancer Hostname.
* Add a DNS CNAME record for vpc-lb-region2.



2. Now adjust the global load balancer to use the new CNAME records.



* Open Reliability panel and choose Global Load Balancers.
* Find and edit the Origin Pools to change the OriginsOrigin Address to vpc-lb-region1.example.com.
* Repeat the above steps for vpc-lb-region2.example.com.



3. Turn on end-to-end security.
Understanding cross-account access 

Securely share DNS zones between IBM cloud accounts by enabling cross-account access.

With cross-account access, you can have DNS zones and resource records information that are completely private. Only VPCs that are associated with the DNS zone are able to access the data over a private network on IBM Cloud. The DNS zone and records cannot be publicly accessed from the internet.

Previously, only VPCs from the same account as the provisioned DNS zone could access the DNS zone. With cross-account access, VPCs from separate accounts can now be granted access.



 Features of cross-account access 

The cross-account access feature is offered with IBM Cloud® DNS Services (Standard plan) and is available through UI, CLI and API. After getting the zone ID and ID of the owner's DNS Services instance, you (as a requestor) can create a linked zone in your DNS Services instance.

As a requestor, you create a linked zone and request access to the resources in the other account. The owner then reviews the cross-account access request, and approves or rejects your request. After the request is approved, you can add their resources as permitted networks in your account.





 Understanding key terms 

To understand the overall design of the cross-account access feature, it helps to understand some key terms:

Linked zone
: When you need to access DNS resource records from private DNS zones that are defined in another account, you can create a request to access the zone in the other account. Then, you can add the DNS resource records from the other account as a linked zone in your DNS Services instance.

Cross-account access
: When a requestor creates a linked zone based on the zone ID and ID of the instance provided by the owner, the owner receives a cross-account access request for the zone.





 Example for cross-account access workflow 

In this example, a customer has multiple IBM Cloud accounts based on their business units.



* Account A is an IT service unit which provides services, for example, a database.
* Account B is the production unit.
Working with wildcard records 

A wildcard DNS record helps match non-existent domain names within a particular DNS Zone. Wildcard domain names always contain an asterisk label, which is the * character only. In order for a domain name to be considered a wildcard domain name, the asterisk label must be the lowest (or first) label. An asterisk in any other place is not treated as a wildcard.



* Wildcard record format



* <>.<hostname.zone | zone>



* Valid wildcard record examples



* .example.com 900 IN A 20.20.20.20
* .foo.example.com 900 MX mailserver.example.com



* Invalid wildcard record examples



* foo..example.com 900 IN A 20.20.20.20
* foo.example.com 900 MX mailserver.example.com
* foo.example.com 900 IN A 1.2.3.4







 How wildcard records work 

Use wildcard data only if no other resource records match the Qname. Similarly, do not use wildcard data if the record type does not match the Qtype, even if the resource record matches the Qname.

For example, a type A query for the name www.example.com is made with wildcard: .example.com 900 IN A 20.20.20.20.



* If there is no resource record of the name www.example.com, it matches with the wildcard record.
* The wildcard is matched only if the domain does not exist.







 Limitations 



* A zone cannot contain more than five wildcard records.
* Wildcard records are only allowed for the following record types.



* A
* AAAA
* CNAME
* MX



* PTR records are not supported for A and AAAA type wildcard records.
* [Importing DNS records](https://cloud.ibm.com/docs/dns-svcs?topic=dns-svcs-managing-dns-zonesimport-resource-records-api) does not support wildcard records.
* UI
* CLI
* API







 Creating orgs and spaces 

As an IBM Cloud® account owner, you can add Cloud Foundry orgs and spaces to your account. Only account owners can create new Cloud Found orgs. If you're an organization manager, you can manage the orgs in the account after they are created.

IBM Cloud Foundry Public is deprecated with an end-of-support date of 1 June 2023. For more information, see [Deprecation of IBM Cloud Foundry](https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-deprecation).



 Cloud Foundry org concepts 

Orgs enable collaboration among users and facilitate the logical grouping of project resources in the following ways:



* You can group a set of spaces, apps, services, domains, routes, and users together in orgs.
* You can manage the user access to the orgs and spaces on an individual basis.



Orgs can span multiple regions, and they are defined by the following items:

Spaces
: A subgroup within an org that you can use to organize applications, services, and users. Spaces are tied to a specific region in IBM Cloud.

Users
: The role with basic permission in orgs and spaces. You must be assigned to an org before you can be granted other permissions to the spaces within the org. For more details, see [Cloud Foundry access](https://cloud.ibm.com/docs/account?topic=account-mngcf).

Domains
: Provide the route on the internet that is allocated to the org. A route has a subdomain and a domain. A subdomain is typically the application name. A domain might be a system domain or a custom domain that you registered for your application. If you add a custom domain, you must configure your DNS server to resolve your custom domain to point to the IBM Cloud system domain. In this way, when IBM Cloud receives a request for your custom domain, it can properly route it to your application.

Quota
Configuring a highly available application 

You can deploy your IBM Cloud® Code Engine application across multiple regions to make it resilient to regional failures. Note that this example uses [IBM Cloud Internet Services](https://cloud.ibm.com/docs/cis?topic=cis-getting-started), but you can use alternate providers. This example also uses a custom domain.



 Prerequisites 



* You must have a custom domain name for your application, such as example.com. This domain name is used by your Code Engine application.
* Set up an instance of [Cloud Internet Services (CIS)](https://cloud.ibm.com/catalog/services/internet-services).
* [Add your domain name to Cloud Internet Services (CIS)](https://cloud.ibm.com/docs/cis?topic=cis-getting-startedadd-configure-your-domain). When you register your domain name with Cloud Internet Services (CIS), you are delegating control of your domain name to Cloud Internet Services (CIS). Note that this step can take a while to complete.







 Step 1: Create projects in different regions 

Create a Code Engine project in three different regions. You can use a common naming pattern and a shared tag.

For example, create a project called global-app-project in the au-syd, eu-de, and br-sao regions with either the CLI or from the console.



Table 1. Projects in multiple regions

 Name Status Tag Location Resource group Created 

 global-app-project Ready global-app Sydney (au-syd) default 
 global-app-project Ready global-app Frankfurt (eu-de) default 2 min 
 global-app-project Ready global-app Sao Paulo (br-sao) default 3 min 



For more information, see [Managing projects](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-project).





 Step 2: Deploy your apps in multiple regions 

Now that your projects are created in multiple regions, deploy your application in each project.

For example, deploy the codeengine/helloworld app.



1.
Use the ALB's IP address (classic) or hostname (VPC), the app path, and your domain to verify that you can successfully send traffic to your app through this ALB.

curl http://<ALB_IP>/<app_path> -H "Host: <ingress_subdomain>"

For example, to send a request to an app called myapp by using a default Ingress subdomain, run the following command.

curl http://169.X.X.X/myapp -H "Host: mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud"



Having trouble connecting to your app through Ingress? Try [Troubleshooting Ingress](https://cloud.ibm.com/docs/containers?topic=containers-ingress-debug). You can check the health and status of your Ingress components by running ibmcloud ks ingress status-report get -c <cluster_name_or_ID>.







 Custom domains with Ingress 

If you do not want to use the IBM-provided Ingress subdomain, you can use your own custom domain that you specify in your Ingress resource. Note that apps exposed with Ingress over private ALBs require a custom domain.



 Creating custom domains for public ALBs 

Follow the steps to create a custom domain for public ALBs.



1. Create a custom domain. To register your custom domain, work with your Domain Name Service (DNS) provider or [IBM Cloud DNS](https://cloud.ibm.com/docs/dns?topic=dns-getting-started). If the apps that you want Ingress to expose are in different namespaces in one cluster, register the custom domain as a wildcard domain, such as .custom_domain.net. Note that domains are limited to 130 characters or fewer in Kubernetes version 1.20 or later.
2. Define an alias for your custom domain by specifying the IBM-provided subdomain as a Canonical Name record (CNAME).
Custom Domain update required for Cloud Foundry Applications 

IBM® Cloud Foundry is deprecated and no longer supported as of 1 June 2023. For more information, see the [deprecation details](https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-deprecationdep_details).

In addition to the [IBM Cloud Foundry deprecation announcement](https://ibm.biz/ibmcf-announce), all IBM Cloud Foundry users that have and are using a custom domain forward pointing to an IBM Cloud Foundry application will need to upload a new application SSL certificate before the deadline of 29 September 2022.



 Custom domain forwarding change needed for applicable IBM Cloud Foundry applications 

Security changes require IBM Cloud Foundry to store SSL certificates using a different storage technology. This means that any IBM Cloud Foundry application that is being forwarded to as a custom domain, and has an SSL certificate uploaded to properly terminate that forward, needs to upload that SSL certificate again.

The upload process will put it in the proper place and the forward will keep working like it does today.

Some notes about this process



* You do not need to regenerate a new SSL certificate if it is still valid, you just need to upload it again
* Be sure to upload it into the account that hosts your IBM Cloud Foundry application - multiple people can have access to an IBM Cloud account for deployment of applications, so be sure to use the one that holds that certificate currently.
* If you uploaded certificates for multiple specific IBM Cloud regions, you need to upload them to the same regions again
* Some users in their DNS forwarding to these custom domains are using only A records, or specific IP addresses, and not CNAME records, like "custom-domain.us-south.cf.cloud.ibm.com" like instructions explain. If you use A record IP addresses ONLY in your DNS forwarding, then this change may cause your application to not forward, even if you upload the SSL certificates.







 Cloud Foundry domains 

You can examine which domains you currently have set up on your IBM Cloud account that might be served by IBM Cloud Foundry applications, using one of the methods below.



 UI method 



1.
If you have a working ACME client or account for Let's Encrypt, you can use your existing private key. If you don't have an account yet, you can create one by using the [ACME account creation tool](https://github.com/ibm-cloud-security/acme-account-creation-tool).

Certificate authorities can apply a charge when you are ordering or renewing a certificate. Additionally, various rate limits apply. Secrets Manager does not control costs or rate limits that are associated with ordering certificates. For more information about rate limits to keep in mind as you order Let's Encrypt certificates, check out the [Let's Encrypt documentation](https://letsencrypt.org/docs/rate-limits/).







 Supported DNS providers 

A DNS provider is the service that is used to manage the domains that you own. You can connect the following DNS providers with your Secrets Manager service instance.



Table 2. DNS provider options

 DNS provider Description 

 [IBM Cloud Internet Services](https://cloud.ibm.com/catalog/services/internet-services) IBM Cloud® Internet Services (CIS), powered by Cloudflare, provides a fast, highly performant, reliable, and secure internet service for customers who are running their business on IBM Cloud. 
 [IBM Cloud classic infrastructure](https://cloud.ibm.com/catalog/infrastructure/domain_registration) [IBM Cloud® Domain Name Registration](https://cloud.ibm.com/docs/dns), available as part of IBM Cloud classic infrastructure (SoftLayer), offers a central location from which to view and manage domains. 
 [Manual DNS providers](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-public-certificatesorder-public-cert-manual-ui) If your DNS provier is not IBM Cloud Internet Services or IBM Cloud Domain Name Registration, you can connect your Secrets Manager to your DNS provider manually. 





 Granting service access to CIS 

If you manage your domains in Cloud Internet Services (CIS), you must assign access to Secrets Manager so that it can validate the ownership.
Note that registering credentials for Cloudflare requires the following permissions in your external Cloudflare account: Zone Settings: Read, Zone: Read, DNS: Read, Zone: Edit, DNS: Edit, API Tokens: Read.

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

-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 Cloudflare account and is specified in your [provider credentials](https://cloud.ibm.com/docs/containers?topic=containers-ingress-domainsingress-domains-ext-cred). This is a GUID value.





 Verify the provider credentials 

Verify that the provider credentials were added to your cluster.

ibmcloud ks ingress domain credential get --cluster CLUSTER [--output OUTPUT] [-q]







 Create a domain, or add an existing domain 

Create or add a domain to your cluster with the ibmcloud ks ingress domain create. If you already have a domain provisioned with an internal or external provider and have set up any necessary credentials, you can use this command to add that domain to your cluster. Or, you can provision a new domain in both your cluster and in your provider account. To specify an existing domain, include the full domain name with the external provider zone, such as exampledomain.externalzone.com. To create a new domain, you must still include the external provider zone, but you can customize the subdomain portion, such as new-exampledomain.externalzone.com.
Note that registering credentials for Cloudflare requires the following permissions in your external Cloudflare account: Zone Settings: Read, Zone: Read, DNS: Read, Zone: Edit, DNS: Edit, API Tokens: Read.

ibmcloud oc ingress domain credential set cloudflare --cluster CLUSTER --token TOKEN --zone CLOUDFLARE_ZONE [-q]

-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 Cloudflare account and is specified in your [provider credentials](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-domainsingress-domains-ext-cred). This is a GUID value.





 Verify the provider credentials 

Verify that the provider credentials were added to your cluster.

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







 Create a domain, or add an existing domain 

Create or add a domain to your cluster with the ibmcloud oc ingress domain create. If you already have a domain provisioned with an internal or external provider and have set up any necessary credentials, you can use this command to add that domain to your cluster. Or, you can provision a new domain in both your cluster and in your provider account. To specify an existing domain, include the full domain name with the external provider zone, such as exampledomain.externalzone.com. To create a new domain, you must still include the external provider zone, but you can customize the subdomain portion, such as new-exampledomain.externalzone.com.