Traditional DNS Howto


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

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".

Share this page:

26 Comment(s)

Add comment

Comments

From: Anonymous at: 2006-03-12 15:55:03

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

From: Anonymous at: 2006-03-21 07:12:40

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.

From: Anonymous at: 2006-04-13 12:33:52

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)

From: Anonymous at: 2006-04-14 18:35:41

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/ .

From: Anonymous at: 2006-05-20 22:30:55

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!

From: Anonymous at: 2011-09-13 09:52:02

i am first timer but managed to configure to run! Well done, thanks a billions!

From: at: 2007-03-11 10:50:27

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.

From: Makarand at: 2010-02-14 15:47:42

This tutorial is truly outstanding. I was able to follow it and get my DNS server up and running for my local LAN in less than an hour. Excellent work, guys. Deepest gratitude !

From: Anonymous at: 2009-12-14 22:05:03

This article is actually good, even if you only want to know about how DNS works.

Thank you.

From: Son Nguyen at: 2012-07-04 10:20:37

One billion thanks to author!
This is a very very very useful article.

From: Anonymous at: 2006-03-18 12:03:01

This is a superb howto. Also reminding us again the power of Linux that is we are free to configure it down to the configuration files. Many thanks :)

From: Anonymous at: 2006-04-11 04:20:25

the best tutorial for dns i've ever seen... woulda been nice to have this 2 weeks ago...

From: Anonymous at: 2006-06-14 05:48:33

wow that's great HOWTO ,job well done ,more power keep up the good work dudes!!!

From: Anonymous at: 2008-12-20 12:42:55

Excellent !

From: sujay at: 2012-11-27 22:55:07

It's really really awesome !!!!

From: Anonymous at: 2006-04-20 17:13:39

This is indeed the best DNS tutorial I have ever read.

I would definitely say that the author did a commendable job indeed.(SPF information was the crowning jewel

Well done,

Hope to see some more articles in the same tone.

From: Anonymous at: 2006-04-21 16:05:06

A DNS server on the Internet should normally only answer queries for the domains it is authoritative for. But unless you configure it otherwise bind will pass on requests for other domains up the hierarchy. This means it can potentially be used in a Denial of Service attack against other DNS servers. You can prevent this by restricting lookup via other DNS servers only to devices you trust. To do this add another line to the options section in the form...

options {

  ...

  allow-recursion { trusted.IP.subnet; };
It will still answer queries from anywhere for domains for which it is the authoritative server, but will now only do lookups via other DNS servers for requests from the trusted subnet.

From: Anonymous at: 2006-05-15 02:11:29

This HOWTO imho puts DNS in layman terms. I truly appreciate it.

Now to tackle my own little DNS venture :D

From: Anonymous at: 2006-06-14 05:52:31

wow that's great HOWTO,

job well done,keep the good work dudes!!! more power!!

From: RChan at: 2009-04-18 18:36:38

I've been a Unix SA for over 15 years now and I never took the time to really understand how to setup a DNS server.  At the companies I've worked for, they were usually setup before my time and I just had to maintain them and update A records or add CNAMEs.  This is by far the most informative writeup in very simple terms.  I would recommend this to any SA!

From: denu at: 2008-11-18 09:40:37

...very much for this great HowTo!

From: Anonymous at: 2009-03-18 18:35:32

Thank you very much for this HOWTO.  It is really really good for a SysAdmin.

From: Anonymous at: 2009-12-18 05:22:38

Very informative HOW-TO and very simple to follow.

From: Big Tone at: 2009-10-03 20:04:45

I thought I knew a little about DNS ... until I installed Bind(9) on FreeBSD for the first time. That's when I realized I knew what DNS did and that's about it!

Thanks for this very informative tutorial that answered a LOT of questions.

From: Richard B at: 2010-03-09 17:54:15

Fantastic job.  I have had problems due to reverse dns and other things that networksolutions doesn't support in it's hosted DNS... so I've had to setup my own DNS server.  I had already completed everything on my own before finding this, but I realize now that much of what I had setup was redundant and just wrong.  It still worked, but this has me down to just 4 files in my zone records and I have more stuff setup now for SPF and the tip mentioned here for "allow-recursion" within the options section of named.conf (though I had to do research to figure out how to list my ip block since I'm on what I now know to be a "moat" type setup and I only want the ip's on that network to contact me for dns lookup.

 Another tip I cam across... add the following to the options section in named.conf:

version "Nunyabeeswax";

Replace "Nunyabeeswax" with whatever you want.  This helps fight some hacking by hiding the version number of BIND... though it's probably mainly useful for those that refuse to upgrade old name servers.

 Again, excellent writeup.  I wanted to learn more and after digging through plenty of other articles, this was the most complete and understandable.

Other notes:

/var/named/ - default location in Slackware for Zone files

everything after ; in a zone file is a comment so be descriptive.

From: ed at: 2014-05-03 07:42:26

The settings on sec.centralsoft.org are  almost the same like in pri.centralsoft.org?