5. Aliases

Aliases are essentially host names you would like served by the CenturyLink CDN. These names are presented in the host: header of a clients HTTP/HTTPS request for content. The alias is the key for the CDN nodes to determine what treatments to apply to the request, what origin to fill form, etc. Request for unrecognized Aliases result in the CDN returning a 404 error response.

The Alias definition contains the minimal amount of information required to create a functional configuration without having to create a Match Rule.

To facilitate efficient configuration, Aliases can be grouped together based on common configuration attributes. For example multiple HTTP Aliases can be grouped under a single Alias Definition. Note that all aliases under the same definition and OriginID share a common cache key (originID+URL)

An example of the most basic Alias definition:

"aliasDefinitions": [
  {
    "id": 1,
    "name": "example",
    "originId": 24152,
    "reportingId": 24152,
    "protocol": [
      "HTTP"
    ],
    "aliases": [
      "www.example.com"
    ]
  }
]

Attributes of an Alias Definition are as follows:

  • id: An integer value, must be unique across all aliasDefinitions within a given service image
  • name: A descriptive name for the definition. Not to be confused with the actual Alias
  • originId: The OriginID to associate with this set of Aliases. For now OriginID = ReportingID
  • reportingId: The ReportingID to associate with this set of Aliases. For now ReportingIDs = CoserverIDs
  • protocol: The protocol the Alias is allowed to use
  • aliases: A list of aliases (FQDNS) that the CDN is expected to see in the clients host: header. In some cases the Alias is pre-fixed with an integer of the form <int>:alias. This is referred to an alternateID Alias and is a carry over from Legacy CDN systems. See the AltID section for further details.

Changed in version 19.1: Removed the precondition of first creating a property in order to add a new Alias.

5.1. CNAME

Each Alias must have a CNAME entry to direct traffic to the CTL CDN. When Aliases are added to a Service Image and pushed to production, a corresponding CDN DNS Name is created. This DNS name is used in the CNAME response and must be provisioned in your Authoritative DNS system. An Aliases CDN DNS Name can be determined by issuing a separate API call which returns the CDN DNS Name for the Alias in question.

Note that this API call returns the CDN DNS Name based on the configured ITM network in the Subscriber Metadata, not what is actually configured. The API will be enhanced in the future to verify the actual CDN DNS Name configured. If no ITM Network is configured, the request will return an error.

5.2. HTTPS

HTTPS can be provisioned as part of the Alias definition. See the sections on Secure Delivery and Secure Features for additional details on how to provision these services.

Note

HTTPS services cannot be self provisioned at this time due to how certificates are managed. Customers are however able to see any HTTPS configurations that may exist.

5.3. HTTP/2

HTTP/2 can only be enabled for HTTPS Aliases using the http2 boolean under the httpsConfig:

"httpsConfig": {
  "serviceType": "Basic",
  "ocsp": false,
  "encryptionLevel": "Default",
  "certInfo": {
    "id": 1,
    "name": "star.secure2.footprint.net"
  },
  "http2": true
}

Note that when enabling http2 with Basic SSL, the star.secure2.footprint.net cert must be used for proper operation.

5.4. Extended Alias

New in version 19.5.

Extended Aliases are Alias definitions with a single path element, for example: www.example.com/path. Taking our basic Alias definition from before, we can turn it into an extended alias by adding a single path element to the Alias definition, for example:

"aliasDefinitions": [
  {
    "id": 1,
    "name": "extended_alias",
    "originId": 24152,
    "reportingId": 24152,
    "protocol": [
      "HTTP"
    ],
    "aliases": [
      "www.example.com/path"
    ]
  }
]

By adding a path element to the Alias definition, the system matches requests based on the alias/path instead of just Alias. This allows for additional flexibility in influencing system behavior for different object paths under the same alias.

5.5. Wildcard aliases

New in version 19.7.

Wildcard aliases are of the form *.example.com. A wildcard alias will match any hostname in the host: header under the example.com domain. So both foo.example.com and foo.bar.example.com will match *.example.com. Note that more specific aliases (e.g., www.example.com) will match over a less specific wildcard alias.

"aliasDefinitions": [
  {
    "id": 1,
    "name": "wildcard_alias",
    "originId": 24152,
    "reportingId": 24152,
    "protocol": [
      "HTTP"
    ],
    "aliases": [
      "*.example.com"
    ]
  }
]

5.6. ReportingIDs

An alias can be associated with a standalone reportingID (see Standalone ReportingId) which can be used to group aliases into a different reporting groups but yet leverage the same origin and behavior as other aliases. Aliases under the same reportingID will have their usage, real-time metrics and log data aggregated under the indicated reportingID.

CDN support can assist in creating new standalone reportingID’s (they cannot be directly created within the service image at this time, but once created they can be used within the service image).

Changed in version 19.6: Updated the section to indicate standalone reportingIDs were introduced in the 19.6 release.

5.7. Duplicate Aliases

The CTL CDN provisioning system performs a variety of validations against a Service Image to make sure it does not conflict with itself or other subscribers configurations One of those is to verify that an alias only appears at most once across all subscribers and within a given Service Image.

This check is also performed across the staging and production environments such that a given alias can only be used by a single subscriber across both environments. Consider the following illustrative case:

  1. A new subscriber, Subscriber 1, is activated with no active service image
  2. Subscriber 1 creates a service image with alias example.com and pushes this service image to staging
  3. Subscriber 1 then pushes the service image from staging to production
  4. Subscriber 1 removes example.com and adds alias extra.com to the service image, they then push the service image to staging

At this point, example.com exists in the production network while extra.com exits in the staging network.

  1. A new subscriber, Subscriber 2, is activated with no active service image
  2. Subscriber 2 creates a service image with alias example.com and pushes this service image to staging
  3. The provisioning system searches all aliases in staging and sees example.com isn’t in use so validation passes, however it then goes on to search the aliases in the production environment and sees example.com is in use by Subscriber 1, so validation fails and the service image will be rejected.