Posts by Mark Pace

Found some really good information on DNS and rather than reinvent the wheel, I thought I would share this with you.
Credits at the bottom of the article.

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 records
Basic 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 records
DNS 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 records
So 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 rDNS
There 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 records
Another 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.

1. You should never point a MX record to a CNAME.
2. You should never point a NS record to a CNAME.
3. You shouldn’t point a CNAME to a CNAME as it could create a never-ending loop.

SRV records
Corporate 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 DNS
Let’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.