vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For the first three options, you will use name servers of the third party (for example, ns1.softlayer.com and ns2.softlayer.com). The last option uses your domain as the name server (for example, ns1.yourdomain.com and ns2.yourdomain.com), and it requires you to run DNS services on your server. You must also register your domain as a name server with your registrar. Name server registration is usually free, but it requires an additional step beyond the basic domain name registration process.

Our customers have free DNS services that are fully managed through the [IBM Cloud console](https://cloud.ibm.com/). It is highly recommended that you allow IBM Cloud to manage your DNS and your name servers, due to our redundant systems, ease of management, and ability to troubleshoot DNS-related issues quickly.





 How do I renew my domain name? 

To renew a registration for an existing domain, select [Classic Infrastructure](https://cloud.ibm.com/gen1/infrastructure/devices) from the menu in the IBM Cloud console, and then go to Services > Domain Registration. See [Renewing existing domains](https://cloud.ibm.com/docs/dns?topic=dns-renew-an-existing-domain).





 Where do I find cost estimates for domain name registration? 

You can estimate the cost of a service using the cost estimator on the provisioning pages for domain name registration. For example, log in to the [Domain Name Service](https://cloud.ibm.com/catalog/infrastructure/domain-registration) console and click Create in the Summary panel. In the Domains page, click the Register list menu. Pricing for registering domains is shown in a list menu in the Register New Domain section.





 How do I manage DNS zones? 

Using the DNS interface, you can manage Forward Zones, Secondary Zones, and Reverse Records. To use this interface, select [Classic Infrastructure](https://cloud.ibm.com/gen1/infrastructure/devices) from the menu in the IBM Cloud console, and then go to Network > DNS.





 How do I set up my reverse DNS?
A 522 error indicates we weren't able to establish a connection with your origin server (that is, your host). After about 15 seconds of connection failure, we close the connection and display a 522 error page.

This issue usually is caused by firewall or security software that accidentally blocks our IP addresses. Because CIS acts as a reverse proxy, connections to your site appear to come from a range of CIS IPs. This behavior can cause certain firewalls to block these connections, which prevents us from serving content to your site visitors properly.

To fix this issue, ask your host to allowlist all of the CIS IP ranges, listed [here](https://cloud.ibm.com/docs/cis?topic=cis-cis-allowlisted-ip-addresses).

All of these IPs must be allowlisted to avoid 522 errors. It's also worth checking to see if any IPs in these ranges are blocked.

522 errors can also be caused by network connectivity issues, so confirm that your server and network is generally healthy and not overloaded.

If after taking the above steps you still receive errors, contact IBM CIS support and confirm the following:



* You've allowlisted our IP ranges
* Your server/network is online and generally healthy



If you contact our support team, please provide a Ray ID from a recent 522 error. We can use this to determine which CIS data center you were hitting and run further tests.





 What is a proxied record and why do I need them? 

Proxied records are records that proxy their traffic through IBM CIS. Only proxied records receive CIS benefits, such as IP masking, where a CIS IP is substituted for your origin IP to protect it:

$ whois 104.28.22.57 | grep OrgName
OrgName: IBM

If you would rather bypass CIS on a domain (we still resolve DNS), then non-proxying the record is a possible solution.





 I got a DNS Validation error: 1004; now what can I do? 

For page rules to work, DNS needs to resolve for your zone. As a result, you must have a proxied DNS record for your zone.
<-- </section "id="section-show-authenticated-origin-pull-certificate-examples" "> --><-- </section "id="section-show-authenticated-origin-pull-certificate" "> --><-- <section "id="section-upload-authenticated-origin-pull-certificate" "> --> ibmcloud cis authenticated-origin-pull-certificate-upload Upload authenticated origin pull certificate for a domain. ibmcloud cis authenticated-origin-pull-certificate-upload DNS_DOMAIN_ID --level zone|hostname] (--json @JSON_FILE | JSON_STRING) -i, --instance INSTANCE] --output FORMAT] ! !!!! ! ! ! ! !
<-- <section "id="section-upload-authenticated-origin-pull-certificate-option" "> --> Command options DNS_DOMAIN_ID: The ID of DNS domain. Required.----level: Specify the authenticated origin pull certificate or settings per zone or hostname level. Valid values: "zone", "hostname". The default is "zone".--json: The JSON file or JSON string used to describe a custom certificate.
<-- <ul> -->

* The required fields in JSON data are "certificate", "private_key":

<-- <ul> -->

* certificate: SSL certificate or certificate and the intermediate(s) for the domain.
* private_key: Private key for the domain.

<-- </ul> -->

<-- </ul> -->

Sample JSON data:
{
"certificate": "-----BEGIN CERTIFICATE-----n...-----END CERTIFICATE-----n",
"private_key": "-----BEGIN PRIVATE KEY-----n...-----END PRIVATE KEY-----n"
}
Configure the VPC, type, subnet, listeners, and pools as needed.
5. Under the DNS type section, choose Private.
6. Click Bind+ to enter DNS instance, and DNS zone information.
7. Click Create to provision the load balancer.







 Binding a DNS zone to an existing load balancer in the UI 

To bind a DNS zone to an existing load balancer, follow these steps:



1. From your browser, open the [IBM Cloud console](https://cloud.ibm.com/login) and log in to your account.
2. Select the Navigation Menu icon ![Navigation Menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) from the upper left, then click VPC Infrastructure > Load balancers in the Network section.
3. From the list of load balancers, select the load balancer to view its details page.
4. Click Bind private DNS in the Private DNS section.
5. Enter the DNS instance, and DNS zone information.
6. Click Bind private DNS to bind the DNS zone to your load balancer.



When migrating to a private DNS zone for an existing load balancer, the default A records in lb.appdomain.cloud are removed. To prepare your client devices, create a CNAME record with the default hostname under the wanted private DNS zone before the migration. After configuring all client devices to use the new private DNS zone, you can then delete the CNAME record and begin the migration. This allows the client devices to cache the private DNS hostname until the A records are created.





 Unbinding a DNS zone to an existing load balancer in the UI 

To unbind a DNS zone from a load balancer, follow these steps:



1. From your browser, open the [IBM Cloud console](https://cloud.ibm.com/login) and log in to your account.
2. Select the Navigation Menu icon !
If this virtual machine does not have access to the private network, you need to replace the server IPs with the IP addresses of the DNS servers you want to use.



* /etc/resolv.conf nameserver 10.0.80.11 nameserver 10.0.80.12



For these changes to take effect, you need to restart networking on the server. You can restart networking by running the following command:



* service network restart







 Ubuntu and Debian 

You configure Ubuntu and Debian networks through a single configuration file. You need to edit this configuration file with the following information. To edit this file, you need to have root access to the server. The base installation of Ubuntu does not provide a root login. However, the user that was created in the installation process can access sudo. You need to use the sudo command to edit the file if you are running Ubuntu.

Example public IP block – 192.0.2.0/29



* IP address – 192.0.2.2
* Gateway – 192.0.2.1
* Subnet Mask – 255.255.255.248



Example private IP block – 10.0.0.0/29

·IP address – 10.0.0.2 ·Gateway – 10.0.0.1 ·Subnet Mask – 255.255.255.248

Public and Private Network

Edit the following file with any text editor and replace example IP addresses with the IPs that are in your Public and Private IP blocks.



* /etc/network/interfaces auto lo iface lo inet loopback

auto eth1
iface eth1 inet static
address 192.0.2.2
netmask 255.255.255.248
gateway 192.0.2.1

auto eth0
iface eth0 inet static
address 10.0.0.2
netmask 255.255.255.248

Static route for backend service network
up route add -net 10.0.0.0/8 gw 10.0.0.1



DNS Configuration
$client = SoftLayer_SoapClient::getClient('SoftLayer_Dns_Domain', $domainId, $apiUser, $apiKey);
 
$result = $client->deleteObject();
print_r($result);

SoftLayer_Dns_Domain::deleteObject Returns a Boolean value: true for successful, false for failed.







 Records 



 List records 

In addition to the method mentioned, domain resource records can be retrieved with SoftLayer_Dns_Domain::getResourceRecords, which returns an array of SoftLayer_Dns_DomainResourceRecord objects.

$domainId = 12345;
$client = SoftLayer_SoapClient::getClient('SoftLayer_Dns_Domain', $domainId, $apiUser, $apiKey);
 
$result = $client->getResourceRecords();
print_r($result);





 Create records 

Creating records directly through the SoftLayer_Dns_Domain_ResourceRecord service is accomplished by creating a SoftLayer_Dns_Domain_ResourceRecord template object and passing it into SoftLayer_Dns_Domain_ResourceRecord::createObject. The use of @ in the host property denotes a wildcard hostname.

The IBM Cloud DNS system supports these record types:



* a
* aaaa
* cname
* mx
* ns
* ptr
* soa
* spf
* srv
* txt



At minimum, the template object must contain:



* data: Value of the record
* host: Label to be added under the zone



$client = SoftLayer_SoapClient::getClient('SoftLayer_Dns_Domain_ResourceRecord', null, $apiUser, $apiKey);
$domainId = 123456;
 
$template = new stdClass();
$template->data = 'webserver01.example.com';
$template->host = 'www';
You can update the transfer interval by [editing the secondary DNS zone](https://cloud.ibm.com/docs/dns?topic=dns-manage-secondary-dns-zonesedit-a-secondary-dns-zone) to avoid the need to force the transfer on a frequent basis.





 Convert a secondary DNS zone to a primary zone 

When you convert a secondary DNS zone to primary, IBM Cloud name servers become the authoritative name servers for the converted zone. Follow these steps to convert a secondary DNS zone to primary from the DNS Secondary Zones page:



1. Locate the row pertaining to the zone you want to convert.
2. Click the Actions menu at the end of the row and select Convert to Primary. A confirmation dialog appears.
3. Click the Yes button to convert the zone, or click No to cancel the action.







 View errors for a secondary DNS zone 

You can view any transfer errors associated with a secondary DNS zone from the DNS Secondary Zones page.



1. Locate the row pertaining to the zone you want to edit.
2. Click the Actions menu at the end of the row and select View Errors. A dialog appears with the errors.
3. Click the Close button to close the errors dialog.
Managing secondary DNS zones 

IBM Cloud® provides secondary DNS to all customers as a means to cache primary DNS zones in the event of a loss of data. Maintaining a secondary DNS zone is not mandatory, but it is strongly encouraged for users with multiple domains.

Using the DNS Secondary Zones page, you can add, edit, and delete secondary DNS zones. You can also force a transfer to the zone, convert the zone from secondary to primary, and view errors associated with the secondary DNS zone.

To get to the DNS Secondary Zones page:



1. From your browser, open the [IBM Cloud® console](https://cloud.ibm.com/) and log in to your account.
2. Select the Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg), then click Classic Infrastructure.
3. From the Classic Infrastructure menu, select Network > DNS > Secondary Zones to open the DNS Secondary Zones page.





 Add a secondary DNS zone 

Follow these steps to add a secondary DNS zone from the DNS Secondary Zones page:



1. Select the Add Zone tab.
2. Enter the domains, IPs (optional), and frequency (optional) in the Domains section.
3. Enter the default IP address in the Default IP field.
4. Enter the default transfer frequency (in minutes) for which the primary DNS zone will transfer to the secondary DNS zone in the Default Transfer Frequency field.
5. Click the Add Zone button to add the zone.







 Edit a secondary DNS zone 

Secondary DNS zones can be edited at any time to update the master name server or transfer interval. Follow these steps to edit a secondary DNS zone from the DNS Secondary Zones page:



1. Locate the row pertaining to the zone you want to edit.
2. Click the cells of the row to update the Master Nameserver and Transfer Interval fields as necessary.
3. Click the Update button to update the secondary DNS zone, or select Cancel to cancel the action.







 Delete a secondary DNS zone
[Delete second subnet](https://cloud.ibm.com/docs-content/v1/content/d56dbd8ab7d14086029681ee71679e14aea53723/dns-svcs/images/cr-no-ha.png)

Figure 1. Delete the second subnet to remove high availability function







 Creating a custom resolver using the CLI 

To create a custom resolver using the CLI, run the following command:

ibmcloud dns custom-resolver-create --name NAME --location LOCATION1 --location LOCATION2 [-description DESCRIPTION] [-i, --instance INSTANCE] [--output FORMAT]

Where:



* -n, --name is the name of the custom resolver.
* -d, --description is the descriptive text of the custom resolver.
* --location is the location where the custom resolver is running. The location subnet CRN is required. For example: --location subnet1,enable --location subnet2,disable
* -i, --instance is the instance name or ID. If this is not set, the context instance specified by dns instance-target INSTANCE is used instead.
* --output specifies output format. Currently, JSON is the only supported format.



To create a custom resolver without high availability, run the command with [-f, --force]:

ibmcloud dns custom-resolver-create --name NAME [--location LOCATION1] [--location LOCATION2] [-description DESCRIPTION] [-f, --force] [-i, --instance INSTANCE] [--output FORMAT]

Where:



* -f, --force allows for creating custom resolver with fewer than 2 locations.







 Create a custom resolver using the API 

To add a custom resolver using the API, follow these steps:



1. Set up your API environment with the correct variables.
2. Store the following values in variables to be used in the API command:



* instance_id, which is the unique identifier of a service instance.
3. Copy your data across.



* For Microsoft® Windows®, format the new storage, and copy the data from your original Block Storage for Classic LUN to your new LUN by using Windows Explorer.
* For Linux®, you can use rsync to copy over the data.

[root@server ] rsync -Pavzu /path/to/original/block/storage/ /path/to/new/block/storage

It is advisable to use the previous command with the --dry-run flag once to make sure that the paths line up correctly. If this process is interrupted, you can delete the last destination file that was being copied to make sure that it is copied to the new location from the beginning.

When this command completes without the --dry-run flag, your data is copied to the new Block Storage for Classic LUN. Run the command again to make sure that nothing was missed. You can also manually review both locations to look for anything that might be missing.

For more information about rsync, see the [rsync man page](https://download.samba.org/pub/rsync/rsync.html).





When your migration is complete, you can move production to the new LUN. Then, you can detach and delete your original LUN from your configuration. The deletion also removes any snapshot or replica on the target site that was associated with the original LUN.





 Snapshots and Replication 

Do you have snapshots and replication established for your original LUN? If yes, you need to set up replication, snapshot space and create snapshot schedules for the new LUN with the same settings as the original volume.
ibmcloud cis firewall-rule-create DNS_DOMAIN_ID (--json @JSON_FILE | JSON_STRING) -i, --instance INSTANCE] --output FORMAT]
Deprecated] ibmcloud cis firewall-rule-create DNS_DOMAIN_ID (-s, --json-str JSON_STR | -j, --json-file JSON_FILE) -i, --instance INSTANCE] --output FORMAT] ! !!!!!! ! ! ! ! !
<-- <section "id="section-create-a-firewall-rule-options" "> --> Command options DNS_DOMAIN_ID: The ID of DNS domain. Required.--expression: A filter expression. For example, ip.src eq 93.184.216.0.--action: The rule action to perform. Valid values: log, allow, challenge, js_challenge, block, bypass.--priority: The rule's priority. Valid values: 0 2147483647. Value 0 means to set to the default value.--description: To briefly describe the rule.--paused: Indicates if the rule is active. Valid values: on, off. Default value is off.--products: The list of security products to be bypassed. Valid values: zoneLockdown, uaBlock, bic, hot, securityLevel, rateLimit, waf.--json: The JSON file or JSON string used to describe a firewall-rule.
<-- <ul> -->

* The required fields in JSON data are expression, action.

<-- <ul> -->

* expression: A filter expression. For example, ip.src eq 93.184.216.0
* action: The rule action to perform. Valid values: log, allow, challenge, js_challenge, block, bypass.

<-- </ul> -->

* The optional fields are description, priority, paused, products.

<-- <ul> -->
The zone becomes active after permitted networks are added.

If the zone creation is unsuccessful, an error notification appears with information about what caused the error.



 Restricted DNS zone names 

Subdomains to any of the restricted 2-level zones are not permitted. For example, my.host.ibm.com is a subdomain to ibm.com. Therefore, my.host.ibm.com is also a restricted zone.

The following DNS zone names are not permitted.



* ibm.com
* softlayer.com
* bluemix.net
* softlayer.local
* mybluemix.net
* networklayer.com
* ibmcloud.com
* pdnsibm.net
* appdomain.cloud









 Editing a DNS zone 



1. From the DNS Zones page, select your zone. Label and Description options appear.
2. Click the edit icon for Label, then enter the label and click Save.
3. Click the edit icon for Description, then enter the description and click Save.







 Deleting a DNS zone 



1. From the DNS Zones page, click the delete icon from the row for the zone you wish to delete. A confirmation dialog appears.
2. Click Delete button.









 Using the API 

First store the API endpoint in a variable so you can use it in API requests without having to type the full URL. For example, to store the production endpoint in a variable, run this command:

DNSSVCS_ENDPOINT=https://api.dns-svcs.cloud.ibm.com

To verify that this variable was saved, run echo $DNSSVCS_ENDPOINT and make sure the response is not empty.



 Authentication 

The Authorization header is required for each API call. This header is the bearer token for the user, which can be retrieved from IAM (for example, using the ibmcloud iam oauth-tokens command).

You must obtain an IAM token and export it into the $TOKEN for DNS Services.





 Creating a DNS zone
Restore your original local hosts file by using the backup copy that was created in Step 2.







 Using wildcard CDN to verify CDN traffic 

The wildcard CDN does not need the DNS record changed to point the domain to the IBM CNAME. The IBM CNAME can be used to access the service, which makes it fast and easy to verify CDN traffic.

To verify CDN traffic using a wildcard certificate, follow these steps:



1. Create a wildcard CDN mapping with a new temporary domain (for example ibm-test-wildcard.cdn-demo.com). This wildcard CDN is only for testing, and it must have the same configuration as the wanted CDN ibm-test.cdn-demo.com. The following configurations, at a minimum, must be the same:



* Origin path
* Origin port type and number
* Origin hostname
* Origin hostheader



The wildcard CDN shows a final list similar to the following image.

Zoom

![CDN list of ibm-test.cdn-demo.com](https://cloud.ibm.com/docs-content/v1/content/006fd22ab2811b7d19804c763a00568b3da4c03a/CDN/images/ibm-test.cdn-demo.com-wildcard-test.png)

Figure 1: CDN list
2. Verify the wildcard traffic. You can add the [Akamai debug headers](https://cloud.ibm.com/docs/CDN?topic=CDN-troubleshoot-cdn-working) to request the wildcard CDN's IBM CNAME.
Name your load balancer. Note that this name appears in your custom domain URL. For example, if your custom domain is global-app.example.com and you name your load balancer global-app, your URL is global-app.example.com.
2. Set Traffic steering to Geo.
3. Add your Geo routes. You can choose to create a route for all CIS regions or only some regions.



* If you create a route for all CIS regions, then in each route that you create, add all the origin pools that you created earlier. Sort them so that a region that contains your running app and is closest to the region route that you are configuring. For example, if you created apps in au-syd, eu-de, and br-sao, then for Oceana, put au-syd first. For Eastern and Western Europe, put de-eu first. And for North and South America, put br-sao first.
* If you create a route for only some CIS regions, add a route for the Default region. This route is the fallback to use when a specified region is not available.



4. Click Create to create the load balancer.









 Step 8: Verify that your app is available 

Open a browser and enter your load balancer name plus your custom domain name; for example, www.global-app.example.com

Now your applications are highly available.





 Step 9: Cleaning up your tutorial 



1. Delete the global load balancers and origin pools from CIS.
2. Delete your DNS records from CIS. For more information, see [Deleting DNS records](https://cloud.ibm.com/docs/cis?topic=cis-set-up-your-dns-for-cisdeleting-dns-records).
3. Delete each project that you created. When you delete a project, all the components contained in that project are also deleted.
Note that you cannot delete a cluster's default domain. If you want to delete the domain that is currently registered as the default, you must first [assign a different default domain](https://cloud.ibm.com/docs/containers?topic=containers-ingress-domainsingress-domain-manage-default).

If you delete a domain that is registered with the IBM internal provider, you cannot reuse the domain name.

For more details and command options, see the [CLI reference](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli&interface=uiingress-domain-rm).

ibmcloud ks ingress domain rm --cluster CLUSTER --domain DOMAIN





 Updating a domain's IP addresses or hostname 

You can update a domain's registered IP addresses (for classic clusters) or hostname (for VPC clusters) after the domain is created or added to the cluster. This command updates all the resources in your cluster with the specified IP addresses or hostnames and changes your app URLs.

For more information and command options, see the [CLI reference](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli&interface=uiingress-domain-update).

Note that when you add IP addresses or hostnames, you must include any IPs or hostnames that are currently registered to the domain. The domain updates with the exact values specified, so any current IP addresses or hostnames are overwritten if they are not included. For example, if 52.137.182.166 is currently registered to your domain and you want to add 52.137.182.270, you must specify --ip 52.137.182.166 --ip 52.137.182.270 in the command.

ibmcloud ks ingress domain update --cluster CLUSTER --domain DOMAIN [--hostname HOSTNAME] [--ip IP]





 Changing a cluster's default domain 

The default Ingress domain is used to form a unique URL for each of your apps and is the domain that is referenced by the IP addresses of any public ALBs in your cluster.