A lot of times DNS syntax gets treated like some kind of esoteric knowledge, given from on high and guarded by a select group of keepers of great secrets. And for good reason—it often feels like one false move can break your zone file, knock your website offline, and keep emails from arriving.
But, really, there’s nothing mystical about your DNS zone. Anybody can learn how to edit their DNS zones and manage their DNS settings.
But that’s not to say there aren’t pitfalls. We’re here to guide you through some of the most common mistakes we’ve seen and help you avoid them.
Syntax matters
If you’re a computer science or language nerd, you probably know what syntax is but in case you aren’t, think of it like grammar for DNS. And the DNS system is the most extreme grammarian that basically won’t accept anything that isn’t correct.
This is where the majority of these pitfalls come from—basically bad DNS grammar. You think you’re saying one thing, but the DNS grammar Nazi rejects it or misinterprets you.
Anatomy of a DNS record
Let’s break down really quickly what’s in a DNS record.
Every DNS record is composed of the above basic pieces.
The Name is what you’re defining in that DNS record. The TTL is the “Time to Live.” Basically, this controls how often a DNS server should check to see if this record has changed. That timeframe is in seconds. Type is the type of record it is. Each record type has a different function. A CNAME is also called an alias, and it lets you point one domain name to another. An A record lets you point a domain name to an IP address. An MX record points your domain name to an email server.
Common DNS mistakes
So with that brief explainer out of the way, let’s get into our list of common DNS mistakes.
1. Missing dot
When you point a domain or a subdomain to another domain name, that domain name has to end with a dot, or it won’t work.
Relative vs. Absolute Syntax or Fully Qualified vs. Partially Qualified
Here’s why: depending on your DNS provider or DNS interface, you might have to use relative syntax or you might have to use absolute syntax.
What’s the difference?
Think of it like first names versus full names. When you’re looking for someone out of every possible person existing, you for sure want to use their full name—first, last, middle—in order to make sure you’re looking up the right person (and even then, unlike with domains, there are duplicates).
But if you’re looking for someone in your own family, you don’t have to specify. You can just use the first name.
It’s the same thing with DNS. A domain’s full name, first, last, and middle name, is called the “fully qualified domain name” (or FQDN for short). That means you have to list the full domain name. And this is crucial—including the dot.
Why the dot? This represents “the root zone.” It’s what indicates that we’re talking about DNS and not some other naming system. You can actually read a domain name from right to left, hierarchically along the tree above. Let’s look at the FQDN news.gandi.net. :
- . – this puts us in the domain name system (DNS). Theoretically, a domain name could be outside of DNS, but let’s not go there
- .net – that puts us in the “.net” zone within DNS
- gandi – now we’re in the “gandi” zone in the “.net” zone, in DNS
- news – and this puts us in the “news” zone of the “gandi” zone in the “.net” zone, in the DNS system
But in a DNS zone, you can just use relative syntax, meaning that you just use the “partially qualified” domain name to make things simple. So within the gandi.net zone, ‘news’ can be a partially qualified domain name that’s easily understood to refer to the fully-qualified domain name news.gandi.net.
The pitfall here is when you point a subdomain to another domain name. That’s usually with a CNAME, ANAME, or MX record. If you don’t point your subdomain to the fully qualified domain name, then a zone using relative syntax will just think you meant the subdomain of the zone you’re in.
So if we create a CNAME that pointed news.gandi.net to the domain name gandi.net, but we forget to put the dot at the end to make it gandi.net., the record would get read as pointing news.gandi.net to gandi.net.gandi.net.
2. Not using @
This error is the flip side of the one above. In the Name column, you usually put the subdomain that you’re trying to define, so www if you’re defining www in the zone for example.com, or in other words, if this record is for www.example.com.
But what if you just wanted to put a record for example.com, no www? To represent your domain name, you use the symbol @.
The error, then, is in using something else, usually just typing out the domain name itself, instead of the @.
3. Duplicate MX records
Before you add new MX records for a new mail service on your domain name, make sure you remove the MX records of the existing mail service. Otherwise, you’ll end up making this error—setting up duplicate MX records that point to different places.
This error comes from the fact that it’s possible to have any number of MX records in your DNS zone to serve as fallbacks so that if your highest priority mail server isn’t available, the email you’re getting sent will still go to a fallback mail server and you’ll ultimately get the email.
But if you have MX records pointing to two different mail services, then you’ll end up getting some of your email with one email service and some of it with another one.
This error also happens when people actually want to redirect their email to another email service, and try adding new MX records in the hope that doing so will mean email gets delivered to both mail services.
4. Changing the TTL
This one stems from a misconception of TTL more than it stems from an syntax error.
The misconception is about the TTL or time to live on a record and usually the situation is that at some point in the past, the TTL on a DNS record is set to something very long, or at least longer than desired.
Then, the domain administrator wants to change the record and have it propagate quickly.
Essentially what the TTL controls is how long a record gets cached. We’ll save the explanation of DNS resolvers for another time, but suffice it to say that DNS servers out on the internet don’t constantly check all DNS records for updates every time they need it. Instead, DNS records get cached for a certain amount of time and that amount of time is controlled by the TTL.
Here’s the trick, then: when you set a new TTL on a record, that new TTL also has to propagate across the internet, or spread to all the DNS servers out there. And DNS servers won’t even check for the new TTL until their current cache has expired.
What this means is that people will update a DNS record with one TTL on it with a new record with a much shorter TTL with the expectation that that new record will go into effect quicker as a result.
In reality, there’s nothing to do that can make your records propagate more quickly. If you had a long TTL, you’ll just have to wait.
These are by far not the only mistakes you could possibly make in your DNS records, but they are some of the most common.
We hope you feel equipped to avoid the most common DNS pitfalls, but if you need help with your DNS at Gandi, feel free to contact our Customer care team.
Tagged in DNSNom de domaine
