vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* If I use the SAN certificate type for my CDN, can I still use the CNAME for access to my service?

No. For the SAN certificate, you can use only the custom domain to access the content from the origin.
* Are all of my IBM Cloud CDN domains added into one certificate?

Not necessarily. Certificate selection is handled by Akamai to ensure that the certificates are in the most efficient state. Domains are added into different certificates in a well-proportioned manner, so we cannot guarantee that all of your domains are on the same certificate.
* Why do I see "wildcard" when I perform a dig or when I try to access content when my CDN is in Requesting Certificate, Domain Validation pending or Deploying Certificate status?

During the DV SAN certificate requesting process, the DNS record chain for your CDN is chained to a wildcard certificate, temporarily. Until the process is complete, content temporarily is served through this wildcard certificate. Once the requesting process is complete, the DNS record chain is updated to chain to your CDN's DV SAN certificate.
* Is HTTP2 protocol supported for HTTPS requests?

CDNs created with HTTPS protocol support HTTP2 for TLS secured traffic.
* Why is the newly created wildcard CDN status CNAME configuration required if we don't need to set the DNS record to point the domain to IBM CNAME?

For the wildcard CDN, you don't need to set the DNS record to point the domain to IBM CNAME. As you create the CDN, the system creates a new DNS record to point the IBM CNAME (xxx.cdn.appdomain.cloud.) to Akamai endpoint (wildcard.appdomain.mdc.edgekey.net.), and it needs some time to finish the record propagation. The CDN status is shown as CNAME configuration required until the record is propagated. After the propagation is done, refresh the mapping status by clicking the Get status button. The CDN status then changes to Running.
* I received an error similar to "Could not allocate more resource to build new rule in Akamai: x behaviors are needed while only x can be used." What should I do?
Getting started with IBM Cloud DNS Services 

IBM Cloud® DNS Services provides private DNS to Virtual Private Cloud (VPC) users. Private DNS zones are resolvable only on IBM Cloud, and only from explicitly [permitted networks](https://cloud.ibm.com/docs/dns-svcs?topic=dns-svcs-dns-conceptspermitted-networks) in an account. To get started, create a DNS Services instance using the IBM Cloud console.



 Before you begin 

To use DNS Services, you must have at least one virtual server instance in a VPC in the IBM Cloud. If you do not have one, learn how to [get started with Virtual Private Cloud](https://cloud.ibm.com/docs/vpc?topic=vpc-getting-started).

While the private DNS resolvers are required to resolve private DNS names, they also resolve public DNS names if the request is for a name that is not defined to be in a private DNS zone.





 Step 1: Create a DNS Services instance 



1. Open the IBM Cloud catalog page and select Networking.
2. Click the DNS Services tile.
3. In the Create tab, select a pricing plan and optionally update the default the service name and resource group.
4. Click Create.







 Step 2: Add a DNS zone 



1. From the resource page, select the DNS Services instance.
2. Click the Create zone button on the DNS Zones page.
3. Enter a fully qualified domain name for the zone and optionally add a label and description. The domain name can have a maximum of 5 levels. You can define subdomains within the zone later.
4. Click Create zone.
5. If the zone creation is successful, you are directed to the zone details page.







 Step 3: Add DNS resource records 



1. Select the zone from the table on the DNS Zones page.
2. Select the DNS records tab.
3. Click Add record.
4.
When using other methods, you would receive an [email alert](https://cloud.ibm.com/docs/CDN?topic=CDN-faq-for-httpsi-received-an-email-indicating-that-my-domain-is-not-pointed-to-IBM-CDN-CNAME) after you migrate to others.

--------------------





 Standard 

If you choose the Standard method for domain validation, the Domain Validation window shows a Challenge URL and a Challenge response. To complete the domain validation process, add the provided Challenge response to your origin server. After it is added, the CA can retrieve the Challenge response from your origin server using the URL specified in the Challenge URL. After your origin server is configured correctly, domain validation can take 2 - 4 hours.

To successfully complete the domain validation through the Standard method, you must configure your origin server in a particular way. The example procedures for Apache and Nginx servers are outlined here.

Example situation:



* Origin server: origin.example.com
* CDN domain: cdn.example.com
* Challenge URL: http://cdn.example.com/.well-known/acme-challenge/examplechallenge-fileobject
* Challenge Response: examplechallenge





 Configuring Apache 

To configure Apache, follow these steps:



1. Log in to the machine running the Apache2 server.
2. Create the challenge response file for the challenge response under .well-known/acme-challenge/ in the directory for your website content. The default location for Apache2 website content is /var/www/html/. For this example, the challenge response is placed in the /var/www/html/.well-known/acme-challenge/ directory.

mkdir -p /var/www/html/.well-known/acme-challenge && printf "examplechallenge" > /var/www/html/.well-known/acme-challenge/examplechallenge-fileobject
3.
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-order-dedicated-cert-options" "> --><-- <section "id="section-order-dedicated-cert-examples" "> --> Examples Order a certificate pack for domain 31984fea73a15b45779fa0df4ef62f9b. ibmcloud cis certificate-order 31984fea73a15b45779fa0df4ef62f9b --hostnames www.example.com --hostnames api.example.com -i "cis-demo"
<-- </section "id="section-order-dedicated-cert-examples" "> --><-- </section "id="section-order-dedicated-cert" "> --><-- <section "id="section-upload-cert" "> --> ibmcloud cis certificate-upload Upload a custom certificate for a DNS domain. ibmcloud cis certificate-upload DNS_DOMAIN_ID (--json @JSON_FILE | JSON_STRING) -i, --instance INSTANCE] --output FORMAT]
Deprecated] ibmcloud cis certificate-upload DNS_DOMAIN_ID (-s, --json-str JSON_STR | -j, --json-file JSON_FILE) -i, --instance INSTANCE] --output FORMAT] ! !!!!!! ! ! ! ! !
<-- <section "id="section-upload-cert-options" "> --> Command options DNS_DOMAIN_ID: The ID of DNS domain. Required.--json: The JSON file or JSON string used to describe a custom certificate. Required.
<-- <ul> -->

* The required fields in JSON data are certificate, private_key:
Working with custom resolvers 

A private DNS custom resolver extends IBM Cloud® DNS Services's capability to meet the needs of a hybrid cloud environment by enabling resolution of the IBM Cloud VPC hostnames from on-premises DNS resolvers, and also enables the resolution of on-premises hostnames from the IBM Cloud.

Key features of the custom resolver:



* Extends DNS resolutions to resolvers residing on-premises
* Allows for resolution fallback to a secondary resolver location (if one is configured) when the primary resolver location is not available





 Custom resolver overview 

To get started using a custom resolver, you must create a custom resolver and then add forwarding rules to it.

It is expected that the custom resolver will be configured for High Availability by default. Follow the steps in [Creating a custom resolver without high availability](https://cloud.ibm.com/docs/dns-svcs?topic=dns-svcs-ui-create-cr&interface=uicr-add-no-ha) if you do not want a highly available configuration.

After you create the custom resolver and configure its forwarding rules, the resolver can be enabled for the VPC. This results in the DHCP option for the resolver changing to the custom resolver IP addresses.





 Reserved IP for custom resolvers 

Virtual appliances are created for custom resolvers to serve DNS queries, or for [global load balancer health checks](https://cloud.ibm.com/docs/dns-svcs?topic=dns-svcs-global-load-balancersadd-a-health-check) to send probes to your origin servers that monitor their health status. The virtual appliance is fully managed by DNS Services, however, you can go to the Subnets for VPC dashboard and view the details of a subnet to see the reserved IPs of that subnet. You can see which IP address is bound to the network interface on the virtual appliance managed by DNS Services.

Zoom

!
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-authenticated-origin-pull-settings-options" "> --><-- <section "id="section-show-authenticated-origin-pull-settings-examples" "> --> Examples List authenticated origin pull settings on zone level for domain 31984fea73a15b45779fa0df4ef62f9b. ibmcloud cis authenticated-origin-pull-settings 31984fea73a15b45779fa0df4ef62f9b -i "cis-demo"
<-- </section "id="section-show-authenticated-origin-pull-settings-examples" "> --><-- </section "id="section-show-authenticated-origin-pull-settings" "> --><-- <section "id="section-update-authenticated-origin-pull-setting" "> --> ibmcloud cis authenticated-origin-pull-setting-update Update authenticated origin pull settings for a domain. ibmcloud cis authenticated-origin-pull-settings-update DNS_DOMAIN_ID --level zone|hostname] --hostname HOSTNAME] --cert_id CERT_ID] (--enabled on|off) -i, --instance INSTANCE] --output FORMAT] ! ! ! ! ! !
<-- <section "id="section-update-authenticated-origin-pull-settings-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".--hostname: The authenticated origin pull settings on a hostname.
: The matching zone or hostname.

--dns-svcs
: The upstream DNS servers will be forwarded to, for example: ip1,ip2

-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 a forwarding rule 9a234ede-c2b6-4c39-bc27-d39ec139ecdb in custom resolver f1aba936b94213e5b8dca0c0dbf1f9cc for instance dns-demo.

ibmcloud dns custom-resolver-forwarding-rule-update f1aba936b94213e5b8dca0c0dbf1f9cc 9a234ede-c2b6-4c39-bc27-d39ec139ecdb --type zone --match "example.com" --dns-svcs 192.168.0.1,192.168.0.2 --description "demo" -i "dns-demo"







 ibmcloud dns custom-resolver-forwarding-rule 

Get a custom resolver forwarding rule details for a service instance.

ibmcloud dns custom-resolver-forwarding-rule RESOLVER_ID RULE_ID [-i, --instance INSTANCE] [--output FORMAT]



 Command options 

RESOLVER_ID
: The ID of custom resolver.

RULE_ID
: The ID of custom resolver forwarding rule.

-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
Domain Name System configuration 

The vCenter Server instance design integrates DNS services on the AD domain controllers:



* The domain structure is specified during the instance order process.
* The domain controllers are configured to be authoritative for the DNS domain.
* The domain controllers servers are configured to point to the IBM Cloud DNS servers for all other zones.
* Any secondary vCenter Server instances that are integrated to the primary instance use the same DNS name structure.



When a secondary vCenter Server instance is linked to the primary instance, the vCenter Server instance appliances are configured:



* DNS is configured with the primary instances AD DNS server IP address.
* Secondary DNS is configured with the secondary instances AD DNS server IP address.



AD DS DNS is configured with a forward lookup zone with the name of <root_domain>, and populated with the following host (A) records:



* clouddriver
* <instance_name>-vc
* <instance_name>-nsx
* Add-on services when ordered. For example, HCX, Caveonix RiskForesight, Veeam, or Zerto, with instance-specific names



Reverse lookup zones with the start of authority (SOA), name server (NS), and the required pointer (PTR) records for the appliances are configured in the following subnets:



* Management subnet
* Internal-mgmt subnet
* Add-on services subnets. For example, HCX subnet, risk foresight subnet.



The forwarder section is configured with:



* 10.0.80.12
* 10.0.80.11



Forwarders are DNS servers that the AD DNS server can use to resolve DNS queries for records that the AD server cannot resolve. 10.0.80.12 and 10.0.80.11 are the two addresses for IBM Cloud Resolving Name Servers. Resolving name servers are located on the private network and act as DNS resolvers. The private resolvers query the Internet root name servers for domain lookups and resolve this information over the private network to keep your bandwidth usage down, reduce the load on the authoritative servers, and offer quick resolution.
2. Use the cbr-zone-create command to add network locations and VPCs to network zones. For more information, see the CBR [CLI reference](https://cloud.ibm.com/docs/account?topic=cli-cbr-plugincbr-zones-cli).

The following example command adds an individual IP, range, subnet, and a VPC to a network zone.

ibmcloud cbr zone-create --name example-zone --description "this is an example of zone" --addresses 169.23.56.234,169.23.22.0-169.23.22.255,192.0.2.0/24 --vpc crn:v1:bluemix:public:is:us-south:a/12ab34cd56ef78ab90cd12ef34ab56cd::vpc:r134-d98a1702-b39a-449a-86d4-ef8dbacf281e









 Limitations 

Context-based restrictions protect only the actions associated with the [DNS Services API](https://cloud.ibm.com/apidocs/dns-svcs). Actions associated with the following platform APIs are not protected by context-based restrictions. Reference the API docs for the specific action IDs.



* [Resource Instance APIs](https://cloud.ibm.com/apidocs/resource-controller/resource-controllerlist-resource-instances)
* [Resource Keys APIs](https://cloud.ibm.com/apidocs/resource-controller/resource-controllerlist-resource-keys)
* [Resource Bindings APIs](https://cloud.ibm.com/apidocs/resource-controller/resource-controllerlist-resource-bindings)
* [Resource Aliases APIs](https://cloud.ibm.com/apidocs/resource-controller/resource-controllerlist-resource-aliases)
* [IAM Policy APIs](https://cloud.ibm.com/apidocs/iam-policy-managementlist-policies)
Create a Custom Image If you are not taking snapshots of the boot volumes, create a custom image to reduce the provisioning time for instances. New virtual instances are built from a golden virtual instance, with preinstalled applications and configurations. 
 Streamline your recovery Use hostnames for Subnets Subnets are zone-specific. Subnets do not extend across the three zones. This limitation can pose a challenge especially for zonal DR. New IP addresses are assigned to the new instances, which can break any existing configurations such as security rules, application configuration files. Use hostnames and DNS instead of IP addresses because the IP addresses must be updated as part of the post-provisioning process. Using hostnames and DNS can minimize the number of changes required. 
 Use Terraform to create standby sites when needed Terraform is an open source infrastructure as a code tool that can help lessen the upfront cost and speed up the standing of the DR site. Create a script to monitor your production site. Then, based on specific events, the script can trigger the terraform script to start the automation and build out the new DR site. using scripts this way can eliminate the need of a warm standby site. Although the RPO/RTO is not as low, it is better than the cold approach with the added benefit of avoiding the cost of unutilized virtual instances 







 Next Steps 

For more information, see [Regional snapshots in 3-tier architecture](https://cloud.ibm.com/docs/ha-infrastructure?topic=ha-infrastructure-regional-snapshots-3-tier-arch)
[Transportation dictionary in the product ui](https://cloud.ibm.com/docs-content/v1/content/f16b1f78a92498247223b337bd9303c2758b9ba8/discovery-data/images/dict-transportation.png)

Figure 1. Transportation dictionary

The resulting facet that is created for the dictionary is displayed in the search page.

Zoom

![Search page with Transportation facet](https://cloud.ibm.com/docs-content/v1/content/f16b1f78a92498247223b337bd9303c2758b9ba8/discovery-data/images/dict-facet.png)

Figure 2. Transportation facet

The document where the enrichment is applied contains the following sentence:

Some car fluids can be acidic, such as battery fluid.

The following JSON snippet illustrates how a Transportation dictionary enrichment mention is stored when the term car, which is a synonym for the vehicle dictionary entry, is found in the document. In this collection, the dictionary enrichment is applied to the text field, so the mention is listed in the entities array that is in the enriched_text array.

{
"enriched_text": [
{
"entities":
{
"model_name": "Dictionary:.Transportation",
"mentions":
{
"confidence": 1,
"location": {
"end": 91122,
"begin": 91119
},
"text": "car"
}
],
"text": "vehicle",
"type": "Transportation"
}
]
}
]
}
Show more





 Uploading dictionary terms 

To add dictionary from a CSV file, complete the following steps:



1. Create a CSV file that contains the dictionary terms that you want to add.

Use UTF-8 encoding. Specify one entry per line.
* UI
* CLI
* API
* Terraform







 Creating a Generic Routing Encapsulation tunnel connection 

You can connect endpoints using a Generic Routing Encapsulation (GRE) tunnel transit gateway connection. This connection allows a transit gateway to connect to overlay networks hosted on classic infrastructure resources.

This form of GRE tunnel is now deprecated, and we suggest using an unbound GRE tunnel instead. Unbound GRE tunnels provide the following benefits:



* The ability to receive classic network subnets from a classic connection.
* The ability to communicate through other unbound GRE tunnels on the same transit gateway in the same availability zone.
* Does not require a classic connection on the transit gateway. As a result, the classic network's subnets will not be advertised to the connections on the transit gateway (and vice versa).



See [Creating an Unbound Generic Routing Encapsulation tunnel connection](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-unbound-gre-connection) for more information.

Migrating your GRE tunnels to unbound GRE tunnels requires deleting any existing GRE tunnels before creating new unbound ones. Migration will also cause a network disruption for anything that uses the old GRE tunnel until you create the new one.

To migrate from a GRE tunnel to an unbound GRE tunnel:



1. Gather the existing GRE tunnel's configuration information for use on the new unbound GRE tunnel.
2. [Delete your old GRE tunnel](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-deleting-connections&interface=ui).
3. If desired, delete any classic connections.

Classic connections cannot be deleted if they are being used by other GRE tunnels.
4. [Create the new unbound GRE tunnel](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-unbound-gre-connection&interface=ui).



Transit gateway GRE connections require the gateway owner to specifically configure HA for their needs.
[egress-rule1](https://cloud.ibm.com/docs-content/v1/content/d50364af907081c3c38f99c11f35dd9cab4b2510/vpc-journey/images/advanced-elements/spoke1-egress-rule.png)![egress-rule2](https://cloud.ibm.com/docs-content/v1/content/d50364af907081c3c38f99c11f35dd9cab4b2510/vpc-journey/images/advanced-elements/spoke2-egress-rule.png)







 Next Steps 

Additional resources, such as leveraging [Flow Logs](https://cloud.ibm.com/docs/vpc?topic=vpc-flow-logs) for logging VPC traffic is available within our [documentation](https://cloud.ibm.com/docs/vpc?topic=vpc-getting-started).





 Related content 



* [How to Use a Transit VPC with Firewall/Routers to Control Traffic in a Collection of Spoke VPCs](https://www.ibm.com/cloud/blog/how-to-use-a-transit-vpc-with-firewall/routers-to-control-traffic-in-a-collection-of-spoke-vpcs): This IBM Cloud Blog post includes more information and a Terraform configuration that is used to build a three VPCs hub-and-spoke infrastructure where all data transfers through firewall/routing appliances.
Extend to Advanced Elements 



 Journey Map 

![Architecture](https://cloud.ibm.com/docs-content/v1/content/d50364af907081c3c38f99c11f35dd9cab4b2510/vpc-journey/images/advanced-elements/journey-map.png)





 Overview 

If multiple VPCs will be used within the environment a "Hub-and-Spoke" approach may be beneficial. In this scenario:



* A transit "Hub" VPC serves as a centralized point for routing network traffic to/from the "Spoke" VPCs where workloads are running.
* The transit "Hub" VPC can be managed by your organizations network infrastructure SMEs. Each "Spoke" VPC can be owned by a Project/App Team.
* Traffic to/from on-prem and the "Spoke" VPCs and traffic between the "Spoke" VPCs pass through the VNF(s) in the "Hub" VPC.



* VNFs within the VPC may be transparent VNFs like Palo Alto or CheckPoint firewalls, or non-transparent VNFs like F5, etc. and are managed by you.
* While VPC has native controls such as Subnet ACLs and Security Groups for control traffic, depending on the complexity of your organization, your network team may prefer to leverage centralized VNFs in transit VPC to control the traffic.



* VPC's Custom Routing using ingress/egress rules is used to transit packets to/from the VNF(s) in the "Hub" VPC



The following architecture depicts a VPC Hub-and-Spoke Topology on the IBM Cloud:

![Architecture](https://cloud.ibm.com/docs-content/v1/content/d50364af907081c3c38f99c11f35dd9cab4b2510/vpc-journey/images/advanced-elements/hub-and-spoke-standalone.png)





 Configuration Steps 



* [Provision VPC as hub](https://cloud.ibm.com/vpc-ext/provision/vpc) with following prefixes: !
An attacker can use one or multiple attack vectors, and might even cycle through these attack vectors based on countermeasures taken by the target.

Common types are:



* Application layer attacks (Layer 7)
* Protocol attacks (Layer 3 and Layer 4)
* Volumetric attacks (amplification attacks)





 Application layer attacks 

An application layer attack is sometimes referred to as a Layer-7 DDoS attack (in reference to the 7th layer of the OSI model). The goal of these attacks is to exhaust the resources of the victim, by targeting the layer where web pages are generated on the server and delivered to the visitors in response to HTTP requests (that is, the application layer). Layer-7 attacks are challenging, because the traffic can be difficult to identify as malicious.





 Protocol attacks 

Protocol attacks utilize weaknesses in Layer 3 and Layer 4 of the ISO protocol stack to render the target inaccessible. These attacks, also known as a state-exhaustion attacks, cause a service disruption by consuming all the available state table capacity of web application servers, or of intermediate resources such as firewalls and load balancers.





 Volumetric attacks 

This category of attacks attempts to create congestion by consuming all available bandwidth between the target and the wider internet. Large amounts of data are sent to a target using a form of amplification, or by other means of creating massive traffic, such as requests from a botnet.







 What do I do if I’m under a DDoS attack? 

Step 1: Turn on “Defense mode" from the Overview screen.

Step 2: Set your DNS records for maximum security.

Step 3: Do not rate-limit or throttle requests from IBM CIS, we need the bandwidth to assist you with your situation.

Step 4: Block specific countries and visitors if necessary.