Traditional DNS Howto

Want to support HowtoForge? Become a subscriber!
 
Submitted by taft (Contact Author) (Forums) on Sun, 2006-03-12 10:43. :: BIND | DNS

Traditional DNS Howto


Version 1.0
Authors: Tom Adelstein <tom [dot] adelstein [at] gmail [dot] com>
Falko Timme <ft [at] falkotimme [dot] com>

Last edited: 03/11/2006

Linux system administrators should learn traditional DNS. Front-ends and quick templates to setup domain records have a place in managing sites. When confronted with DNS configurations already in existence, nothing can substitute for knowing and using the fundamentals.

The vast majority of users on the Internet have no clue about DNS. They may have seen the term when they set up their ISP connection, but they do not realize its connection to their lives. Simply put, DNS servers allow you to use friendly names in your browser, email or other Internet applications to perform tasks which require IP addresses.

The Internet uses TCP/IP protocol to send and receive everything on the Internet. When you type Google.com in your browser to do a search, you use DNS. Otherwise, you would have to use this numeric value: 64.233.187.99. Click on each one and see what you get.

You see Google.com is an name in a database that your browser consults to find the IP address of the Google web site. But that's transparent to the user. How would you like to keep a notebook of IP addresses to manually look up and find web sites you wish to visit? Well, the Domain Name System does that for you automatically.

If you're sitting there reading this and going, "Oh yeah, I already know about that", then hold on a minute or two. Working with DNS requires considerable knowledge and discipline. The system administrators I know can do many tasks, yet few can handle DNS. Almost without exception, they get lost because they don't understand the fundamentals.

The Domain Name System of the Internet makes up the largest distributed database on the planet and it's quite ingenious. In theory, it has no flaws. In practice, people kludge it up all the time. People make DNS entries in their part of the database that aren't formatted correctly or have inherent deficiencies which result in errors.

Internet surveys of DNS records have shown incidents of errors as high as 72%. We know the majority of those errors come from lame delegations. Lame delegations include domains registered with DNS servers assigned to them when no one is actually hosting the domain. Other causes include the failure to provide zone files, errors in resource records, expired domain registrations.

If you attempt to learn DNS jargon, you will find that it is not intuitive. At first it just doesn't make sense. In many ways, the jargon reminds me of a foreign language. You just have to work with it for a period of time before it makes sense.

Linux uses BIND to perform DNS functions. Rather than attempt to use another program, system administrators should start with BIND because it runs almost all the DNS servers in the world. I'm not going to offer a history lesson on BIND because this subject will put you to sleep anyway.

So, if you want to go forth and learn all about BIND please do. It won't help you do much DNS with one exception. Some people still use BIND version 4. You want to upgrade from BIND 4 to BIND 8 or 9. It's just my luck that you'll go out to create DNS configuration files and they won't make any sense. That's because a lot of people still run BIND 4.

Tell Me About Configuration Files

BIND comes with three components. The first components we called named or name-dee. It's a daemon that runs the server side of DNS. That will make sense in a little while.

The second component of BIND we call the resolver library. People think of a resolver as the client side of BIND. The resolver code makes queries of DNS servers in an attempt to translate a friendly name to an IP address. This component uses the resolv.conf file. Does that sound like a UNIX abbreviation. It should because it is.

The third component of BIND provides tools for testing you DNS server. We call them tools but they are really a set of command line utilities like dig. Go to your console and type dig yahoo.com and see what happens. We will look at this later.

What's My Responsibility In The DNS System?

As stated earlier, DNS is a distributed data base. When you pay a fee to register a domain one of the questions you answer deals with your Name Servers. You have to list two and they have to be registered in the DNS system.

The domain name system database has three levels. The first group of servers we call "root" servers. The second we call Top Level Domains or (TLDs). When your resolver needs to find the address for a web site, it makes a query.

Let's say you want to find Google.com. Your resolver asks the Root servers to identify Google.com's IP. The Root server replies, I don't know but I do now where you can find the answer. Start with the TLD servers for COM.

So, Root sends your query to a COM server. It says, OK. I don't have that information but I know a Name Server that does. It has an address of 64.233.167.99 and the name ns1.google.com. So, go to that address and it will tell you the web site address of google.com

Your resolver takes the information from ns1.google.com and returns with an IP address. If Google's name server gave your resolver the correct name, you'll get a web page.

The path traveled looks like Figure 1.



Figure 1 - From Root to your Domain.

In the upper left of Figure 1, we have depicted a set of servers with the annotation of Root. In the jargon of DNS, these servers represent the beginning of the DNS path. You will see them represented by a period or dot ("."). In your configuration files, your IP address to name mapping will end with a period. When we look at some of those files in a few minutes this will become clearer.

The Root servers are the top of the distributed DNS database. They have information about the Top Level Domains(TLDs). TLDs include com, net, org, mil, gov, edu, etc. When you contract to use a domain name, you chose which TLD you want. In my case, I have a domain in the org name space called centralsoft.org.

When I registered my name servers, I gave the name of server1.centralsoft.org and ns0.centralsoft.org to my registration agent. In the TLD servers for org, you will find my name servers. The org servers know where you should find information on centralsoft.

When I registered, I told the agent that I would take responsibility for maintaining a database of IP addresses and friendly names and map them to one another. So, we made an agreement and the Domain Name System said, "OK, now you have authority for the data on centralsoft.org. When someone wants to find the services you offer on the Internet, we will point them to you."

So, now I have to run an application which can answer your queries and say, "sure if you want to see my web page or send mail to one of my users, you can find them here. If you ask me for a name, I'll give you an IP address because I know you have this protocol which uses TCP/IP and I realize you need the address, even when you specify a name".


Please do not use the comment function to ask for help! If you need help, please use our forum.
Comments will be published after administrator approval.
Submitted by phpotes (registered user) on Sun, 2007-03-11 11:50.

Thanks for this clarification on DNS.

Just want to add that reading the logs is basic for troubleshooting and if your sec. runs on another machine (shouldn't it be...) make sure that both machines (servers) are synchronized on time (helps if both have ntp) otherwise you'll wonder why zones don't transfer.

Submitted by Anonymous (not registered) on Sat, 2006-05-20 23:30.
I have spent a lot of time trying to learn DNS and have read A LOT of "How-to's" on the subject. This how-to is hands-down the best I have seen. Well done!
Submitted by Anonymous (not registered) on Tue, 2011-09-13 10:52.
i am first timer but managed to configure to run! Well done, thanks a billions!
Submitted by Anonymous (not registered) on Fri, 2006-04-14 19:35.
Though this work looks good, it is almost all written from a BIND perspective. Some focus on using tools to troubleshoot problems would be good.

Mention of alternate DNS packages would be good, especially for running the various DNS roles (caching, authorative). BIND is especially bad running as a cache and auth from the same daemon.

Finally, the expected plug: http://www.lifewithdjbdns.org/ .

Submitted by Anonymous (not registered) on Thu, 2006-04-13 13:33.
1) Restricting zonetransfers is useless. Anyone with secret data in public dns is doing something wrong anyway. Restringing zonetransfers just makes it harder to debug dns problems.

2) Make it clear that recursion should be disabled on nameservers. Never use the same dns as both nameserver and resolver. Public resolvers helps doing dns amplification DoS attacks. (http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf)

Submitted by Anonymous (not registered) on Sun, 2006-03-12 16:55.

IMO you should at least mention dynamic DNS updates, a method of editing your zones remotely from anywhere on the Internet:

http://linux.yyz.us/nsupdate/

http://linux.yyz.us/dns/ddns-server.html

Submitted by Anonymous (not registered) on Tue, 2006-03-21 08:12.
I don't think dynamic dns has much to do with traditional DNS configuration. It certainly deserves a Howto of its own, but I don't see it as applicable to this article.