DNS - The Big Picture

By Joshua Erdman
Digital Foundation, inc.

With a good foundation of what DNS is I was able to focus on how I should best implement it at my office. Since it was already pitifully implemented, I had to go through all our existing domains (over 200 of them) and clean up the mess. I ran across bad entries, invalid serial numbers, and absolutely no documentation. There was no consistency from one domain config file to another (thank God for Perl Scripts).

Now that I got everything standardized, I could look at the big picture. There is much to consider with how you choose to implement DNS:

What DNS Server software was I going to use?
What Operating System was I going to run it on?
How was I going to Structure our company's domain?
How critical are our DNS servers?
How much time should I focus to security?
What level of redundancy should I consider?

Choosing an operating system and DNS Software these days is pretty easy. Today, you have 2 options available to you Microsoft DNS and Bind (the Linux DNS server). In my situation, I choose to use Bind running on a Linux operating system to keep my boss at the time from fiddling around with the new setup. In that situation, everyone won, I had piece of mind in the extra job security I created and he didn't get the crap beat out of him from messing with my new system.

DNS Structure was a whole other complexity. I could increase the grangularity of all our company's equipment by using four segments instead of three. This way much of the equipment would be listed as comuter.department.company.com instead of just computer.company.com. I decided three segments was enough. The division of our departments were not that defined.

At first Security seemed pretty simple, I mean this was DNS, I wanted the Interent to have the access needed to query my domains. At first I felt that all I needed to do was make sure my DNS software remained current so no one could hack in and mess things up. Then a friend pointed out to me that I could be providing very important information just by how I listed my hosts in our domain. He asked me, "Do you want to display to the whole world that router.company.com is your router? It would be better to use something more stealthly such as samson.company.com." I was aware of this type of security, called security by obscurity, but it never occurred to me to apply it to DNS.

The last thing to consider is redundancy. DNS Servers typically do not need an extreme amount of horsepower just to serve DNS. You could build secondary servers and locate them at other companies to have a DNS presence even when your facility is having problems. Since the Secondary DNS Servers just pull a copy of the Domain Record from the main server, they wouldn't even need tape backups. Overall, Secondary DNS Servers are very low maintenance and redundancy should be easy.

In the next article I will go over DNS records including A Records, CNAME records, NS records and MX records.

References:

There is so much more to DNS, here we only cover usineg DNS with 3 segments such as mail.company.com or www.company.com but there are ways to get more grangularity such as listing departments in the 3rd segment and devices in a 4th segment. To get more information about this the O'Rilley and Associates book: DNS & Bind is a great resource.

Read the article that explains the steps of resolving a domain name. I also have available my PowerPoint presentation I gave when speaking to the SLO Bytes PC User's group on DNS resolution that is basically written from this article.

Article last reviewed: 01/29/2003

Created by: Digital Foundation, inc.

All content of the NetworkClue website is copyrighted. Articles, notes, outlines, and all other materials may not be stored on the Internet or sold or placed by themselves or with other material in any electronic or printed format in whole or part. However materials may be referenced by links to the site.