vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For example, if object storage origin s3-example.object-storage.com with bucket name xyz-bucket-name is added in path /example-cos/, when a user opens the CDN URL cdn.example.com/example-cos/, the CDN edge server retrieves the content from s3-example.object-storage.com/xyz-bucket-name/.



* What's the difference between the origin on the Settings page and the origins on the Origins page?

 What's the difference between the origin on the Settings page and the origins on the Origins page? 

The Settings page shows the origin path created during CDN provisioning. You cannot edit or delete it. However, on the Origins page, you can configure different types of origins (COS or origin server). You can also edit or delete origins on this page.
* Why can't I change the protocol and port for an origin?

 Why can't I change the protocol and port for an origin? 

The displayed protocol and port options match what you selected when you ordered the CDN. For example, if you selected an HTTP port when you ordered a CDN, only the HTTP port option is shown as part of Add Origin.
* How many origins can I add to a CDN?

 How many origins can I add to a CDN? 

See [Known limitations](https://cloud.ibm.com/docs/CDN?topic=CDN-limits-and-maximum-valuesis-there-a-limit-on-the-number-of-origin-and-ttl-entries) for the number of origins per CDN.
* Will deleting a CDN also delete my account?

 Will deleting a CDN also delete my account? 

No. Selecting Delete deletes only the CDN; it does not delete your account.
* Why is the DV SAN certificate CDN still there after I deleted it?

 Why is the DV SAN certificate CDN still there after I deleted it? 

If your CDN is configured with HTTPS with DV SAN certificate, it can take up to 5 hours to complete the deletion process.
Managing domains with the DNS service (ibmcloud sl dns) 

IBM Cloud® Domain Name Service (DNS) provides customers with a central location to view and manage their domains through the basic DNS management interface. Users can manage reverse and secondary DNS in the same location free of charge.

Use the following commands from the IBM Cloud® Command Line Interface to manage the IBM Cloud classic infrastructure DNS service.



 ibmcloud sl dns import 

Import a zone based off a BIND zone file:

ibmcloud sl dns import ZONEFILE [OPTIONS]

Command options:

--dry-run
: Don't actually create records.

Examples:

ibmcloud sl dns import /ibm.com.txt

This command imports zone and its resource records from file: /ibm.com.txt.





 ibmcloud sl dns record-add 

Add resource record in a zone:

ibmcloud sl dns record-add ZONE RECORD TYPE DATA [OPTIONS]

Command options:

--ttl
: TTL(Time-To-Live) in seconds, such as: 86400. The default is: 7200.

Examples:

ibmcloud sl dns record-add ibm.com ftp A 127.0.0.1 --ttl 86400

This command adds an A record to zone: ibm.com, its host is "ftp", data is "127.0.0.1" and ttl is 86400 seconds.





 ibmcloud sl dns record-edit 

Update resource records in a zone:

ibmcloud sl dns record-edit ZONE [OPTIONS]

Command options:

--by-record
: Edit by host record, such as www.

--by-id
: Edit a single record by its ID.

--data
: Record data, such as an IP address.

--ttl
: TTL(Time-To-Live) in seconds, such as: 86400.

Examples:

ibmcloud sl dns record-edit ibm.com --by-id 12345678 --data 127.0.0.2 --ttl 3600
* Proxy and non-proxy options for load balancing
* Origin pools and health checks





 Global anycast network 

The available health check regions are based on the [Cloudflare Global Anycast Network](https://www.cloudflare.com/network/).







 DNS features 

DNS within CIS has the following features:



* DNS management - Manage your DNS records, control proxying, and enable DNS security.
* DNSSEC - DNS security cryptographically signs a zone to ensure that the DNS records provided to the user are the same as the DNS records published on the DNS server.







 gRPC protocol support 

The gRPC protocol builds efficient APIs with smaller payloads, which reduces bandwidth requirements, decreases latency, and increases the implementation time. CIS supports gRPC protocol for any proxied gRPC endpoints. To enable or disable gRPC support, navigate to the Reliability section, select the Advanced tab, and toggle the gRPC switch.

The following requirements must be met before you use gRPC:



* The gRPC endpoint must listen on port 443
* The gRPC endpoint must support TLS and HTTP/2
* HTTP/2 must be advertised over Application-Layer Protocol Negotiation (ALPN)
* The content-type header of gRPC requests must use application/grpc or application/grpc+<message type>









 Performance features 

Zoom

![performance graphic](https://cloud.ibm.com/docs-content/v1/content/cb1eb27836421578019401fa7556779109430b29/cis/images/performance-graphic.png)

Figure 3. Performance features



 Caching 

Control how CIS manages your cached assets.





 Page rules 

Fine-tune your cache behavior and create content optimization.





 Routing 

Eliminate excess latency by analyzing and optimizing routing decisions across the global internet using real-time network connections.





 Advanced performance 

Apply Brotli compression and restrict upload sizes in the advanced performance section.
For private zones, since the authority is within IBM Cloud, records are fetched using secure protocols, and are guaranteed to have the same level of privacy and security that DNSSec provides for public zones.





 Is DNS Services regional or global? 

DNS Services is a global service and can be used from permitted networks in any IBM Cloud region.





 When creating a DNS zone, what is the purpose of the Label field? 

A given instance can have multiple DNS zones with the same name. The label helps to differentiate zones with name collisions.





 How many private zones are supported? 

DNS Services supports 10 private zones per service instance.





 How many permitted networks are supported? 

DNS Services supports 10 permitted networks per DNS zone.





 How many DNS records are supported? 

DNS Services supports 3500 DNS records per DNS zone.





 How do I delete my DNS Services instance? 

To delete a DNS Services instance,



* Navigate to the Resource List in the [IBM Cloud console](https://cloud.ibm.com/).
* Click the "overflow" menu ![overflow menu icon](https://cloud.ibm.com/docs-content/v1/content/d56dbd8ab7d14086029681ee71679e14aea53723/icons/actions-icon-vertical.svg) in the final column and select "Delete".







 Why can't I delete a DNS Services instance? 

If a DNS zone has been added to the DNS Services instance, the instance cannot be deleted.





 Why can't I delete a DNS zone? 

If a network has been added to a zone, the zone cannot be deleted until the permitted network is deleted from the zone.





 What happens if I delete my VPC? 

If the VPC is deleted, the corresponding permitted network will also be deleted from the DNS zones of your instance.





 Why can I still resolve my resource records after I deleted its associated zone or permitted network? 

To maintain a level of performance while resolving DNS queries, DNS Services resolvers cache data related to permitted networks for a period of time.
"ttl": 60,
"name": "100.10.168.192.in-addr.arpa",
"id": "PTR:a47dd63a-e65a-4280-8f53-3cdb433cc78a",
"rdata": {
"ptrdname": "www1.example.com"
}
}







 Creating type 'CNAME' resource record 



 Request 

curl -X POST $DNSSVCS_ENDPOINT/v1/instances/$INSTANCE_ID/dnszones/$DNSZONE_ID/resource_records -H "Authorization: $TOKEN" -d '{
"type": "CNAME",
"name": "cname.example.com",
"rdata": {
"cname": "clientinterface.com"
}
}'





 Response 

{
"created_on": "2019-08-16 08:29:36.710416 +0000 UTC",
"modified_on": "2019-08-16 08:29:36.710416 +0000 UTC",
"rtype": "CNAME",
"ttl": 60,
"name": "cname.example.com",
"id": "CNAME:c95916ba-5504-499a-943a-21f5befe92b5",
"rdata": {
"cname": "clientinterface.com"
}
}







 Creating type 'AAAA' resource record 



 Request 

curl -X POST $DNSSVCS_ENDPOINT/v1/instances/$INSTANCE_ID/dnszones/$DNSZONE_ID/resource_records -H "Authorization: $TOKEN" -d '{
"type": "AAAA",
"name": "test.example.com",
"rdata": {
"ip": "8000::2000"
}
}'
Why did I get an NXDOMAIN error on name resolution? 

You tried to perform a domain name resolution, but it didn't work. Your response can vary depending on whether the domain name resolution is the first query attempt, or across multiple query attempts.



 NXDOMAIN error on the first query 

 What’s happening 

You tried to perform a domain name resolution for the first time, but you receive an NXDOMAIN error.

 Why it’s happening 

NXDDOMAIN errors happen when a request to resolve a domain is sent to the DNS and the request can't be resolved to an IP address. An NXDOMAIN error message means that the domain does not exist.

 How to fix it 



* Verify DNS Services is configured correctly and that access to 161.26.0.7 and 161.26.0.8 is available from within the virtual server instance by using the following dig command: $ dig @161.26.0.7 yourzone.com.
* Verify the server that you are sending the request from is configured to use one of these DNS resolvers: 161.26.0.7 or 161.26.0.8.
* Verify the server that you are sending the request from is part of a VPC that has been added as a permitted network to the DNS zone.
* Verify the FQDN for which name resolution is attempted has a resource record in the DNS zone.
* Verify that the DNS request is using the correct resource record type in the query.







 NXDOMAIN error across multiple query attempts for the same name with custom resolver 

 What’s happening 

You tried to perform a domain name resolution multiple times for a given name using a custom resolver, but none of the attempts worked.



* You received an NXDOMAIN error across multiple domain name resolution attempts.
* The error persists for many minutes, but less than an hour.
* The first attempt at DNS resolution takes the longest, typically. Most attempts for the same query after the first one take less time to resolve.



 Why it’s happening 

For example, an application in your VPC had attempted a domain name resolution to your custom resolver.
instance is.instance.network-interface_floating-ip.detach Floating IP was disassociated from instance network interface 
 instance is.instance.volume-attachment.create Instance volume attachment was created 
 instance is.instance.volume-attachment.delete Instance volume attachment was deleted 
 instance is.instance.volume-attachment.update Instance volume attachment was updated 
 instance is.instance.volume-attachment.read One or more instance volume attachments was retrieved 
 instance is.instance.network-interface.create <br><br> * Instance network interface was created (Instance was attached to a subnet)<br> * Includes the state of the allow_ip_spoofing parameter, which disables source/destination checks for network interfaces that are created on the virtual server. When set to false, IP spoofing is not allowed on the interface.<br><br><br> 
 instance is.instance.network-interface.update <br><br> * Instance network interface was updated (Instance was attached to a subnet)<br> * Includes the state of the allow_ip_spoofing parameter, which disables source/destination checks for network interfaces that are created on the virtual server. When set to false, IP spoofing is not allowed on the interface.<br><br><br> 
 instance is.instance.network-interface.delete Instance network interface was deleted (Instance was detached from a subnet) 
 instance is.instance.network-interface.read One or more instance network interfaces was retrieved 
 instance is.instance.network-interface_floating-ip.read One or more floating IPs under an instance network interface was retrieved 
 instance is.instance.disk.read One or more instance storage disks was retrieved 
 instance is.instance.disk.update Instance storage disk name was updated 
 instance is.instance.disk.wipe Instance storage disk was wiped clean 
 instance is.instance.gpu.wipe Memory was wiped on the GPU for the Instance 







 Instance Metadata service events 

The instance metadata service events are undergoing changes and should not be used for automation. They are useful, however, for audit purposes.



Table 14. Actions that generate events for the Instance Metadata service

 Resource Action Description
Why did the deletion of the DV SAN certificate domain fail? It shows that the domain is still live on the network. 

If your CDN is configured with DV SAN certificate HTTPS, you must remove the DNS record that points your domain to the [IBM CNAME](https://cloud.ibm.com/docs/CDN?topic=CDN-next-steps-after-orderingibm-cname) before deleting your CDN. Otherwise, the deletion fails with the error message 'Delete CDN failed: the xxxxxx is still live on network, please remove the DNS record pointing to Akamai.'

If you already deleted the DNS record that points your domain to the [IBM CNAME](https://cloud.ibm.com/docs/CDN?topic=CDN-next-steps-after-orderingibm-cname) and you still get an error, wait 15 - 30 minutes for the DNS update to take effect.
* What is a Content Delivery Network (CDN)?

A Content Delivery Network (CDN) is a collection of Edge servers that are distributed through various parts of the country or the world. Their web content is served from an Edge server, which is located in the geographic area closest to the customer who requests the content. This technique lets the users receive the content with less delay than we might achieve by delivering the content from one centralized location. It delivers a better overall experience for your customers.
* How does a Content Delivery Network (CDN) work?

A CDN achieves its purpose by caching web content on Edge servers around the world. When a user requests web content, the content request is routed to the Edge server that is geographically closest to that user. By reducing the distance that the content must travel, the CDN offers optimized throughput, minimized latency, and increased performance.
* Where do I find cost estimates for CDN?

You can estimate the cost of a service using the cost estimator on the provisioning pages for CDN offerings.
* lockdowns: Lock access to URLs in this domain to only permitted addresses or address ranges.



-d, --domain
: DNS Domain ID. For ua-rules and lockdowns type rule, it is a required parameter.

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





 Examples 

Delete a firewall rule.

ibmcloud cis firewall-delete dc014906ccce4e7ea2e28be7df70d0d2 -t access-rules -i "cis-demo"
ibmcloud cis firewall-delete bc014906ccce4e7ea2e28be7df70d0d2 -t access-rules -d 31984fea73a15b45779fa0df4ef62f9b -i "cis-demo"
ibmcloud cis firewall-delete 4af47b1518be478aa2c8f024af1c0bad -t ua-rules -d 31984fea73a15b45779fa0df4ef62f9b -i "cis-demo"
ibmcloud cis firewall-delete e6106d7ec58e47ebb2fa053dedcd7dcb -t lockdown -d 31984fea73a15b45779fa0df4ef62f9b -i "cis-demo"









 Firewall rules 

Manipulate how firewall rules perform using the following firewall-rules commands:



 ibmcloud cis firewall-rules 

Retrieve a list of currently existing firewall-rules for a given DNS domain.

ibmcloud cis firewall-rules DNS_DOMAIN_ID [--page PAGE] [--per-page PER_PAGE] [-i, --instance INSTANCE] [ ! ! ! ! ! ! --output FORMAT
ibmcloud cis overview DNS_DOMAIN_ID -i, --instance INSTANCE] --output FORMAT] ! ! ! ! ! ! ! !
<-- <section "id="section-get-overview-options" "> --> Command options DNS_DOMAIN_ID: The ID of DNS domain. Required.-i, --instance: Instance name or ID. If not set, the context instance specified by ibmcloud cis instance-set INSTANCE will be used.--output: Specify output format, only JSON is supported.<-- </section "id="section-get-overview-options" "> --><-- <section "id="section-get-overview-examples" "> --> Examples Show the overview information for domain 31984fea73a15b45779fa0df4ef62f9b. ibmcloud cis overview 31984fea73a15b45779fa0df4ef62f9b -i "cis-demo"
<-- </section "id="section-get-overview-examples" "> --><-- </section "id="section-get-overview" "> --><-- </section "id="section-overview" "> --><-- <section "id="section-page-rule-cli-ref" "> --> Page rules Manipulate page rules by using the following pagerule commmands.<-- <section "id="section-page-rule-create" "> --> ibmcloud cis page-rule-create Create a page rule of the DNS domain. ibmcloud cis page-rule-create DNS_DOMAIN_ID (--json @JSON_FILE | JSON_STRING) -i, --instance INSTANCE] --output FORMAT]
Managing DNS zones 

DNS management by IBM Cloud® extends to DNS zones that might not be on the IBM Cloud network. Using the DNS Forward Zones page, you can add, edit, and delete DNS zones.

To get to the DNS Forward 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 > Forward Zones to open the DNS Forward Zones page.





 Add a DNS zone 

Follow these steps to add a DNS zone in the DNS Forward Zones page:



1. Select the Add DNS Zone tab.
2. Enter the domains and IPs (optional) in the Domains field.
3. Enter the default IP address in the Default IP field.
4. Click the Add Zone button to add the DNS zone.



After you added the DNS zone, you can [add records](https://cloud.ibm.com/docs/dns?topic=dns-manage-dns-zone-recordsadd-a-dns-zone-record) to the zone.





 Edit a DNS zone 

Select the DNS zone you want to edit from the list of zones in the DNS Forward Zones page by clicking on the name of the zone. This opens the DNS Edit Zone page. From here, you can make changes to the DNS zone, and click Update SOA to commit the changes.

The DNS Edit Zone page allows you to add new records and edit existing records for the zone. You can also export or delete the zone from this page.





 Delete a DNS zone 

After a DNS zone is added, it can be deleted at any time. DNS zone deletions are permanent; they cannot be undone.
(Optional) If block or file storage volumes were part of the original virtual server, create the new volumes and update the iSCSI or NFS configuration on the new virtual server. After created and attached, copy the data over from the old to new virtual server by using your tool of choice.
4. Update and add or modify any infrastructure resources, such as:



* Security groups
* Firewall rules
* Load balancers
* VPN
* DNS









 Final check 



1. After you complete the new virtual server verification and are ready to activate the new server, do one last sync of any data drift from the old to new virtual server.
2. Shut down the old server.
3. Create one last image template as a backup.
4. When ready, clean and cancel any unused resources at the old location.









 System rebuild method 

For this method, you're ordering a new virtual server and copying the data from the old to the new virtual server. Copying the data is handled at the OS level, by using scp, rsync, dd, or another third-party tool.



 Evaluate your virtual server 



1. Evaluate the virtual server that you want to migrate so see which services it is using, such as (not an exhaustive list):



* Auto scale group
* Placement group
* Security groups
* Firewall rules
* Load balancers



2. Make sure that similar services are created at the new data center.







 Order, provision, and configure the new virtual server 



1. Log in to the [IBM Cloud® console](https://cloud.ibm.com/classic?) by using your unique credentials.
2. Click the Virtual Server for Classic tile in the catalog.
3. Provision the new virtual server:



* Enter a hostname and domain
* (Optional) Select or create a placement group
* Select a location
* Select a virtual server profile
* (Recommended) Select an SSH key
* Add an extra attached storage disk, if necessary
* Select Uplink port speeds



4.
To add this record type, valid values must exist in the Name and IPv6 Address fields. A TTL also can be specified from the list menu, with the default value of Automatic.

Required Fields: Name, IPv6 Address Optional Field: TTL (default value is Automatic)





 CNAME Type record 

To add this record type, a valid value must exist in the Name field and a fully qualified domain name must be in the Domain Name (FQDN) field. A TTL also can be specified from the list menu, with the default value of Automatic.

Required Fields: Name, Domain Name (for CNAME) Optional Field: TTL (default value is Automatic)

Enterprise plans are able to CNAME another domain as long as that domain is configured within CIS.

Ex.
Configured CIS Domains:
- example.com
- different.com

test.example.com -CNAME-> test.different.com

The CNAME flattening feature is enabled by default, and cannot be turned off.

CIS does not support Cloudflare's CNAME setup. The only way to activate your domain in CIS is to delegate your NS Records management to CIS.





 MX Type record 

To add this record type, a valid value must exist in the Name field and a valid address must exist in the Mail Server field. A TTL also can be specified from the list menu, with the default value of Automatic.



* Required Fields: Name, Mail Server
* Optional Fields: TTL (default value is Automatic), Priority (default value is 1)







 LOC Type record 

To add this record type, a valid value must exist in the Name field. If you need more specific information, select the Configure LOC options button. A TTL also can be specified from the list menu, with the default value of Automatic.



* Required Fields: Name
* Optional Fields: LOC options (click Configure LOC options to configure)







 CAA Type record 

To add this record type, valid values must exist in the Name and Value fields. The Value field correlates to the value of the Tag list field, which defaults to "Send violation reports to URL".
In this case, select the type A.
5. Enter the required data for the type of DNS record you selected. In this case, for type A, enter Name and IPv4 Address.
6. Click Add record in the panel.







 Creating a permitted network 



1. Navigate to the Resource page and select your DNS Services instance. Then select your zone.
2. Click the Permitted Networks tab.
3. Click Add network.
4. In the Add Network panel, select the region of your VPC from the Network Region menu.
5. Select the VPC from the Network menu that appears.
6. Click Add network.

This request adds the VPC network to your zone, thereby giving the network access to the zone.







 Verifying the setup 

To verify that your instance, zone, and record are performing correctly, run the following dig command:

dig @161.26.0.7 <Record type> <record name>

Example:

dig @161.26.0.7 A xyz.example.com







 Using the API 



 Creating a DNS Services instance 

See the [create a new resource instance](https://cloud.ibm.com/apidocs/resource-controller/resource-controllercreate-provision-a-new-resource-instance) documentation for the Resource Controller API. Note that the resource_group and resource_plan_id must be set. Each account can have multiple resource groups, and each resource group has a unique ID.

Set the variables as follows to create an instance of the standard plan:

"resource_plan_id": "2c8fa097-d7c2-4df2-b53e-2efb7874cdf7",

See the [Resource Controller API reference](https://cloud.ibm.com/apidocs/resource-controller/resource-controller) documentation for more information on using the API.

Command lines for instances are using resource controller API, not DNS APIs.