Hostnames and Origins

• Hostname: A hostname identifies a domain (e.g., cdn.example.com) through which your site will be served.
• Source: Define the source from which Edgio will retrieve content. You may retrieve content from any combination of the following sources:
  • Origin: An origin configuration defines how our service will communicate with your web servers.
  • Edgio Cloud: The Edgio cloud, which powers Edgio Sites and Cloud Functions, allows you to run serverless code.

Quick Start #

1. Define each hostname through which your site’s content will be delivered.
2. Create an origin configuration that defines how Edgio communicates with your web server(s).
3. Configure your firewall to accept traffic from our network.
4. Edgio requires a TLS certificate hosted on our network to serve HTTPS traffic. You may either upload your own TLS certificate or you may allow Edgio to autogenerate it for each hostname defined in step 1 by performing the following steps:
   1. Check for CAA records and verify that the Let’s Encrypt certificate authority is allowed to issue certificates for that hostname.
   2. Add an _acme-challenge CNAME record that proves your control over that hostname.
      Example: _acme-challenge.cdn.example.com. CNAME _acme-challenge.xdn-validation.com.
5. Once you are ready to serve traffic on our CDN, use your DNS service provider to update the DNS record for each hostname defined in step 1 to point to our service.

Hostnames #

• Specify hostnames using lower-case letters.
• Hostnames must be unique across all environments.
  For example, if you have defined www.example.com within the production environment, then you cannot define it within any other environment until you delete it from the production environment.
• Each hostname is mapped to an origin configuration. By default, Edgio proxies cache misses for that hostname to that origin configuration. You may override this mapping through the Set Origin feature or your CDN-as-code configuration (set_origin).
• Each hostname requires the installation of a TLS certificate on our network. Edgio can automatically generate and install this TLS certificate when both of the following requirements are met:
  • Certificate Authority Authorization: The Let’s Encrypt certificate authority (CA) must be allowed to issue certificates for that hostname. It is allowed to issue certificates when either of the following conditions are true:
    • A CAA record has not been issued for that hostname or a parent hostname. This DNS configuration means that any CA is allowed to generate certificates for that hostname.
    • A CAA record explicitly allows the Let’s Encrypt CA to generate certificates for that hostname.
    This sample CAA record indicates that the Let’s Encrypt CA is allowed to issue certificates for cdn.example.com:
    cdn.example.com. CAA 0 issue "letsencrypt.org"
  • Domain Control Validation: Prove your control over that domain by adding an _acme-challenge CNAME record to it.
    Example: _acme-challenge.cdn.example.com. CNAME _acme-challenge.xdn-validation.com.
  Alternatively, you may upload your own TLS certificate.
• Once you are ready to serve traffic through Edgio, update the hostname’s DNS configuration to point to our service.

1. Load the Hostnames page.
   1. From the Edgio Console, select the desired private space or organization.
   2. Select the desired property.
   3. From the left-hand pane, select the desired environment from under the Environments section.
   4. From the left-hand pane, select Hostnames.
2. Perform one of the following steps:
   • Add a Hostname:
     1. Click + Add hostname.
     2. Add each desired hostname on a separate line.

     

     3. Click Add Hostnames.
   • Assign an Origin: Map a hostname to a different origin by selecting the desired origin from under the Default Origin column.
     The Default Origin column is read-only when the current property only contains a single origin configuration (e.g., web).
   • Modify a Hostname: Modify an existing hostname by replacing the existing hostname with a new value.

     

   • Delete a Hostname: Click

     

     next to the hostname that should be deleted.
3. Repeat step 2 as needed.
4. If you are finished making changes to this environment, click Deploy Changes.

Origin #

• Each origin configuration identifies a set of web server(s) by hostname or IP address. You may specify up to 4 hostnames or IP addresses.
• Load balance requests to the web servers associated with an origin configuration using either primary/failover or round-robin mode.
• The maximum number of origin configurations per environment is 100.
• By default, our CDN forwards the Host header provided by the client when proxying requests to your origin server(s). You may override the client’s Host header by setting the Override Host Header option to the desired hostname. This forces our CDN to set the Host header to the specified hostname whenever it proxies traffic to the origin server(s) associated with this origin configuration.
  Overriding the Host header is useful when your origin implementation uses multiple virtual hosts or a virtual host with multiple aliases.
• You may configure an origin configuration to always serve traffic to your hosts over HTTP, HTTPS, or to match the client’s scheme. Matching a client’s scheme means that our network will serve HTTP traffic to your web servers over port 80, while HTTPS traffic will be served over port 443.
• An origin configuration’s Use SNI option determines whether Edgio will provide a Server Name Indication (SNI) hint to your origin server during the TLS handshake.
  • A SNI-enabled web server uses a SNI hint to determine the TLS certificate that will be returned.
  • If the Use SNI option has been enabled, Edgio compares the hostname defined within the SNI hint to the certificate’s Subject Alternative Name (SAN) or Common Name (CN) during the TLS handshake. If the hostname does not match, then we will respond with a 502 Bad Gateway response.
  • If your origin server requires SNI, then you must provide a SNI hint. Otherwise, your web server will reject the request and our edge servers will respond with a 502 Bad Gateway response.
• By default, our network disables delivery and responds with a 502 Bad Gateway when we detect an origin server using a self-signed certificate during the TLS handshake. Allow Edgio to serve traffic when it detects a self-signed certificate by enabling the Allow Self-Signed Certs option.
• Register the SHA-256 digest for the public key of your end-entity (i.e., leaf) certificate within the Pinned Cert(s) option. After which, our edge servers will respond with a 502 Bad Gateway response when the SHA-256 digest for the public key detected from the origin server does not match one of the pinned certificates.
• Malicious actors may bypass the security provided by our service by directly targeting your origin server(s). We strongly recommend that you set up your firewall to only allow traffic from trusted sources (e.g., our network) and to obfuscate your origin.

1. Load the Origins page.
   1. From the Edgio Console, select the desired private space or organization.
   2. Select the desired property.
   3. From the left-hand pane, select the desired environment from under the Environments section.
   4. From the left-hand pane, select Origins.
2. Click + Add Origin.

   

3. In the Name option, assign a name to this origin configuration. This name should only consist of alphanumeric characters, hyphens, periods, and underscores.
   We recommend a unique, descriptive name to help you quickly map hostname(s) to this origin configuration.
4. Define one or more host(s). Each host determines how Edgio will communicate with your web server(s).

   

   1. In the Origin Hostname option, type a hostname or IP address that points to your web server(s).
   2. Optional. Set the Port option to the port over which our network will serve traffic to the above hostname or IP address.
   3. Set the Scheme option to always serve traffic to your hosts over HTTPS, HTTP, or to match the client’s scheme.
   4. Optional. Override the client’s Host header by setting the Override Host Header option to the desired hostname.
   5. Optional. Add another host to this origin configuration by clicking + Add Host and then performing steps 4.1 - 4.4.
   6. Optional. Set the Balancer type option to the desired load balancing mode for requests proxied to your web servers.
5. Define TLS settings for this origin configuration through the Origin TLS Settings section.
   1. Most web servers require a SNI hint during the TLS handshake. Define this SNI hint through the Use SNI option. By default, this option is set to the value assigned to the Override Host Header option.
      Perform either of the following steps:
      • If your web server requires a SNI hint, verify or set the SNI hint through the Use SNI option.
      • If your web server does not use SNI, then you should disable the Use SNI option.
      Upon enabling SNI, our service will perform a strict check using this hostname against the certificate’s Subject Alternative Name (SAN) or Common Name (CN) during the TLS handshake.
   2. If your origin servers use a self-signed certificate, then you should toggle the Allow Self Signed Certs option to the on position (

      

      ).
   3. Set up certificate pinning by adding one or more public keys.
      1. Click + Add Pin.
      2. Paste the SHA-256 digest for the public key of your leaf certificate.
      3. Repeat steps 1 and 2 as needed.
6. Optional. Protect your origin by defining one or more shield POP(s). Click on the Shields section to expand it.
   1. Assign a POP location to the region closest to your web server(s).
      Upon configuring a region, all other regions will be updated from Bypass to the selected POP. This configuration means that cache misses from all regions will be proxied to the selected POP location.

      

   2. Optional. Assign a POP location to a different region.
      Upon configuring a second region, the remaining regions are automatically updated from the selected POP to Use the shield with the lowest RTT. This configuration means that cache misses from the remaining regions will be proxied to the shield POP that will provide the best performance.
      For example, the following configuration may potentially allow cache misses from the APAC region to be served through the shield location defined for the US West region (i.e., OXR).

      

   3. Optional. Repeat step 2 as needed.
   4. Optional. Configure cache misses from a specific region to always be proxied to your origin by selecting Bypass.
7. If you are finished making changes to this environment, click Deploy Changes.

System-Defined Origins #

• edgio_image_optimizer: Used for serving images through the image optimization feature.
• edgio_permanent_static: Used for serving static assets configured to persist across deployments.
• edgio_serverless: Used for serving requests through the Edgio cloud.
• edgio_static: Used for serving static assets.

HTTP/3 #

• Once a QUIC-compatible user agent discovers that a server supports QUIC, it will attempt to leverage QUIC for all subsequent requests to the same domain until the connection ends.
• By default, QUIC is supported on the latest versions of Google Chrome, Chromium, and Opera. However, it may require enablement. If a user agent doesn’t support QUIC, then it will communicate with the CDN using HTTP/2 over TCP.
• Our QUIC implementation supports the Bottleneck Bandwidth and Round-trip propagation time (BBR) congestion control algorithm without requiring additional CDN setup. However, BBR will only be used when a QUIC-enabled client (e.g., Google Chrome) requests it.
• The alt-svc header contains a v (version) parameter that identifies the supported QUIC versions. We strongly recommend that you define this response header through the Set Response Headers (set_response_headers) feature and set the v parameter to the %{quic_altsvc_versions} variable. This variable returns the QUIC versions supported by our service.
  We may add or drop support for QUIC versions at any time. Ensure that you only advertise supported versions by setting the v parameter to the %{quic_altsvc_versions} variable
• Sample alt-svc header name/value: alt-svc: quic=":443"; ma=2592000; v="49,48,46,43",h3-Q049=":443"; ma=2592000,h3-Q048=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000
  The above sample response header indicates to the client that:
  • QUIC is only supported for traffic over port 443 as defined by the quic parameter.
  • The user agent should treat the connection as fresh for 259,200 seconds (i.e., 3 days) as determined by the ma (max-age) parameter.
  • The v (version) parameter informs the client as to the supported QUIC versions.

Load Balancing #

• Edgio generates a list of IP addresses by resolving the hostnames associated with an origin configuration. These IP addresses are listed according to the order in which the corresponding hosts are listed within your origin configuration.
• If an origin configuration allows Edgio to proxy requests using both HTTP and HTTPS, then Edgio will generate an ordered list of IP addresses for each HTTP scheme.
• The available load balancing options are:
  • Primary/Failover: This load balancing mode requires Edgio to:
    1. Proxy all traffic to the first IP address in the list.
    2. If the current server is unavailable, then Edgio will issue another request to the next IP address on the list. This step is repeated until a server is able to honor the request.
    Set up primary/failover load balancing by selecting Primary failover from the Balancer type option.
  • Round-robin: This mode distributes requests evenly across all IP addresses. If a server is unavailable, then the request will be sent to the next IP address on the list.
    Set up round-robin load balancing by selecting Round robin from the Balancer type option.
• The above load-balancing options are completely independent from any load balancing configuration that may already distribute traffic to your web servers. For instance, traffic for a single IP address might be load balanced across several physical servers.

Unavailable Servers #

• A TCP connection is refused.
• The connection times out.

1. Once a server is designated as unavailable, CDN traffic will not be load balanced to the corresponding hostname or IP address for a brief time period.
2. Upon the expiration of this time period, CDN traffic may once again flow through the corresponding hostname or IP address according to its position within your origin configuration.
3. If the server is still unavailable, then CDN traffic will not be load balanced to the corresponding hostname or IP address for a brief, but slightly longer time period.
4. Steps 2 and 3 repeat until the server becomes available.

Firewall - Allowing Edgio IP Addresses #

1. Load the Origins page.
   1. From the Edgio Console, select the desired private space or organization.
   2. Select the desired property.
   3. From the left-hand pane, select the desired environment from under the Environments section.
   4. From the left-hand pane, select Origins.
2. From the information bar at the top of the page, click instructions.

   

   The Allowlisting window will display a list of IPv4 and IPv6 blocks for standard traffic, Perimeter 81 for network security, AWS NAT gateway for the Edgio cloud, and the domain to which the Edgio CLI connects when deploying to a development or CI/CD environment.
   We strongly recommend that you allow traffic for all IP blocks and the domain listed on the Allowlisting window.

Serving Traffic through Edgio #

Environment-Specific Service Domain #

1. Load the Hostnames page.
   1. From the Edgio Console, select the desired private space or organization.
   2. Select the desired property.
   3. From the left-hand pane, select the desired environment from under the Environments section.
   4. From the left-hand pane, select Hostnames.
2. From the DNS column, click Actions needed.

   

3. From the DNS Configuration pane, click

   

   to copy this domain.

Space-Specific Service Domain #

• Your private space.
• Each organization to which you belong.

1. Load the space’s Settings page.
   1. From the Edgio Console, select the desired private space or organization.
   2. Click Settings.
2. From the Organization DNS Configuration section, click

   

   to copy this domain.

DNS Verification #

1> dig cdn.example.com
2
3# Result
4cdn.example.com.   599    IN    CNAME    2af36ae6-2146-4b73-a5e7-f86c4a93bc06.edgio.link