This is the 223rd article in the Spotlight on IT series. If you'd be interested in writing an article on the subject of backup, security, storage, virtualization, mobile, networking, wireless, cloud and SaaS, or MSPs for the series PM Eric to get started.

DNS (Domain Name System) is a simple service many in IT don't understand. It’s essentially the phone book for any network — especially the Internet. When you surf the web you use DNS. If not, you would have to remember every system’s IP address you wanted to visit. Instead of Google.com or Amazon.com, you would have to remember 74.125.239.82 and 205.251.242.54 and every backup IP address they use for load balancing the traffic.

There are many different providers of DNS. They're your ISP (home or business), Google, Level 3, OpenDNS, DynDNS, etc. Your home ISP will often provide features like search assist or phishing block to help protect you while you're searching the web. Google (8.8.8.8 and 8.8.4.4) and Level 3 (4.2.2.1 and 4.2.2.2) provide DNS servers that don’t block any requests (unfiltered) so you don’t have to use your ISP's DNS services if you don’t want to.

OpenDNS and DynDNS offer services — for pay and for free — that allow you to control what kind of sites you wish to block and what sites you wish to allow. Pay accounts often give you more control down to individual sites rather than categories of sites. This is a popular method for securing home Internet service to protect kids from looking at content you don’t want them to look at — without having to hover over them as they browse the Internet. It’s also good for protecting you from phishing scams.

A recordsBasic DNS records are called A records. These are Address Records for a hostname. For example, if you look at the A records for www.google.com you will find several entries that include 74.125.227.209, 74.125.227.210, 74.125.227.211, 74.125.227.212, and 74.125.227.208 as well as one that looks different than the others: 2607:f8b0:4000:803::1013. This one is IPv6 where the others are IPv4. Having multiple records like this doesn’t give true load balancing. If you surf to www.google.com and DNS tells your system that it needs to contact 74.125.227.209 and it doesn’t respond, your system doesn’t ask again — it gets 74.125.227.210 and continues. It will ask the question once and if it gets an answer (even one that states the address can’t be resolved) your browser will attempt to connect to it and return the web page or a “page doesn’t exist” error page.

MX recordsDNS records are also used to route email around the Internet. These are called MX records. They usually point to a group of computers that are responsible for receiving mail for the organization. Each entry will have a priority associated with it — this provides a failover so if one mail server isn’t responding, the sending mail server can try the next one in the list.

NS recordsSo what are DNS servers called in DNS records? NS, or Name Servers, are the servers that are responsible or have authority for the domain zones they host. This also helps with replicating the changes in the DNS zone between servers that are responsible for each DNS zone.

PTR records and rDNSThere are also reverse records called pointer (PTR) records. These help with security. If a system receives email, it knows what IP address it came from. It will do a reverse DNS (rDNS) lookup to see what domain name it came from. Then it compares this with the MX records to see if this server is registered as an email server. If not, it can reject the email as spam.

Another use is in network troubleshooting when you know the IP address but don’t know the system name. PING and TRACERT (trace route) commands will show you the IP address and the DNS name.

CNAME recordsAnother popular record type is a CNAME. This is a Canonical NAME record — think of it as an alias record. It is used when one IP address is used for multiple services. For example, let's say you have a website named www.yourwebsite.com and it has an IP address of 10.1.2.3, but you also have other services you wish to publish, like FTP.

Rather than making another A Record for ftp.yourwebsite.com, you can make a CNAME for ftp.yourwebsite.com and point it (alias) to www.yourwebsite.com. When/if you change the IP address for your website (change of providers), then you only have to update one record (the A Record) for www.yourwebsite.com and all of your CNAME records will automatically be redirected to the proper IP address.

However, there are some rules that should be followed with CNAME records.

You should never point a MX record to a CNAME.

You should never point a NS record to a CNAME.

You shouldn’t point a CNAME to a CNAME as it could create a never-ending loop.

SRV recordsCorporate DNS used for Active Directory Domains takes this further and includes records that help computer systems authenticate on the network and determine what domain controller is closer, what file server is closer, what the email server auto-setup should be, etc. These records include SRV records that are used for Kerberos, LDAP, and other services as the domain needs to function.

So what system holds the DNS for corporate servers (Active Directory)? Active Directory servers run DNS service that clients — other computers on the internal network — will point to them for all DNS needs. It’s up to the internal DNS servers to decide if the request is for an internal (private) record or for a public record.

If it needs a public record, there are several ways a DNS server can find the information. It can point to a set of servers either for all domains or for just a specific domain. It can use root hints to direct traffic to the proper public DNS servers. Or, it can also use a combination of the two — depending on the needs of the organization.

If you have an Active Directory environment and you point your client (or the DNS client on a domain controller/DNS server) to a public DNS server, your domain won't function properly. The public DNS servers won't have the records for your private DNS zone and won't have any way to get them if your client requests it. This will prevent your computer from authenticating on the domain, joining the domain, connecting to your email server, surfing your corporate intranet, etc.

Split DNSLet’s say you’re in a corporate environment. You have a web server that you list as www.yourwebsite.com with a public DNS record of 74.125.227.210 (this is Google’s IP address — I’m only using this as an example). But, you’re inside your network and your firewall won't allow traffic to go out, make a u-turn and come back in so you can’t get to the website. How do you resolve this for your internal clients? You make a split DNS.

This means there is a public DNS zone for yourwebsite.com that contains an A Record for www. that resolves to 74.125.227.210 and you have an internal DNS zone (on your domain controller or domain DNS server) that also has a zone for yourwebsite.com but has an A Record for www. that resolves to 10.1.2.3 (the internal IP address for the same web server).

Now your client on the inside of your corporate network can communicate with your web server at www.yourwebsite.com. If this is a mobile device, you could move between networks (corporate, public Wi-Fi, home) and still have access to the website. Of course, with this split DNS zone, you’ll have to enter every record that’s in the public DNS zone or you will break the other records while on the internal network.

Another split DNS zone implementation is to do it just for the record you wish to redirect. You would create a DNS zone for www.yourwebsite.com and have the default record resolve to 10.1.2.3 — this way you only have to maintain one record internally instead of every record that is in the public DNS zone.

Have any questions or tips about DNS? Share your DNS-related queries, quandaries and pointers in the comments below!

Good right up. Many a young IT, depending on their background have DNS issues. And sometimes there is more than one way to solve DNS issues, but generally, if you don't understand it, look up an article like this one and learn a bit before bringing the network to a snail's pace. I've personally had to fix DNS issues at a handful of companies.

Having at least a basic understanding of DNS (and other network standards) is essential to success in IT. I worked with techs for years who refused to get even a basic understanding and would call me with the same issues over and over. If they took the time to learn even a little bit about it, they would have been able to fix many more problems on their own.

For some of us, split DNS isn't a choice. Its usually a case of the previous admin not having a clue what he's doing when creating a domain. For most AD implementations a .local suffix will do. If you have hosted Exchange and use split DNS, you know what a pain that is dealing with locked accounts due to Outlook.

I agree with ArgMen2009. An article on split DNS, especially in an AD environment would be nice. I am currently doing it an ugly way, if the DNS I want to internalize is outlook.domain.com, I create a new zone called outlook.domain.com and then create an A record to the internal IP. Its an ugly hack but it works for our environment.

I assume the SRV -> SVC typo was due to a rogue auto-correction? Other than that I have two comments:

CNAME records should be avoided whenever possible. Multiple A records work much better as long as you can control the IP address pointed to.

The PTR / rDNS section is a bit misleading. Although it is very common for anti-spam zealots to use reverse DNS, it is illogical to check that the address resolves to a name "registered as a mail server". MX records are used for addresses used to receive mail, not necessarily to send it. And even if used for both sending and receiving, servers serving several domains are unlikely to have a PTR record for each of them. SPF or the equivalent TXT record would be much better for authenticating the sender.

Before this article I had an extremely basic understanding of DNS. After reading the article I feel a little more confident about DNS and what it really is. I will be sure to read this article again and also read something to supplement this as I never knew how complicated DNS could really be.

Even if you use a .local TLD for your internal network, there are still cases where you would use a split DNS. Its often better to tell your users to use one website like webmail.company.com instead of telling them to use one internally and a different one externally. And for the mentioned scenario where you don't want traffic trying to do a U-Turn on your firewalls.
You can always set it up to forward unresolved hosts back out to a different path if you don't want to have to list every external host in your split zone.

For some of us, split DNS isn't a choice. Its usually a case of the previous admin not having a clue what he's doing when creating a domain. For most AD implementations a .local suffix will do. If you have hosted Exchange and use split DNS, you know what a pain that is dealing with locked accounts due to Outlook.

At one point, Microsoft were advising against the use of .local as it caused problems with mDNS and the advice was to use a subdomain of a domain you own.

As more mDNS based software appeared, I've stuck with split or a subdomain and had no headaches.

It's all fully documented, so if I get hit by a bus, whoever comes after me will be good.

For some of us, split DNS isn't a choice. Its usually a case of the previous admin not having a clue what he's doing when creating a domain. For most AD implementations a .local suffix will do. If you have hosted Exchange and use split DNS, you know what a pain that is dealing with locked accounts due to Outlook.

All of our sites use split DNS and I consider it essential to do so, Primarily for flexibility of registering SSL certificates which isn't going to work well for much longer if it isn't a verifiable domain.

I have yet to find a site that has an issue with a hosted exchange environment either. If you configure the correct DNS internally on the DNS server hosting the split DNS to point to the correct records externally then it isn't a problem. IIRC an MX record and an Autodiscover A record plus another A or possibly an SRV record is all what's needed for Office 365. It then even auto configures the Outlook account as normal if you install the Office 365 AD synchronisation tools too (if you're game to do so, and aren't too hyper sensitive about the AD).