vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.240.66.1 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 10.240.66.1 0.0.0.0 UG 100 0 0 eth0
10.240.66.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0
3. Delete any unnecessary gateways permanently from the system files. Old gateway route details can be found in the file /etc/sysconfig/network-scripts/route-eth0. See the following example.

 Created by cloud-init on instance boot automatically, do not edit.

ADDRESS0=10.0.0.0
GATEWAY0=10.187.149.65
NETMASK0=255.0.0.0
ADDRESS1=161.26.0.0
GATEWAY1=10.187.149.65
NETMASK1=255.255.0.0
ADDRESS2=166.8.0.0
GATEWAY2=10.187.149.65
NETMASK2=255.252.0.0

Delete the unnecessary gateway information so that the file looks similar to the following example.

 Created by cloud-init on instance boot automatically, do not edit.




3. Re-register the Red Hat Enterprise Linux operating system on your virtual server instance. At this time the Red Hat Enterprise Linux operating system is still in an unsubscribed state.



1. You can verify the unsubscribed state by running the following command. See the following example:

[root@skv-vsic1x7im ] subscription-manager list
You are attempting to use a locale that is not installed.
+-------------------------------------------+
Installed Product Status
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.



 Adding permitted networks 

A DNS zone's initial state is PENDING_NETWORK_ADD, because its permitted network list is empty when the DNS zone is created. When a permitted network is added to the DNS zone's permitted networks, the state changes to ACTIVE.



 Parameters 



* DNSZONE_ID: When you create a zone, the DNSZONE_ID is returned in the response as id.







 Request 

curl -X POST $DNSSVCS_ENDPOINT/v1/instances/$INSTANCE_ID/dnszones/$DNSZONE_ID/permitted_networks -H "Authorization: $TOKEN" -d '{
"type": "vpc",
"permitted_network":{
"vpc_crn":"crn:v1:staging:public:is:us-east:a/0821fa9f9ebcc7b7c9a0d6e9bf9442a4::vpc:b7246cdf-892a-4a6c-8fa9-491a5f585bd0"
}
}'





 Response 

{
"id": "b7246cdf-892a-4a6c-8fa9-491a5f585bd0",
"created_on": "2019-09-11 13:46:51.68793557 +0000 UTC",
"modified_on": "2019-09-11 13:46:51.68793557 +0000 UTC",
"permitted_network": {
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. Your custom resolver responded with an NXODMAIN response from an upstream DNS resolver and had cached that response. Then for subsequent queries, your custom resolver responded with that cached response. Because resolving from cache is faster, subsequent DNS queries that were resolved through the custom resolver's cache took less time. The TTL has a 30-minute maximum for the negative cache for the custom resolver, which is currently not a configuration parameter.

 How to fix it 

Avoid caching a negative DNS response in the resolver for that query before the period in which applications expect to intentionally make queries and get good responses. For example:



* Add the DNS resource record that is associated with the queried name before the applications make that first DNS query.
* Add the DNS resource record that is associated with the queried name, then wait until the negative cache entry on the custom resolver expires. Resume DNS queries, and maintain access to resource records for that DNS name.
The vCenter Server deployment uses the deployed AD VSIs or VMs as DNS servers for the instance. All deployed components (vCenter with embedded PSC, NSX, ESXi hosts) are configured to point to the AD as their default DNS. You can customize the DNS zone configuration if it does not interfere with the configuration of the deployed components.

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



* The domain structure is specified by the user.
* The domain name can be any number of levels up to the maximum that all vCenter Server components handle.
* The domain name must be at least three levels. This guideline enforces the best practice that the top-level domain delegates responsibility to the instance for the instance domain.
* The AD/DNS servers are configured to be authoritative for the DNS domain.
* The AD/DNS servers are configured to point to the IBM Cloud DNS servers for all other zones.
* Any secondary cloud regions that are integrated to the first cloud region or target deployed cloud region must use the same DNS name structure with unique host prefixes.
* Optionally, you can deploy redundant DNS servers within the vCenter Server cluster. Two AD/DNS servers are configured unlicensed. It is your responsibility to provide licenses for the Windows operating systems for these servers.
* If a single site is provisioned with only one AD/DNS server, then all configured vCenter Server components must have only that single IP address as a DNS entry.







 Secondary vCenter Server instances 

For cross instance redundancy, when the first secondary vCenter Server instance is added to an existing primary or stand-alone vCenter Server instance, that primary instance AD DNS server IP address is used in the secondary vCenter Server instance and in any subsequent secondary vCenter Server instance “secondary DNS” entry for all components that require a DNS server entry.

For example, ESXi, vCenter, and NSX Manager, and also add-on components, such as, HCX, Zerto, and Veeam. The primary site secondary DNS entry is then changed to the first secondary vCenter Server instances AD/DNS IP address.







 NTP services 

This design uses the IBM Cloud infrastructure NTP 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.
* When will the IBM ResellOne End of Service take effect?

 When will the IBM ResellOne End of Service take effect? 

End of Service takes effect on 1 November 2021. For more information, see the [End of Service announcement](https://cloud.ibm.com/docs/dns?topic=dns-resellone-eos).
* What are the benefits of migrating to Hover?

 What are the benefits of migrating to Hover? 

As a Hover customer, you’ll benefit from a clean and intuitive domain management control panel. You'll also get an expanded selection of premium top-level domains, and great customer support.
* What are the benefits of migrating to OpenSRS?

 What are the benefits of migrating to OpenSRS?
Where <dns> is the domain name, <namespace> is the namespace, <repo> is the repository, and <digest> is the digest of the chart that you want to restore.

ibmcloud cr image-restore <dns>/<namespace>/<repo>@<digest>

If some tags aren't restored, see [Why aren't all the tags restored when I restore by digest](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-image-restore-digest).

In your live repository, you can pull the chart by digest. If you run the [ibmcloud cr image-digests](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_digests) command, the chart shows in the output.







 Restoring charts by tag 

When you restore a chart by tag, only that specific tag is moved out of the trash into your live repository.

To restore a chart by tag from the trash, complete the following steps.



1. Log in to IBM Cloud by running the ibmcloud login command.
2. List the charts in the trash by running the following command.

ibmcloud cr trash-list

A table is displayed that shows the items in the trash. The table shows the digest, the days until expiry, and the tags for that digest.
3. For the chart that you want to restore, make a note of the digest up to, but not including, the at sign (@). This part of the digest is <dns>/<namespace>/<repo>, where <dns> is the domain name, <namespace> is the namespace, and <repo> is the repository.
4. For the chart that you want to restore, make a note of the tag, <tag>.
5. Run the following command to restore the chart to your repository, where <dns>/<namespace>/<repo> is the name of the chart that you want to restore and <tag> is the tag.
[DNS Layout](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/vpc-transit/vpc-transit-dns.svg)

DNS Layout



 DNS Resources 



1. Apply the dns_tf layer to create the DNS services and add a DNS zone for each VPC and an A record for each of the test instances:

./apply.sh dns_tf
2. Open the [Resource list](https://cloud.ibm.com/resources) in the IBM Cloud console.
3. Expand the Networking section and notice the DNS Services.
4. Locate and click to open the instance with the suffix spoke0.
5. Click on the DNS zone with the suffix spoke0.com. Notice the A records associated with the test instances that are in the spoke instance.
6. Click on the Custom resolver tab on the left and click on the resolver with the suffix spoke0.com.
7. Click on the Forwarding rules tab and notice the forwarding rules.

Separate DNS instances learn each other's DNS names with forwarding rules. In the diagram there are arrows that indicate a forwarding rule. The associated table are a list of zones that could be resolved by the forwarding rule. Starting on the left notice that the enterprise DNS forwarding rule will look to the transit for the DNS zones: x-transit.com, x-spoke0.com, and x-spoke1.com. The transit DNS instance can resolve x-transit.com and has its own forwarding rules to the enterprise and spokes to resolve the rest. Similarly the spokes rely on the transit DNS instance to resolve the enterprise, transit and the other spokes.
8. Optionally explore the other DNS instances and find similarly named DNS zones and A records for the other test instances.







 DNS Testing 

There is a set of curl DNS tests that are available in the pytest script.
Getting resource record 'A:f20cfe91-b936-4bad-a8d1-f7afa4ac32a6' in zone 'example.com:f7f40364-a5e6-48f7-9fc9-387434c579ae' for service instance 'DNS Services-km' ...
OK

ID A:f20cfe91-b936-4bad-a8d1-f7afa4ac32a6
Name www.example.com
Type A
Created On 2020-04-10 09:12:07.858707275 +0000 UTC
Modified On 2020-04-10 09:34:49.986883927 +0000 UTC
TTL 900
Data
ip 192.168.1.100





 Listing resource records 

Use ibmcloud dns resource-records command followed by the zone ID to list all resource records.

$ ibmcloud dns resource-records $DNS_ZONE_ID
Listing resource records in zone 'example.com:f7f40364-a5e6-48f7-9fc9-387434c579ae' for service instance 'DNS Services-km' ...
OK
ID Name Type TTL
AAAA:37e1e701-e549-4ca1-8c22-86574bf4aaed www.example.com AAAA 900
CNAME:6e80f079-effd-409a-a520-b8c1b10f6e6e web.example.com CNAME 900
MX:900750bf-881d-402f-a482-20447f2e64a2 mail.example.com MX 900
TXT:92648285-c7e5-49ef-bf8b-a5be91d5c5d3 text.example.com TXT 900
* UI
* CLI
* API







 Deleting custom resolver forwarding rules 

You can delete custom resolver forwarding rules in IBM Cloud® DNS Services by using the UI, CLI, or API.



 Deleting custom resolver forwarding rules using the UI 

To delete a forwarding rule:



1. Navigate to the custom resolver details page and select the Forwarding rules tab.
2. Click the overflow menu next to the rule that you want to delete.
3. Select Delete.

You cannot delete the default rule.







 Deleting custom resolver forwarding rules using the CLI 

To delete a custom resolver forwarding rule using the CLI, run the following command:

ibmcloud dns custom-resolver-forwarding-rule-delete RESOLVER_ID RULE_ID [-i, --instance INSTANCE] [-f, --force]

Where:



* RESOLVER_ID is the ID of custom resolver.
* RULE_ID is the ID of custom resolver forwarding rule.
* -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.
* -f, --force deletes the custom resolver forwarding rule without prompting for confirmation.







 Deleting custom resolver forwarding rules using the API 

To delete a custom resolver forwarding rule 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.
* resolver_id, which is the unique identifier of a custom resolver.
* rule_id, which is the unique identifier of a forwarding rule.
* X-Correlation-ID, which is a string that uniquely identifies a request.



3. When all variables are initiated, delete your custom resolver forwarding rule:
From the Actions menu, select Load from image.
3. Select the image template checkbox to for the image template to load on to the device.

Before the reload completes, the image template is copied to the data center that contains the device, if it is not already located in the same data center. If the image template must be copied to the data center, a fee might be charged if the template is not deleted from the location after the OS Reload occurs.
4. Determine whether you want to add any features. Any features that you select are added to the device as part of the reload process.



Table 1. Optional features

 Optional features Steps 

 Yes, I want to add optional features. i. Click Load selected image. <br>ii. Review the Image Configuration and proceed or cancel. <br>iii. Click Confirm OS Reload to confirm the action and begin the OS reload process. 
 No, I do not want to add optional features. Click View optional features. 



5. Configure options, as relevant. Refer to the following information for more details.

Post install script Adds an existing or new postinstallation script.

SSH key Adds an SSH key to the device upon the reload action.

Reset IPMI password This option is only available for physical devices.

Apply system board BIOS upgrades This option is only available for physical devices.

Apply firmware updates for all hard disks This option is only available for physical devices.

Add to spare spool after OS reload This option is available only on physical devices and requires internal approval before its available on an account.

Erase all hard disks This option is available only on physical devices and requires special user permissions set by the account administrator.

OS reload with disk preservation This option configures your current primary disk as a secondary disk (retaining all data), and creates a new primary disk. The OS is installed on the new primary disk. Retains all data on the current primary disk during the OS Reload process. Retains all data on the current primary disk during the OS Reload process. Disk preservation converts the primary drive to a Portable Storage device.
ibmcloud cis waf-packages DNS_DOMAIN_ID -i, --instance INSTANCE] --output FORMAT] ! ! ! ! ! !
<-- <section "id="section-list-waf-packages-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 is used.--output: Specify output format, only JSON is supported.<-- </section "id="section-list-waf-packages-options" "> --><-- <section "id="section-list-waf-packages-examples" "> --> Examples List all WAF packages for domain 372e67954025e0ba6aaa6d586b9e0b60. ibmcloud cis waf-packages 31984fea73a15b45779fa0df4ef62f9b -i "cis-demo"
<-- </section "id="section-list-waf-packages-examples" "> --><-- </section "id="section-list-waf-packages" "> --><-- <section "id="section-show-waf-package" "> --> ibmcloud cis waf-package Get detail of a WAF package. ibmcloud cis waf-package DNS_DOMAIN_ID WAF_PACKAGE_ID -i, --instance INSTANCE] --output FORMAT] ! ! ! ! ! !
<-- <section "id="section-show-waf-package-options" "> --> Command options DNS_DOMAIN_ID: The ID of DNS domain. Required.WAF_PACKAGE_ID: The ID of WAF package. Required.-i, --instance: Instance name or ID.
If not set, the context instance specified by dns instance-target INSTANCE is used.

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





 Examples 

Update location 9a234ede-c2b6-4c39-bc27-d39ec139ecdb in custom resolver f1aba936b94213e5b8dca0c0dbf1f9cc for instance dns-demo.

ibmcloud dns custom-resolver-location-update f1aba936b94213e5b8dca0c0dbf1f9cc 9a234ede-c2b6-4c39-bc27-d39ec139ecdb --subnet crn:v1:bluemix:public:is:us-south-1:a/01652b251c3ae2787110a995d8db0135::subnet:0716-b49ef064-0f89-4fb1-8212-135b12568f04 --enabled true -i "dns-demo"







 ibmcloud dns custom-resolver-location-delete 

Delete custom resolver location for a service instance.

ibmcloud dns custom-resolver-location-delete RESOLVER_ID LOCATION_ID [-i, --instance INSTANCE] [-f, --force]



 Command options 

RESOLVER_ID
: The ID of custom resolver.

LOCATION_ID
: The ID of custom resolver location.

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

---f, --force
: Delete custom resolver location without prompting for confirmation.





 Examples 

Delete location 9a234ede-c2b6-4c39-bc27-d39ec139ecdb in custom resolver f1aba936b94213e5b8dca0c0dbf1f9cc for instance dns-demo.
* UI
* CLI
* API







 Deleting custom resolver locations 

You can delete custom resolver locations in IBM Cloud® DNS Services by using the UI, CLI, or API.



 Deleting a resolver location using the UI 

To delete a resolver location by using the UI, follow these steps:



1. Select a custom resolver to open the details page.
2. Select the Resolver locations tab, if not selected already.
3. Click the overflow menu icon for the location that you want to delete.
4. Select Delete.







 Deleting a resolver location 

To delete a resolver location using the CLI, run the following command:

ibmcloud dns custom-resolver-location-delete RESOLVER_ID LOCATION_ID [-i, --instance INSTANCE] [-f, --force]

Where:



* RESOLVER_ID is the ID of custom resolver.
* LOCATION_ID is the ID of the custom resolver location.
* -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.
* -f, --force deletes the resolver location without prompting for confirmation.







 Deleting a resolver location using the API 

To delete a custom resolver location 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.
* resolver_id, which is the unique identifier of a custom resolver.
* location_id, which is the custom resolver location ID.
* X-Correlation-ID, which is a string that uniquely identifies a request.



3. When all variables are initiated, get the details of your custom resolver:
ibmcloud cis glb DNS_DOMAIN_ID GLB_ID -i, --instance INSTANCE] --output FORMAT] ! ! ! ! ! !
<-- <section "id="section-show-glb-options" "> --> Command options DNS_DOMAIN_ID: The ID of DNS domain. Required.GLB_ID: The ID of global load balancer. Required.-i, --instance: Instance name or ID. If not set, the context instance specified by ibmcloud cis instance-set INSTANCE is used.--output: Specify output format, only JSON is supported.<-- </section "id="section-show-glb-options" "> --><-- <section "id="section-show-glb-examples" "> --> Examples Show global load balancer 699d98642c564d2e855e9661899b7252 in domain 31984fea73a15b45779fa0df4ef62f9b. ibmcloud cis glb 31984fea73a15b45779fa0df4ef62f9b 699d98642c564d2e855e9661899b7252 -i "cis-demo"
<-- </section "id="section-show-glb-examples" "> --><-- </section "id="section-show-glb" "> --><-- <section "id="section-delete-glb" "> --> ibmcloud cis glb-delete Delete a global load balancer under a given DNS domain. ibmcloud cis glb-delete DNS_DOMAIN_ID GLB_ID -i, --instance INSTANCE] ! ! ! ! ! !
<-- <section "id="section-delete-glb-options" "> --> Command options DNS_DOMAIN_ID: The ID of DNS domain.
"rdata": {
"ip": "1.2.6.7"
}
}







 Creating type 'SRV' resource record 



 Request 

curl -X POST $DNSSVCS_ENDPOINT/v1/instances/$INSTANCE_ID/dnszones/$DNSZONE_ID/resource_records -H "Authorization: $TOKEN" -d '{
"type": "SRV",
"name": "example.com",
"service": "srv",
"protocol": "udp",
"rdata": {
"priority": 100,
"weight": 100,
"port": 8000,
"target": "siphost.com"
}
}'





 Response 

{
"created_on": "2019-08-16 08:07:41.113606 +0000 UTC",
"modified_on": "2019-08-16 08:07:41.113606 +0000 UTC",
"rtype": "SRV",
"ttl": 60,
"name": "example.com",
"id": "SRV:7562b1f9-1a6a-4189-b794-dd84c91d6a28",
"rdata": {
"priority": 100,
"weight": 100,
"port": 8000,
"target": "siphost.com"
},
"service": "srv",
"protocol": "udp"
}







 Creating type 'TXT' resource record 



 Request 

curl -X POST $DNSSVCS_ENDPOINT/v1/instances/$INSTANCE_ID/dnszones/$DNSZONE_ID/resource_records -H "Authorization: $TOKEN" -d '{
"type": "TXT",
"name": "txt.example.com",
"rdata": {
The following table lists the actions that are related to permitted networks and generate an event.



Table 3. Permitted networks

 Action Description 

 dns-svcs.permitted-networks.read Get or list permitted networks from DNS zone. 
 dns-svcs.permitted-networks.create Add a permitted network to DNS zone. 
 dns-svcs.permitted-networks.delete Remove a permitted network from DNS zone. 







 Global balancer events 

The following table lists the actions that are related to global load balancers and generate an event.



Table 4. Global load balancers

 Action Description 

 dns-svcs.monitors.read Get or list health monitors. 
 dns-svcs.monitors.create Create a health monitor. 
 dns-svcs.monitors.update Update a health monitor. 
 dns-svcs.monitors.delete Delete a health monitor. 
 dns-svcs.pools.read Get or list origin pools. 
 dns-svcs.pools.create Create an origin pool. 
 dns-svcs.pools.update Update an origin pool. 
 dns-svcs.pools.delete Delete an origin pool. 
 dns-svcs.load-balancers.read Get or list load balancers. 
 dns-svcs.load-balancers.create Create a load balancer. 
 dns-svcs.load-balancers.update Update a load balancer. 
 dns-svcs.load-balancers.delete Delete a load balancer. 







 Custom resolvers 

The following table lists the actions that are related to custom resolvers and generate an event.



Table 5. Custom resolvers

 Action Description 

 dns-svcs.custom-resolvers.read Get or list custom resolvers. 
 dns-svcs.custom-resolvers.create Create a custom resolver. 
 dns-svcs.custom-resolvers.update Update a custom resolver. 
 dns-svcs.custom-resolvers.delete Delete a custom resolver. 
 dns-svcs.locations.create Add a custom resolver location.