DNS is like the yellow-pages of the Internet. It can be confusing at times, and there are some common DNS mistakes that many novice and even experienced DNS administrators make. Here are the top most common DNS mistakes and solutions for them. Do not let misconfigured DNS settings break your website.
Using a CNAME for the Main Domain
A CNAME is a record that points one domain to another. This can be used to point www.example.com to example.com. That way any time a user attempts to go to www.example.com, they are instead sent to example.com.
So while a CNAME is a useful DNS tool, you should never use it for a main domain name. What I mean by main domain name is the domain right above the top level domain. example.com would be one such main domain name. Adminhacks.com is another. This is the opposite of subdomains. A subdomain would be something like mail.example.com or www.example.com or subdomain.example.com.
The reason to only use CNAMEs for subdomains is that a CNAME takes precedence over all other DNS records. If a CNAME is created for example.com, then the NS records, the A records, the MX records and all other records will be ignored. If the NS record is unavailable because the CNAME is found instead, then this can create a loop and DNS might fail altogether. The website might not be found at all.
The solution is simply to not use CNAMEs for the main domain name. If you want to forward the main domain name to a subdomain, do so using a different method, such as a .htaccess 301 redirect.
This is wrong:
example.com CNAME www.example.com
And this is good:
www.example.com CNAME example.com
The first points a top domain to a subdomain. The second points a subdomain to the main domain. If you want to have any other DNS record usable for that domain or subdomain, then avoid CNAMES. Do not use CNAME records when you want other records to be accessable for that domain/subdomain.
NS and MX Records Pointing to IP Addresses
This is a less serious issue as it usually doesn’t break much. It is a mistake to point an MX or NS record at an IP address rather than at a hostname. A hostname should have am A record which will provide DNS with the IP address, and no other records should have an IPv4 address.
The point is to only have a single IP address per DNS host. If you have an MX record and an NS record and an A record all pointing to an IP address you have to update three different records whenever an IP address changes. This creates a higher chance of messing something up or forgetting to update one of the records.
This is incorrect:
example.com NS 10.10.10.5
example.com MX 10.10.10.2
example.com A 10.10.10.2
example.com AAAA 2001:db8::2
The above is bad because anytime an update has to be made then all the records have to be updated. The above is also bad because though there is an IPv6 address and there is an A record for that address, there is no MX record or NS record for the IPv6 address.
This is correct:
example.com NS ns.example.com
example.com MX example.com
example.com A 10.10.10.2
example.com AAAA 2001:db8::2
Now there is only a single record for the IPv4 address and a single record for the IPv6 address. In this example both IPv4 and IPv6 are used for email because the MX record can use either the A or the AAAA record.
The RFC and industry standard is to set the MX and NS DNS records to point to a hostname not an IP address.
IPv4 Pointing One Place, IPv6 Somewhere Else
With the adoption of IPv6, DNS gets slightly more confusing. Not by much, but as seen above, the more records that need updating when a change happens, the more likely a mistake will be made.
It is not uncommon for DNS administrators to move a webserver to a different IP address and remember to update the IPv4 A record, but forget all about the IPv6 AAAA record. This leads to a very confusing issue. Some people see the new webhost, and some see the old webhost. This is especially confusing when the two webhosts are serving different versions of a website.
If customers complain that an old version of a website is showing up on some computers but not on others, make sure that both IPv4 and IPv6 are pointing to the same webserver. Same thing when email mysteriously arrives from some senders, but not from others.
Check that A and AAAA records both point to the correct destination.
Leaving the TTL at a Low Value
The Time to Live (TTL) is a DNS setting stating how often the Internet should check to see if there have been any updates in the DNS settings for a domain name. Setting the TTL to a low value, such as 300 seconds (5 minutes) is a fantastic idea when making changes to DNS records. This will allow you to revert or fix any mistakes within five minutes. I always change the DNS TTL to as low a value as possible when making changes.
However, once the DNS settings have been tested and everything is set in the correct fashion, it is a good idea to raise the TTL to as high as possible. This is usually 24 hours. The reason is that sometimes DNS servers have problems and become unavailable. If the TTL for your website is set to five minutes, and the DNS server goes down for one hour, then your site becomes unavailable for at least 55 minutes to the whole world.
However, if your authoritative DNS name-servers go down for an hour, but the TTL of your DNS records is set to 24 hours, then there is a good chance a large portion of the Internet will still be able to access you website. The reason is that local DNS servers will have a copy of your DNS record which has a TTL of 24 hours. They will use that copy of the DNS record until those 24 hours end. For those 24 hours they will not look for an update.
The parts of the Internet that do look for an update will not be able to reach the DNS server which hosts your records, and will not know where to send users who want to visit your website.
To avoid website downtime, when you are not making changes to DNS, set the TTL of all of your DNS records to as high a number as possible.
Making DNS Changes on the Wrong Server
Your DNS record has a single authoritative DNS server, which the rest of the Internet looks to to find out DNS information about your website. This authoritative name server is set by your domain name registrar. That is the company from whom you purchased your domain name. Many of these companies offer free DNS services, but there are other free DNS services that are not tied to registrars, along with paid DNS services. Many webhosts provide DNs service with their webhosting.
If you want the DNS changes you make to take effect and be seen by the world, you must make them on the correct DNS server. Check with your registrar who your authoritative name server is. You can also use the ‘dig’ command on a linux or mac to see who the authoritative name server for your website is:
dig ns example.com
The above would show you who the authoritative name servers for example.com are. That is where you need to make any DNS changes.
There are of course other ways to break DNS. However, if you can avoid the above DNS mistakes, you will be far ahead of many other DNS administrators.
