Sooner or later, you will deal with a DNS CNAME Record. In fact, as an Internet user, you are unconsciously using these records all the time. Instead, PTR records are somewhat less common, but if you work for a larger company you should know about them.
In this post, we explain in simple terms what those two DNS records are. We try to give an easy, yet complete explanation. This way, you don’t have to be a master of DNS. Understanding these records can help you in many IT-related activities, like web development.
What to learn more about DNS? Your journey can start here.
What is a DNS CNAME Record?
As we know, Domain Name System has one major goal: translate domain names into IP addresses. That’s because network communications happen at the IP-address level, but humans don’t like that format too much. So, if you want to visit a website, you don’t have to remember its IP address. You just remember the name (like ictshore.com), and DNS translates that into an IP address.
However, DNS translates names to IP addresses with a specific type of record: type A. CNAME is a different type of record, and does something similar.
CNAME does not translate names with IP addresses but translates names with names. And, unlike an URL redirect, CNAME is transparent to the user. This means the user will always see the URL he has entered. You can use this type of record to do mainly two things:
- Catch users pointing to many domains
- Host your website on a third-party or cloud platform
Tip: some people call CNAME records alias.
Catching users
What do we mean by catching users that point to a different domain? Imagine you have a website (let’s say example.com), and you want to run a mail server as well. You configure the mail server on mail.example.com. However, mail is a complex environment. For example, you can download emails with IMAP or POP, two different protocols. You could configure your mail client (like Microsoft Outlook) to directly reference mail.example.com.
Yet, we don’t want to do that. We want to be granular. So, we create two CNAME entries: imap.example.com, and pop.example.com. Those records have the same value: mail.example.com. If the user goes to imap.example.com, to pop.example.com, or to mail.example.com he will always see the same thing.
What is the advantage? Maybe your users are used to a different URL, and you don’t want to leave them behind. Yet, this is not the greatest advantage. By adopting this configuration, you can later scale up more easily. If you want to add a separate IMAP server later, you already have users that prefer IMAP using a specific DNS entry, and you can change only that one. If everyone is pointing to mail.example.com, you need to tell your users to change their configuration.
Cloud platforms integration
Cloud is simply the future. Simple, scalable, with no upfront commitment. It allows people to achieve incredible things. So, it is natural you may want to use it!
There are many options to host a website in the cloud. For example, AWS – the market leader – offers several ways to create a serverless website. You may use lambda functions, S3 buckets, or CloudFront CDN. If you are interested, check their official tutorials.
All cloud hosting options have one thing in common: the website is not on your server, is in the cloud. Hence, if your website should be example.com, chances are on AWS it will be examplecom.cdn.aws.com, or something similar.
You don’t want your users to see the ugly URL that Amazon provides. You want them to reach you at the domain they already know. Well, this is easy to do: just put a CNAME on your domain that references the AWS “ugly” domain.
CNAME Limitations
While CNAME records are powerful, you cannot do everything with them. In fact, they have just one small limitation that may just hurt the more perfectionists of us.
CNAME records can apply only to subdomains. Yes, you heard right: you can make a CNAME record for sub.example.com, but not for example.com. Now, before you start yelling and head out to Google to find a way to do it, let me state it once more: it is simply not possible.
In fact, there is an actual standard that says so. I am talking about RFC 2181. Of course, this was not designed to simply be a source of pain. In fact, there are some valid reasons for it. In short, to prevent overuse of the DNS infrastructure by crawler and similars.
If you are interested, there is a wonderful article by Dominic Fraser that explains why a domain’s root can’t be a CNAME.
What is a PTR Record?
Now, the CNAME record was our main dish. Instead, the PTR record is a complex wine that only experts can fully appreciate.
Truth is, the role of a PTR (Pointer) record is astonishingly simple. It translates an IP address into a domain name. With a normal A record, you want to answer the question “What is the IP of example.com?”. Instead, with a PTR record, you want to answer “What domain is associated with IP 1.82.21.12?”.
So far so simple. But now, things start to get complicated. To create an A record (or CNAME), you need to be the owner of the domain. Then, you can insert any record you want, to any IP you want.
Instead, to create a PTR record (for public IP addresses), you have to own the IP address. And not owning it in a sense of leasing it from a provider, as 99% of the cases. I mean actually owning the IP, after having purchased the subnet from the IANA or your Regional Registrar.
This is not something the average Joe does. Only large companies can do that. However, note that a hosting provider often times owns the IP addresses it uses. So, it may allow you to set the PTR record for the IP they are leasing to you if you only ask.
Why having a PTR record?
This is the part where most people fail to see the importance of PTR records. And that’s because their role is not something needed every day, most certainly not by the average person. Not even by the average geek or website developer.
With PTR records, you can truly validate that an IP address is legitimately the webserver of a given website. With a PTR, you can prove that your other CNAME records were not corrupt. It is important to establish trust between systems, particularly in industries where trust is crucial, like finance.
Furthermore, it allows you to solve problems more quickly, enabling better troubleshooting. This is because you can quickly look up which website is associated with each IP you own.
In summary
To pack everything in a few phrases:
- CNAME records allow you to resolve a DNS name with a different name. The only limitation is that you cannot have them on your top-level domain, but only on sub-domains.
- PTR records start from the IP address and resolve with a name. To create one, you need to own the IP address, that is not something really easy or cheap. For most people, simply forget about PTR and don’t worry about it.
Hopefully, you have now the basics skill that will enable you to do some better cloud integration and catch a few more users on your website. Are you using CNAME records? Just drop me a comment.
