DNS – Making a WordPress site [04]

In the post that explains redirections, I gave a more general explanation of DNS and its role. Here I’ll explain what the A, CNAME, MX, TXT… DNS records mean and how they are set up for a (WordPress) website and email.

• Making a WordPress site [01] Email
• Making a WordPress site [02] Domain registration and nameservers
• Making a WordPress site [03] Hosting
• Making a WordPress site [04] DNS
• Making a WordPress site [05] Hosting setup and SSL
• Making a WordPress site [06] Staging and development
• Making a WordPress site [07] Visual and functional design

Table Of Contents (T.O.C.):

1. What is a DNS and what is it used for?
2. How do DNS-s work?
3. DNS and nameservers
   3.1. Using a separate DNS service
4. DNS records explained
   4.1. DNS records and values
   4.2. Proxy status
   4.3. TTL (Time To Live)
   4.4. Content (also known as “points to”)
   4.5. Name (also known as “Host”)
   4.6. Types of DNS records (also known as DNS zones)
   …4.6.1. A records (AAAA for IPv6) – Host records
   …4.6.2. CNAME DNS records (also known as an alias)
   …4.6.3. MX records
   …4.6.4. TXT records
   …4.6.5. PTR records
   4.7. Using asterisks ( * ) with DNS records (wildcard DNS records)
5. DNS records needed for a WordPress site
6. How to configure DNS records
   6.1. DNS record setup in cPanel
   6.2. DNS record setup in DirectAdmin
   6.3. DNS record setup in Cloudflare
7. Conclusion

1. What is a DNS and what is it used for?

DNS (Domain Name Server) is used to translate addresses that are easily understandable to humans (like www.bikegremlin.com) to the ones that computers can easily understand (like an IPv4 address: 172.217.22.4). Sort of a computers’ address book, to put it simply. By the way, human-friendly address is called an URL (Uniform Resource Locator).

DNS for a domain consists of several records that I’ll explain in this post. It might sound a bit complicated at first, but by the end of this post it will all “fall in its place”. Let us begin.

– T.O.C. –

2. How do DNS-s work?

In the 2nd post of this series, I explained what are domain (domain name) and nameservers. I suggest you first read that post, if you haven’t already. It will help understanding this topic.

Domain registrar for your domain tells everyone which nameservers are relevant for your domain. That is: which nameservers contain DNS records for your domain.

Now, there are many DNS servers in the world. The ones nearest to your nameservers will ask those nameservers about DNS records for your domain and keep a copy for a set period of time. Their neighbour DNS servers will not “bother” your nameservers directly, but first check with their neighbours if they have the DNS records (and keep a copy for themselves after that). This is called DNS propagation. It can take up to 48 hours for all the DNS servers in the World to register a change in DNS records of your website (or a nameserver change for that matter, if you change nameservers).

– T.O.C. –

3. DNS and nameservers

After you’ve chosen a hosting for your website, hosting provider has given you nameservers you can use. If you decide to use those nameservers, all the DNS records will be written, changed and used from your hosting control panel. This is what it looks like in cPanel (we’ll explain later what is what and how it is edited):

Fields masked with blue are IP addresses (like: 172.217.22.4). With DirectAdmin control panel, this looks a bit differently, but the principle is the same:

– T.O.C. –

3.1. Using a separate DNS service

If you decide to use a separate DNS service, then you will set the service’s nameservers in your domain registrar control panel. Good free DNS services are Cloudflare and Hurricane Electric.

Whether you opt for a separate DNS service, or decide to use hosting provider’s nameservers, here’s an explanation how to set nameservers for a domain (the link goes to the 6th chapter of the above mentioned post about domains).

What are the advantages of using a separate DNS service?
It makes website migrations easier. Nameservers are set only once for the domain, to point to the DNS service nameservers, while all the future changes are made on one place – within the DNS service control panel. Also, if you are using a separate email service, you don’t have to set up the DNS records for it whenever you migrate the website (this will be clearer when we explain DNS records later).

Digression: This also enables me to put my cycling website bike.bikegremlin.com on a server in the US, while Serbocroatian version, bicikl.bikegremlin.com is hosted in the UK. This also enables me to make backup copies on a server in Germany. In case either of the servers fail, I can just edit a few fields on the DNS service to point them towards a functioning server. Of course, this can all be made to work automatically, with even a backup DNS service, but that is beyond the scope of this post (Googling “load balancing servers” and “failover DNS setup” can point you in the right direction on that).

Downsides of using a separate DNS?
When you use hosting provider’s nameservers, then everything is set up properly, automatically (well, everything except emails, they never do that right in my experience, since they can’t know which services you use and it takes time – which costs).

When using a separate DNS service, you must set it up yourself. How? I’ll be using Cloudflare DNS for an example.

– T.O.C. –

4. DNS records explained

Here is what DNS setup for a domain looks like (with Cloudflare DNS service):

Now I’ll explain it all one by one item. I have created a link to the picture 3, so you can quickly jump to it, then click back in your browser to return where you were in the text (back arrow is usually in the top-left corner). I’ll be using that link in the remainder of the text, like this: (pic.3).

– T.O.C. –

4.1. DNS records and values

Each row in the picture above is one DNS record. Each record has some values, such as Type, Name, TTL… I’ll start “from the back”, first explaining the last two values (rightmost two columns in the picture), because they are more independent of the record type. Going towards the left.

– T.O.C. –

4.2. Proxy status

“Proxy status” column is Cloudflare specific and I’ll explain that in a separate post.

– T.O.C. –

4.3. TTL (Time To Live)

Take a look at the 2nd chapter, where DNS propagation is explained. TTL is your recommendation to all the DNS servers for how long to consider your DNS information valid. When the TTL time has passed, they should check again to see if there are any changes, disregarding their previously stored data.

It is usually expressed in seconds, though Cloudflare made it more human-friendly, by using minutes, hours and days. Still, you’ll often see the values such as: 3600 (1 hour), 14400 (4 hours), 86400 (24 hours ie. 1 day) etc.

It makes sense to set all the values that aren’t changed often to one day (86400 seconds). This provides your website visitors with faster DNS response, since DNS servers don’t have to often fetch fresh data.

Auto value for TTL that some records in picture 3 have is Cloudflare specific and I’ll explain it in a separate post.

– T.O.C. –

4.4. Content (also known as “points to”)

This can also be described as “value in the narrow meaning of the word”. Since DNS is used for directing Internet traffic for a domain, I’ll use the traffic analogy to explain: Content is a road’s destination, ie. “where the road leads to”.

Of course, some DNS records return text data, not an address (like TXT records), but the principle is the same – this will be clear by the end of this post.

– T.O.C. –

4.5. Name (also known as “Host”)

To explain this value, I’ll use the traffic analogy from the previous chapter. I said that Content value is where a road leads to. Name (Host) value says what the traffic sign, or desired destination is. I know it’s still not clear, but now it will be, just remember the previous sentences:

A man asks you: “where is New York” (Name / Host). You point to the road leading there (Content / points to). Well, technically, since Internet is structured that way, you would just give the man GPS coordinates, letting his navigation software lead him (IP routing), but I think this explains Name (and Content) values principle.

If it is still not crystal clear, don’t worry, it will be, read on.

– T.O.C. –

4.6. Types of DNS records (also known as DNS zones)

Types of DNS records (A, MX, TXT…) are also called “DNS zones” (“A zone”, “MX zone” etc.).

– T.O.C. –

4.6.1. A records (AAAA for IPv6) – Host records

You can jump to picture 3 for a reminder what it all looks like, while here’s a picture of only A records:

A records always show (server) IP addresses. They are also called “Host records”, or “DNS hosts”.

The first record says: ftp.ivetamakeup.com is hosted on a server with IPv4 address 172.217.22.4.

Your hosting provider will of course give you the IP address of your server – it can also be viewed from within your control panel. I’ll explain later how this is found within control panel, but for now we’ll just assume it is information that is known. For servers that (also) use IPv6 addresses, it is needed to add AAAA records containing and IPv6 addresses (that are a bit longer).

Hosting servers are usually configured to expect FTP traffic on ftp. subdomain, so that is used for FTPS and SFTP connections (uploading, downloading and editing files on the server).

ivetamakeup.com points to the same server as ftp.ivetamakeup.com (more precisely, ftp. points to the same server as the “main” domain, so we can connect and use FTP to edit files).

localhost A record is not really needed, but it does no harm. It leads visitors to their own computer’s local host (127.0.0.1), so there’s no load on your server in case someone mistakenly looks for localhost with your domain’s extension.

We could create another subdomain, such as shop.ivetamakeup.com, hosted on a completely different server and we would do that by adding an A record, like:
A shop. 173.218.23.5

How would we connect to that server using FTP? Creating ftp.shop.ivetamakeup.com A record will work, but we would not be able to install a free SSL/TLS certificate for that (it’s a level 2 subdomain – see my post on subdomain limitations).

I solve this by having a “main” account on a hosting server using a “working domain” (like developer12345656.com). Or you could use hosting provider’s server, it is usually provided when you create an account (“Temporary FTP hostname”).

– T.O.C. –

4.6.2. CNAME DNS records (also known as an alias)

CNAME DNS record type is often referred to as an “alias”. Our example:

What does this mean? First record in picture 5 says:
those looking for webmail.ivetamakeup.com should look for friday.mxlogin.com

In this case it refers the visitor to the MXroute mail service’s nameservers.

Second record says:
www.ivetamakeup.com is the same as ivetamakeup.com (ie. it directs visitors to ask DNS for ivetamakeup.com A record and see which IP address that record points to).

CNAME is an alias, so can never point to an IP address (like A records must). CNAME always points to another domain name. Technically, it could point to another CNAME, but that doesn’t make much sense.

Why wouldn’t we make an A record for www.ivetamakeup.com? We would if we planned to have ivetamakeup.com and www.ivetamakeup.com lead to two different servers (websites). Since that is not the case, by using a CNAME for the www. version, we are directing all those looking for www.ivetamakeup.com to ask the DNS for ivetamakeup.com. CNAME requests are much faster to process (they don’t return an IP address, but point to another domain). So this results in a bit more speed and fewer DNS records to be handled.

So we can make an A record shop.ivetamakeup.com, then make a CNAME store.ivetamakeup.com that points to that A record (shop.ivetamakeup.com). Everything that is in fact an alias, always the same, should be set using CNAME records.

To use the traffic analogy once more: you set GPS coordinates for “Los Angeles” (A record), then direct all those looking for “LA” to look under “Los Angeles (CNAME).

CNAME and A records can’t be duplicate. That is, you can’t set CNAME and A record for say www.ivetamakeup.com. Either one, or the other, but not both. Likewise, you can’t have two CNAME or two A records with the same domain name (Name column in picture 3).

– T.O.C. –

4.6.3. MX records

MX (Mail eXchanger) records are used exclusively for emails. They provide information on domain names of mail servers. From our example:

MX records in picture 6 are saying:
“For emails with domain ivetamakeup.com use friday.mxlogin.com mail server as a primary one (priority 10) and if it doesn’t work, try the secondary server (priority 20) friday-relay.mxlogin.com”.

Unlike A and CNAME records, MX records can be duplicate, as this example shows. They point to a domain name.

Technically, MX records can point to an IP address (like A records), but it is advisory to have them point at a domain name (like CNAME records). So, if you get just an IP address of your mail server from the provider, it is best to create an A record, like mail.mydomain.com, pointing to that IP address. Then create an MX record with value “mydomain.com” pointing to “mail.mydomain.com”.

– T.O.C. –

4.6.4. TXT records

Unlike all the other DNS record types, TXT records don’t point anywhere, but contain some text. This text is important for validation, authentication and configuring email SPF (Sender Policy Framework). I wrote a separate post explaining how to configure SPF, DKIM and DMARC values in DNS for successful email sending. Let’s see how it looks like in our example:

The first is a relatively newly introduced one, email related TXT record called BIMI (Brand Indicators for Message Identification). It contains a link to the (company) logo, saved in .svg format.

Second record shown in picture 7 is DKIM value (Domain Keys Identified Mail). To completely understand this, read the post about asymmetric encryption first. DKIM contains the public encryption key for domain’s mail servers. Sending server digitally signs the outgoing email (encrypting its hash value using the private DKIM key). Receiving servers can then decrypt the hash using the public DKIM key of the sending domain to verify it is authentic.

The last, fifth record, contains SPF settings (Sender Policy Framework), telling which hosts are allowed to send emails for the domain and what to do with emails sent from other hosts (again, this is explained in the above mentioned post about email DNS settings).

Third record contains DMARC settings (Domain-based Message Authentication, Reporting & Conformance). What is this? To put it simply, DMARC can be set to tell all the email servers:
“If an email fails either SPF, or DKIM validation, disregard it, it is probably someone pretending to be sending emails as @ivetamakeup.com – impersonating it.”

You understand now that SPF, DKIM and DMARC data is connected? That is why I explained them in this order.

Fourth record contains value needed to validate domain (ie. prove ownership) for Google Postmaster tools.

– T.O.C. –

4.6.5. PTR records

PTR records are used to prevent spam mails, by enabling something called “reverse DNS lookup”. They are like A records, but with switched places of Name and Content (points to) columns.

In other words: A record for a domain name (say example.com) will give the server IP address. PTR record, on the other hand, returns a domain name. For example, if a server gets an email from the IP address 72.17.222.44, it can perform a reverse DNS lookup for the IP address and if PTR record is properly set, it would return the sender’s domain. Failed reverse DNS lookup would raise suspicion it is a spamer trying to impersonate sender’s domain.

In our example, ivetamakeup.com is set to use MXroute mail servers, so PTR records are set with MXroute email service provider and their friday.mxlogin.com (see MX records chapter).

PTR records are usually set by the mail service provider, so regardless of whether you use hosting provider’s mail server, or a separate mail service, you won’t have to bother with these. For those using a VPS to set up their own mail server, make sure to configure PTR records in the DNS. In order for this to work, you must have ownership of the IP address in question, of course.

One IP address can have several domain names connected with it (mail1.provider.com and mail2.provider.com for example).

This concludes types of DNS records I’ll explain in the post. Complete list of all the types, with brief explanations can be found on Simple DNS website, in the article called: DNS Record types.

– T.O.C. –

4.7. Using asterisks ( * ) with DNS records (wildcard DNS records)

Almost all the DNS record types can be entered using an asterisk – ” * “. It is used to emulate any value, like a sort of a wildcard.

Let’s use the following DNS records for an example (note that wildcard * can be used with any DNS record type, not just with A records):
A ftp.ivetamakeup.com 172.217.22.4
A ivetamakeup.com 172.217.22.4
A *.ivetamakeup.com 8.8.8.8

Those querying an A record for “subdomain.ivetamakeup.com” would get IP 8.8.8.8.
Same goes for an A record query for “somethingelse.ivetamakeup.com”. BUT:
MX record queries with above noted domain names won’t work properly, because we didn’t define something like:
MX *.ivetamakeup.com 8.8.8.8
A query for “ftp.ivetamakeup.com” will return 172.217.22.4, because that record is defined, therefore takes precedence over wildcard records.

Likewise, in order to get a reply to an A query for “www.sudomain.ivetamakeup.com”, using wildcards, we’d have to define something like this:
A *.*.ivetamakeup.com 8.8.8.8 – or,
A *.subdomain.ivetamakeup.com 4.4.4.4

In that case, A query for “www.abc.ivetamakeup.com” would return IP address 8.8.8.8, while A query for “www.subdomain.ivetamakeup.com” would return 4.4.4.4.

Now I’ll list some rules for wildcard domains, some of which can be figured from the above given examples and explanations:

• Wildcard relates only to the subdomain level for which it is defined. To cover second subdomain level, an extra asterisk needs to be used ( *.*.example.com).
• Asterisk can replace only a complete subdomain level, ie. one can’t use: *.ive*keup.com, or sub*.ivetamakeup.com etc.
• It can’t be used for mid-levels, ie. *.*.example.com is fine, *.subdomain.example.com fine as well, but subdomain.*.example.com is not valid.
• Existing records always take precedence over wildcard records.

Wildcard records should not be used without a very good reason, and/or if one doesn’t know how DNS works. Good Wikipedia article on Wildcard DNS records.

– T.O.C. –

5. DNS records needed for a WordPress site

A basic set of needed records is shown in picture 3. This goes for websites that aren’t WordPress as well. There’s nothing WordPress specific with DNS-s, as far as I know.

The use and setup of most DNS record types was explained in chapter 4.6, but here I’ll give a brief list of the most important ones, to get your website up and running.

• DNS A type records for domains and subdomains you intend to use. This includes ftp.yourdomain.com and all the other used (sub)domains.
• CNAME records – used primarily for www. domain versions, the rest according to needs.
• MX records for emails. You get these record values set with your hosting provider (if using their email service), or from your mail service provider. I wrote a post explaining how it is set for using MXroute mail service. While a different post explains how to include service for bulk mail sending (like newsletters), using an example of SendGrid mail setup.
• TXT records, for domain validation. Very important for mail sending. Separate post explaining how to set SPF, DKIM and DMARC records.

– T.O.C. –

6. How to configure DNS records

I’ll explain briefly how this is done with cPanel, DirectAdmin and Cloudflare. The principle is the same for all the others. Pictures, with as little text as possible. If you have any questions, use comment section at the bottom.

6.1. DNS record setup in cPanel

Now you will see a list of DNS records already created by your hosting provider – automatically. You will probably need to edit TXT record with SPF information, unless you are using an external email service. This is all explained in chapter 5 (and chapter 4).

Now, whether you are adding a new DNS record, or editing an existing one, options are the same, shown in picture 11:

– T.O.C. –

6.2. DNS record setup in DirectAdmin

Now you will see a list of DNS records already created by your hosting provider – automatically. You will probably need to edit TXT record with SPF information, unless you are using an external email service. This is all explained in chapter 5 (and chapter 4).

Whether adding a new, or editing an existing DNS record, you will be given a set of options depending on the record type. DirectAdmin is a bit less intuitive than cPanel (in my opinion), so I’ll explain some record types in a bit more details. First the MX:

TXT record type can automatically fill in SPF data based on your chosen options. I find it easier to check the option “Edit Manually” and, well, edit it manually.

Principle is similar with all the other record types.

– T.O.C. –

6.3. DNS record setup in Cloudflare

This is what it looks like when adding a new record:

Cloudflare comes with a super-convenient option of exporting all the created DNS records into a simple .txt file:

In a separate post I provided a more detailed explanation of Cloudflare DNS setup.

– T.O.C. –

7. Conclusion

This post is long, congratulations if you red it entirely. It will probably take several re-readings, along with reading all the linked posts that explain certain topics in more detail. However, it will all eventually click into place. From then on, this post will be useful as a quick reminder/reference. So don’t worry if you don’t understand it all now. It will come. Bookmark this post and get back to it, as you improve and learn new things.

For all the questions, suggestions, or corrections, use the BikeGremlin forum.

– T.O.C. –