Formatting Domain Name System (DNS) Records and the Trailing Dot

When you add a record to prove control of a domain for an SSL Certificate, the value you enter is usually correct. What changes between one Domain Name System (DNS) provider and the next is how that value must be written. The most common point of confusion is a single character at the end : the trailing dot.

One control panel wants the dot left off and adds it for you. Another treats the name exactly as typed and needs the dot present. The record is the same in both places. Only the notation differs, and that is what this article explains.

If a record works only after you remove the trailing dot, nothing is wrong with the value you were given. Your software simply belongs to the group that adds the dot for you. Understanding why makes these records quick to enter correctly the first time.

What the Trailing Dot Represents

Every name in the Domain Name System is read from right to left, starting from a single unnamed point called the root. The root sits above the top-level domains such as .com, .org, and .net. The trailing dot is how that root is written.

A name written with the dot at the end is complete. It names every level from the host down to the root, with nothing left out or assumed. That is what makes it a Fully Qualified Domain Name (FQDN).

www.example.com.

Read from the right, that is the root, then .com, then example, then the host www. The final dot is easy to miss, and many interfaces hide it, but in principle it is always there.

Absolute Names and Relative Names

The trailing dot marks the difference between two ways of writing a name : absolute and relative. Which one your software expects decides whether you include the dot.

An absolute name ends with the dot and is taken exactly as written. Nothing is added to it. It is the full name, from the host all the way to the root.

A relative name has no trailing dot. The Domain Name System software treats it as incomplete and appends the zone name, called the origin, to finish it. A relative name only makes sense inside the zone it belongs to.

So the dot is not decoration. It tells the software whether to leave the name alone or add the zone name to the end. Enter the wrong form and the name that gets stored is not the name you intended.

One Target, Two Notations

A worked example shows why the same correct target is typed differently in different places. Suppose your zone is example.com and a validation step asks you to point a record at the target below.

dv.trustico.com

In software that reads the value literally, you must include the dot. Leave it off and the software adds your zone name to the end, turning a correct target into a broken one.

dv.trustico.com.example.com.

That doubled name is the single most common Domain Name System mistake, and it is exactly what happens when a trailing dot is missing where the software required one.

The opposite case is just as common. In a control panel that adds the dot for you, typing it yourself produces the same doubled name. Here you leave the dot off and enter the target on its own, and the panel completes it correctly.

The Name Field and the Value Field

Most records have two sides : the name on the left and the value on the right. The trailing dot behaves differently in each, which is another source of confusion.

The name field, sometimes called the host, is where you put the record label. In almost every control panel you enter this part relative to your zone, so for a validation record you would type the label only, not the whole name.

_acme-challenge

The panel adds your zone automatically, so the stored name becomes the full one below.

_acme-challenge.example.com.

The value field is where absolute and relative names matter most, because a target such as a CNAME points at a name in a zone that is often not your own. If the software appends your zone to that target, it breaks. This is where the trailing dot earns its keep.

Zone Files and Hosting Control Panels

Whether you need the dot comes down to which kind of software you are using. There are two broad groups, and they treat the dot in opposite ways.

Raw zone files, such as those used by BIND and tools built on the same format, are literal. A name without a trailing dot is relative and a name with one is absolute, so the dot genuinely changes the meaning. Here you include it on every absolute name.

Most hosting control panels and provider dashboards hide the concept. They expect the value without a trailing dot and add it for you behind the scenes. Type the dot yourself and some reject it, while others accept it and then double your zone onto the end.

This is why the same record entered into a zone file and into a hosting dashboard looks different. The record is identical. The interface decides the notation.

Records Used for SSL Certificate Validation

For SSL Certificate issuance, the trailing dot shows up in the records you add to prove control of a domain. A few record types come up repeatedly.

Some validation methods ask you to add a CNAME record that points at a target given during your order. Because the target lives outside your zone, the trailing dot rule applies to it directly, and a missing or extra dot is a frequent cause of failure. Read About Troubleshooting CNAME Records 🔗

Other methods use a TXT record, most often for the Domain Name System based challenge used by automated issuance. The label is usually _acme-challenge followed by your domain, and the value is a string given by the Certificate Authority (CA). Explore Choosing an ACME Challenge Type 🔗

_acme-challenge.example.com.  IN  TXT  "3x9K7Qp2verification-string-from-your-order"

A Certification Authority Authorization (CAA) record is a different case, since it controls which authorities may issue for your domain rather than proving control. When a single SSL Certificate covers several names, each name can need its own validation record. Read About CAA Records 🔗

Checking What Your Software Expects

You do not have to guess which group your software belongs to. A quick check tells you.

Enter the value without a trailing dot first, since that is what most panels expect. Then look at how the record is stored or how it resolves. If your own zone name appears doubled on the end, the software added the origin and you should leave the dot off.

If instead the target resolves as though it were shortened or incomplete, the software expected an absolute name, so add the trailing dot. A single lookup after saving confirms which way your software works.

With that one check, the trailing dot stops being a mystery and becomes a property you can read straight from your own software.

When a Record Still Does Not Resolve

If the notation is right and the record still does not work, the cause is usually elsewhere.

New and changed records take time to spread, and old answers can stay cached for as long as the previous record allowed. Waiting, then checking again with a fresh lookup, clears most of these cases.

Occasionally a record is correct but the answer served inside your network differs from the one the public sees, which stops an external check from finding it. Read About Split-Horizon Resolution Problems 🔗

Correctly Formatted Records and SSL Certificate Issuance

A validation record only does its job when the Certificate Authority (CA) can look it up and read the expected value. Correct notation is what makes that possible, so the trailing dot is worth getting right the first time.

This matters most for a Wildcard SSL Certificate, which can only be validated through a Domain Name System record rather than a file on the server. Learn About Wildcard SSL Certificates 🔗

Where a validation record can stay in place, leaving it there lets later issuance and reissue reuse it without repeating the step. Review Keeping Validation Records in Place 🔗

The value you were given is almost always right. Match the trailing dot to what your software expects, and the record will resolve and validate as intended. Understand The Validation Procedure 🔗