- About the web interface controls
- Always-on DDoS mitigation
- Browser recommendations when using the Fastly web interface
- Content and its delivery
- Fastly POP locations
- Getting started with Fastly
- How caching and CDNs work
- How Fastly's CDN Service works
- HTTP status codes cached by default
- Self-provisioned Fastly services
- Sign up and create your first service
- Working with services
Domains & Origins
Domains & Origins
- Changing origins based on user location
- Connecting to origins
- Enabling global POPs
- Failover configuration
- IPv6 support
- Maintaining separate HTTP and HTTPS requests to origin servers
- Routing assets to different origins
- Setting up redundant origin servers
- Specifying an override host
- Using Fastly with apex domains
- About Dynamic Servers
- Authenticating URL purge requests via API
- Cache control tutorial
- Caching configuration best practices
- Controlling caching
- Creating and using pools with Dynamic Servers
- Creating and using server entries with Dynamic Servers
- Enabling API caching
- Enabling automatic gzipping
- Failure modes with large files
- Getting started with surrogate keys
- HTTP/2 server push
- Implementing API cache control
- Logging purge requests
- Making query strings agnostic
- Purging API cache with surrogate keys
- Request collapsing
- Segmented Caching
- Serving stale content
- Setting Surrogate-Key headers based on a URL
- Setting Surrogate-Key headers for Amazon S3 origins
- Single purges
- Soft purges
- Streaming Miss
- Wildcard purges
- Accept-Language header VCL features
- Authenticating before returning a request
- Basic authentication
- Creating location-based tagging
- Custom responses that don't hit origin servers
- Delivering different content to different devices
- Enabling URL token validation
- Guide to VCL
- Isolating header values without regular expressions
- Manipulating the cache key
- IP geolocation variables: Migrating to the new dataset
- Overriding which IP address the geolocation features use
- Response Cookie handling
- Support for the Edge-Control header
- Understanding the different PASS action behaviors
- Using edge side includes (ESI)
- VCL regular expression cheat sheet
Access Control Lists
Monitoring and testing
- Domain validation for TLS certificates
- Enabling HSTS through Fastly
- Forcing a TLS redirect
- Managing domains on TLS certificates
- Serving HTTPS traffic using certificates you manage
- Serving HTTPS traffic using Fastly-managed certificates
- Setting up free TLS
- TLS key and certificate replacement
- TLS termination
Web Application Firewall
- Log streaming: Amazon S3
- Log streaming: Microsoft Azure Blob Storage
- Log streaming: Cloud Files
- Log streaming: Datadog
- Log streaming: DigitalOcean Spaces
- Log streaming: Elasticsearch
- Log streaming: FTP
- Log streaming: Google BigQuery
- Log streaming: Google Cloud Storage
- Log streaming: Honeycomb
- Log streaming: Kafka
- Log streaming: Log Shuttle
- Log streaming: LogDNA
- Log streaming: Logentries
- Log streaming: Loggly
- Log streaming: Heroku's Logplex
- Log streaming: OpenStack
- Log streaming: Papertrail
- Log streaming: Scalyr
- Log streaming: SFTP
- Log streaming: Splunk
- Log streaming: Sumo Logic
- Log streaming: Syslog
User access and control
Adding CNAME records
Last updated October 03, 2018
This guide describes how to choose the right hostname and how to update the CNAME record for your domain with your DNS provider. Choosing the appropriate CNAME record is the final step required before Fastly can start acting as a reverse proxy and begin routing client traffic through Fastly services instead of directly to your origin.
Before you begin
Before you add a DNS CNAME record, keep in mind the following:
- To make the changes suggested here you must have access privileges to modify DNS records for your domain.
- If you plan to use Fastly on your apex domain (e.g.,
www.example.com), you can't use a CNAME record. See our guide to using Fastly with apex domains for more details.
Choosing the right Fastly hostname for your CNAME record
To successfully update your DNS CNAME record, you must choose the right Fastly hostname to use. The hostname you choose will differ based on:
- the standard HTTPS (TLS) support requirements for your domain, including whether or not HTTP/2 is enabled.
- any custom TLS options purchased for your domain.
- whether or not you choose to limit your traffic to the North American and EU network or use Fastly's global network.
We've provided recommendations below based on these criteria.
Non-TLS hostnames and limiting traffic
If you don't require TLS support and only need to accept HTTP (Port 80) connections, use one of the following hostnames:
nonssl.global.fastly.net.to route traffic through Fastly's entire global network.
nonssl.us-eu.fastly.net.to route traffic through Fastly's North American and EU POPs only.
IMPORTANT: Fastly's non-TLS hostnames refuse HTTPS connections (port 443) to prevent TLS certificate mismatch errors.
[letter].shared.global.fastly.net.to route traffic through Fastly's entire global network.
[letter].shared.us-eu.fastly.net.to route traffic through Fastly's North American and EU POPs only.
When you purchase one of these certificate services, Fastly Support will add your domains to a specific TLS Certificate, usually differentiated by a certificate letter (e.g.,
c). You'll need to add the appropriate certificate letter to the beginning of the Fastly hostname noted above for use in your CNAME record. For example, if your domain was added to our
a certificate and was being routed through Fastly's entire global network, the above hostname would become:
IMPORTANT: You must use the assigned Fastly TLS hostname provided by Fastly Support. Using the incorrect Fastly hostname will cause a TLS Certificate mismatch error for HTTPS (Port 443) traffic.
If you've purchased our Customer-Provided TLS Certificate Hosting Service option, we'll assign you to a specific domain map that uses the following format:
Free TLS wildcard Certificate
If you plan to accept both HTTP (port 80) and HTTPS (port 443) connections and you're using Fastly's free shared TLS wildcard certificate, use:
IMPORTANT: The free TLS hostname does not support use with your own domain name (
www.example.com). Customers typically use the free TLS hostname in links directly to assets (e.g., linking to
https://example.global.ssl.fastly.net/example.jpg) or for testing purposes. If you want to use your own domain (
www.example.com), see the TLS-enabled hostname section above.
Updating the CNAME record with your DNS provider
Once you've determined the appropriate Fastly hostname for your domain, the next step is to create a CNAME record for your domain. The steps you follow will vary depending on your DNS provider's control panel interfaces. Refer to your DNS provider's documentation for exact instructions on how to create or update a CNAME record.
TIP: If you can't find your provider's CNAME configuration instructions, Google maintains instructions for most major providers. Keep in mind that these instructions are maintained by Google, not Fastly, and are tailored specifically for Google enterprise services.
If you run your own DNS server or are familiar with the format of BIND zone files, the CNAME record would look similar to this:
1 www.example.com. 3600 IN CNAME nonssl.global.fastly.net.
In the above example, the domain set up on Fastly is
www.example.com., with a time-to-live (TTL) of
3600 seconds (1 hour), the Record Type is
CNAME, and the Fastly hostname is
nonssl.global.fastly.net. because TLS support isn't required and traffic will be routed through Fastly's entire global network.
Best practices when updating a DNS CNAME record
- Be sure you've added all domains you want served by Fastly to the appropriate service. If you don't and you point your domain to Fastly, an
unknown domainerror will occur.
- Make sure your service is properly configured. You can test a Fastly service on your local machine by using cURL and our Testing setup before changing domains guides.
- If you have multiple hostnames on the same domain (e.g.,
app.example.com), you can use a DNS wildcard record (
*.example.com) at your DNS provider so only a single CNAME record is created and maintained. You should also add either a matching
*.example.comdomain or the individual domains to your Fastly service.
- Before changing a CNAME to point to a Fastly hostname, change your service configuration to lower the CNAME's TTL to a small number (we suggest 60 seconds) and wait for the old TTL to expire. Creating a DNS CNAME record for your domain after the TTL expiration ensures you have an easy way to roll back changes if you encounter an issue. Once you confirm everything is working properly using Fastly, you can increase the TTL to its original value.
Checking your CNAME record
To check your CNAME record, run the following command in a terminal window:
dig www.example.com +short
Your output should appear similar to the following:
1 2 nonssl.global.fastly.net. 22.214.171.124
In most cases, the hostname displayed first will be your current Fastly hostname (in this case,
nonssl.global.fastly.net.). If you don't see a Fastly hostname in the output or if you see an incorrect Fastly hostname, then either your CNAME isn't properly set at your DNS provider or an older CNAME record is still cached by your local DNS resolver.
Removing CNAME records
If you deactivate a service, delete a service, or cancel your account, we strongly recommend modifying or deleting any CNAME records pointing to Fastly hostnames. Follow the instructions on your DNS provider's website. Doing so will minimize the risk of unauthorized use of your domains.Back to Top