Traditional DNS Howto - Page 3

The Primary Zone File

Now let's look at the zone file for the centralsoft domain: pri.centralsoft.org:

@ IN SOA server1.centralsoft.org. root.localhost. (
2006012103; serial
28800; refresh, seconds
7200; retry, seconds
604800; expire, seconds
86400 ); minimum, seconds

;
NS server1.centralsoft.org.;
NS ns0.centralsoft.org. ;

;
MX 10 server1.centralsoft.org.;

;

centralsoft.org. A 70.253.158.42
www A 70.253.158.42
server1 A 70.253.158.42
ns0 A 70.253.158.45

SOA refers to "Start of Authority". When you look at Figure 1, remember that DNS distributes its database. By the time you enter the picture, the system has handed off authority for part of the entire database to you. So, your zone file has to indicate where your authority starts. Your authority starts in your zone file. Your Top Level Domain servers are waiting for you to do your part of the job.

The data field of the SOA record contains several components or fields. You need to provide data or answers in the record which will allow another server on the Internet to satisfy its query. Think of the data field as a computer RECORD which has several fields. They include:

  • Name
  • The root name of the zone. The "@" sign is a shorthand reference to the current origin (zone) in the /etc/named.conf file for that particular database file. The host name of the master server for this zone is server1.centralsoft.org. Don't worry if this jargon doesn't make sense. If just means that back in the named.conf configuration file an entry points to this file and this file points back to the entry in the configuration file.

  • Class
  • A number of different DNS classes exist. For our purposes we will use the IN or Internet class used when defining IP address mapping information for BIND. The other classes exist for non Internet protocols and functions.

  • Type
  • The type of DNS resource record. In the example, this is an SOA resource record.

  • Name-server
  • Fully qualified name of your primary name server. Must be followed by a period.

  • Email-address
  • This is the email address of the person responsible for the domain. Notice that instead of an @ sign, the address uses a period and is followed by a period. In this case, the email address is the root user or root.loalhost. In other applications the email address would be root@localhost.

  • Serial-no
  • A serial number for the current configuration is usually in a date format YYYYMMDD with an incremented double digit number tagged to the end. This allows you to do multiple edits each day with a serial number that both increments and reflects the date on which the change was made. It's a numeric value that the slave server can use to check whether the zone file has been updated. The slave periodically checks the serial number to see if it has changed. If it has, the slave will perform a zone transfer. 2006012103 is the serial number in the zone file above.

  • Refresh
  • This field tells a slave DNS server how often it should check the master. This field represents a length in seconds. Every refresh cycle, the slave server checks to see whether it needs to perform a zone transfer. In this file we use 28800 as the value.

  • Retry
  • This field tells the slave how often it should try to connect to the master in the event of a connection failure. The interval in our example is 7200.

  • Expiry
  • Total amount of time a slave should retry to contact the master before expiring the data it contains. Future references will be directed towards the root servers. This is the expiration time, the length of time that the slave server should continue to respond to queries even if it cannot update the zone file. An expiration period exists under the theory that out of date data is worse than no data at all. In our example we use 604800.

  • Minimum-TTL
  • This is the default time to live (TTL) for this domain in seconds. Times will occur when remote clients will make queries for sub-domains that don't exist in your records. If so configured, your DNS server will respond with a no domain or NXDOMAIN response that the client's remote server caches. The TTL value defines the caching duration your DNS response. The value is included in your server's response. Any resource record that does not have a specified TTL uses this default. Because 86400 seconds is one day, the querying cache's record should die in one day.

The next database record type specifies the name servers for the domain. NS stands for name server. You already know that server1.centralsoft.org represents the host name of the primary domain server. The secondary or slave server for this domain follows. ns0.centralsoft.org is the hostname of the secondary name server for this domain.

Following the name servers you will see the MX record type which identifies the mail server for the domain. Following the mail record you can see the A record type which maps a name to an IP address. In the file above we have four A records which map the host names to IP addresses.

Let's write a zone file. You should name it for your own domain. Mine is pri.centralsoft.org. Name your zone file for your domain.

The first line in our zone file looks like this:

@ IN SOA server1.centralsoft.org. root.localhost. (

The "@" sign in the line refers to the "origin" for this zone file which is server1.centralsoft.org. DNS uses this as simply a label to designate the Start Of Authority (SOA) record that appears at the beginning of any zone file defining a domain. Don't make too much out of this. If you read much about DNS, then you will see people using this strange term "current origin". Few people explain what that means. It's just another bit of jargon.

The next item on the line "IN" stands for Internet. People call this a class field. Three classes exist including "HS" for Hesiod servers and "CH" which stands for Chaosnet servers. You will only see Internet servers, so don't sweat the small stuff.

IETF RFC 1035, Domain Names - Implementation and Specification says:

The SOA record stores information about the name of the server that supplied the data for the zone; the administrator of the zone; the current version of the data file [serial number]; the number of seconds a secondary name server should wait before checking for updates; the number of seconds a secondary name server should wait before retrying a failed zone transfer; the maximum number of seconds that a secondary name server can use data before it must either be refreshed or expire; and a default number of seconds for the time-to-live file on resource records.

What's next? The mailing address of the administrator in this file is root@localhost. Obviously, my mail server delivers local mail so messages related to this process will go to root's mailbox.

In case you missed it, the first line is only part of the SOA record. It has additional fields. Notice the "(" at the end of the line. Here's the rest of the record.

                        2006012103; serial
28800; refresh, seconds
7200; retry, seconds
604800; expire, seconds
86400 ); minimum, seconds

The serial number is the only field in the record that does not refer to seconds. You designate the serial number as a numeric value so when a slave server checks to the zone file on the primary server if will know if the zone file changed. The slave can then do a zone transfer and populate its database with the current records.

The remaining fields use seconds to denote their values. For example, the number of seconds a secondary name server should wait before checking for updates is in the refresh record. 28800 seconds is 480 minutes or 8 hours.

Also notice that the SOA record ends at the end of the Minimum-Time to Live (TTL). You can see the ")" symbol which closes the record values.

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?