System Administration: Another Step toward the BIND - III

Before we take a look at a complete primary zone file, we need to cover background. Consider this background the context where the file itself is content.

Note: None of this may mean much to you until you see the entire text of a zone file. That's OK at this point because when you do see it tomorrow, you can refer back to this information to make sense of it. In the mean time, you may have to humor the editor.

The early information contained in the primary zone file exists to accommodate your secondary or slave server. That's BIND for you. When you look at the SOA entry you will see the information for the secondary server in lines 2 through 6.

The primary zone file contains the bulk of the configuration information DNS needs. The zone file for the example.org domain is pri.example.org. (The pri prefix exists to help you recognize that it's primary.)

If you're using the set of files that our Debian installation provides, you should name your own file after your domain. The file itself reads as follows with an explanation for each entry below it.

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

SOA refers to "Start of Authority." This term applies to the concept of an authoritative server. By the time you write your part of the DNS distributed directory, 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—the domain you are serving.

                   NS server1.example.org.;
                   NS server2.example.org.;
;

The above record type specifies the name servers for the domain. These are the ones you specified at registration of the domain.

                   MX 10 server1.example.org.;
;

The MX record in this section of the file identifies the mail server for the domain.

example.org.       A 70.158.253.42
www                A 70.158.253.42
server1            A 70.158.253.42
server2            A 70.158.253.45

A record types map a name to an IP address.

The data field of the SOA record contains several components or fields. You need to provide data or answers in the record that will allow another server on the Internet to satisfy its query. I suggest you take some time and study these. The fields include:

Name

The root name of the zone, here just an @ sign. It's a shorthand reference to the current origin (zone) in the /etc/bind/named.conf file.

Class

A number of different DNS classes exist. 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 this case, this is an SOA resource record.

Name server

The fully qualified name of your primary name server. Must be followed by a period “.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

2 errors in RR descriptions (SOA and A records)

Keith Kruepke's picture

I see two errors in your explaination of resource records. I think these are good articles for their intended audience, but I am concerned about letting these misunderstandings propagate.

(1) The last field in the SOA record is NOT a minimum/default TTL. It is the negative caching TTL, which means it is the TTL used by caching servers when your server answers that a particular name DOES NOT EXIST in your zone file. This is a common error that I think might be a holdover from something that changed in BIND.

The default TTL for resource records that do not include their own is specified at the beginning of the zone file with a $TTL directive.

See the BIND 9 Configuration Reference for additional explanation.

(2) You can have more than one A record for a particular hostname entry in DNS. When queried, the nameserver will return all of the A records for the hostname. However, each time it answers a query for the same hostname, it will change the order in which it returns the addresses. This is known as "round robin DNS" and is used for very simple load balancing.

You can run 'dig www.google.com' a few times in a row to see this in action.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState