DNS: Domain Name System (Domain Name Server)

Overview

DNS is a vast protocol that is essentially its own subject entirely, however, within the scope of this document it is only important to understand the basics of DNS and how it is used when dealing with CDN vendors.

‍

Basic Definitions:

‍
Root Domain: (or Top-Level Domain) is the domain without any prefix. For example, from the web address www.google.com, google.com is the root domain.

‍

IP Address: is the actual address known and understood by servers and routers.
For example, 1.1.1.1 could be the IP address for a server that contains a website or application.

‍

Sub-domain: is the full address of a domain. For example, www.google.com is a sub-domain of the root domain google.com.

‍

DNS Records: are different groups of information that translate domains into either IP addresses or other domains. (There are variations of these but for the purpose of this document they are not required). The most relevant record types for this document are ‘A Records’ and ‘CNAME Records’. ‘A Records’ are sub-domains that are translated into IP addresses and ‘CNAME Records’ are sub-domains translated to another sub-domain (alias).

‍

How it works:
Servers and routers (public and private) all use IP addresses (without going into MPLS and other methods) to communicate with each other. Website addresses or HTTP applications are all located on servers that will have a public IP address if they need to be accessed by end users. For example, www.google.com resolves to an IP address which is where the request is sent to and the response is received. It is not feasible for end users to learn and remember the IP addresses of all the sites so these are given memorable names such as www.google.com and within the DNS configuration for the domain google.com there will be an A Record that will translate the www.google.com sub-domain to an IP address.

‍

Hint: The easiest way to remember DNS is to think of it as the phonebook for the internet. It is like looking up a friend’s name and clicking dial. You do not need to know their phone number as your phonebook will translate the name you chose into a phone number and dial it for you.

‍

‍

DNS and CDN

The primary use of a CDN is to decrease load times across a geographical area and DNS plays a major part in this. In order to make use of a CDN, the domain must point to a CDN provider and this is achieved through DNS using the CNAME record (described below).

‍

‍

Domain of application that is also configured on the CDN: www.domain.com Domain of the hosting server: origin.domain.com

As per Diagram 6 DNS resolutions can take place in two parts of a what is a single request by an end user. When we consider performance of a HTTP request, it is broken down into 6 parts (explained later in HTTP) and DNS Lookup is the first. In order to point to a CDN, the following steps need to be considered.

‍

DNS Provider

Are you using your ISP, or do you pay extra for a known DNS provider? Recommendation when using a CDN is touse a known DNS provider to ensure performance at this level.

‍

Current domain that points directly to the hosting server.

You should configure the same domain on the CDN. This helps avoiding the reconfiguration of domains in yourwebsite/application code.

‍

Number of DNS requests (hops) for a single domain.

Without stating the obvious, a single DNS query is best practice. A domain that resolves to an A record or CNAME record, however, there are cases when this is not entirely possible. Best Practice is to keep the number of DNS queries per domain request to a minimum.

‍

CDN domain (if different from the above).

In some cases, a single website/application is best split between different CDN products for various reasons. These are normally to split static and dynamic content (creates more than a single point of failure and reduces cost). This is best practice and the most preferred method but it does require more planning and coding.

‍

CNAME – Canonical Name Record

To point a domain to a CDN requires a CNAME record in the DNS zone. A CNAME record is an alias for a sub-domain. It works in a similar way to an A record but instead of pointing a sub-domain to an IP address, it allows us to point a sub-domain to another sub-domain that the end user does not have to remember.

‍

Example: www.domain.com CNAME www.domain.com.cdn.vendor.net.
The end user will only have to know the sub-domain and the DNS will point the domain to the CDN. Note, the IP address of the hosting server is not required as this will be configured in the CDN. A great way to hide your hosting server IP from potential attacks. For more information see the below link: https://en.wikipedia.org/wiki/CNAME_record

‍

Best Practice

Always refer to your CDN vendor for a detailed list of their CNAME options as these are usually product or geographically dependent. Choosing the incorrect CNAME will not stop the CDN from working but it could reduce performance.

‍

RCNAME/APEX Record (CNAME a Root Domain)

In some cases, you may want to CNAME a root domain. All CDN and DNS vendors will not recommend doing this as it sits outside of best practice. The only point that needs to be noted from this section is that it is possible and CDN and DNS vendors do support it.

‍

TTL – Time to Live

When configuring a DNS record there is an option for each record called TTL. This is the amount of time the record should be cached for by other DNS servers. By default, many DNS providers will have this value set to 300 seconds.

‍

Best Practice

Set your TTL as long as possible (24 hours or longer) on domain records that you do not forecast changing often. Note that during the testing phases of new domains and CDN configurations, set the TTL to no longer than 5 minutes (300 seconds) so changes propagate quickly.

‍

Wildcard Domains and SSL certificates

It is possible to setup CNAME records for wildcard domains but please note the below if you are planning to do this.

‍

Best Practice

If there are many sub-domains that share the same root domain and share the same CDN configuration setup and rules it is a perfect scenario to use a wildcard domain. The only flaw is when we start to consider SSL. SSL providers do allow wildcard certificates and some even allow wildcard domains on shared certificates, however, there is a standard that must be kept to:

• Wildcards on SSL certificates only work on 1 level sub-domains

‍

Example:

‍
*.domain.com on an SSL certificate would be accepted and rejected as follows:
Accepted: www.domain.com, cdn.domain.com, hello-world.domain.com
Rejected: www.cdn.domain.com, abc.123.domain.com
Note that each “.” (period) denotes another sub-level. SSL will only support a single sub-domain. The workaround would be to use a “- “(dash) to replace “.” (period) to avoid going further than single sub-domain levels.

‍

‍