Skip to main content

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

  • Close [x]

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

  • Close [x]

developerWorks Community:

  • Close [x]

LPI exam prep: Domain Name System (DNS)

Intermediate Level Administration (LPIC-2) topic 207

David Mertz (mertz@gnosis.cx), Developer, Gnosis Software
David Mertz
David Mertz has been writing the developerWorks columns Charming Python and XML Matters since 2000. Check out his book Text Processing in Python. For more on David, see his personal Web page.

Summary:  This is the third of seven tutorials covering intermediate network administration on Linux®. In this tutorial, David Mertz gives an introduction to DNS and discusses how to use Linux as a DNS server, chiefly using BIND 9. He shows how to set up and configure the service, how to create forward and reverse lookup zones, and how to ensure that the server is secure from attacks.

View more content in this series

Date:  01 Dec 2005
Level:  Intermediate PDF:  A4 and Letter (281 KB | 14 pages)Get Adobe® Reader®

Activity:  18929 views
Comments:  

Basic BIND configuration and running a name server

BIND configurations

When you run the named daemon to provide a DNS server, you may choose from three modes of operation: master, slave, and caching-only. The named daemon itself looks in its configuration files, chiefly /etc/bind/named.conf, to determine its operating mode.

In master mode, the named server acts as the authoritative source for all information about its zone. Domain information provided by the server is loaded from a local disk file that is manually modified or updated. Each DNS zone should have exactly one master server.

In slave mode, the named server transfers its zone information from the master server for its zone. Technically, a multi-zone server can be master of one zone and slave for another, but more commonly a LAN installation has a single hierarchy between master and slave or caching-only servers. A slave server transfers complete zone information to local files from its master server, so the answers provided by a slave server are still considered authoritative.

In caching-only mode, the named server keeps no zone files. Every query relies on some other name server for an initial answer, but to minimize bandwidth usage, previous queries are cached by the caching-only server. However, any novel query must be answered by a query sent over the network. Caching-only servers are most common on local machines where client applications can often perform a lookup without any network traffic.

In the /etc/resolv.conf configuration I offered as an example earlier in Listing 1, 0.0.0.0 is a caching-only server, 192.168.2.1 is a slave server, and 151.203.0.84 is a master server. You cannot tell this for certain just based on the order or IP addresses used, but the use of the local machine pseudo-IP address 0.0.0.0 suggests that it is running a caching-only server.


Configuring named.conf

There are some standard features that pretty much every /etc/bind/named.conf file has. An initial options directive configures some basic information. After that, several zone directives provide information on how to handle various zone requests. Domains given in zone directives as IP addresses represent initial portions of IP address ranges, but are indicated "backwards." Symbolic names may define zones, too, allowing further specified subdomains.

named.conf files (and other BIND configuration files) follow C-like formatting conventions, in large part. Both C-style block comments (/* comment */) and C++-style line comments (// comment) are allowed, as are shell-style line comments (# comment). Directives are followed by semicolon-divided statements surrounded by curly brackets.

To start, here are some common options. My local /etc/bind/named.conf begins with:


Listing 6. My local named.conf starts like this
include "/etc/bind/named.conf.options";

But you may also use the options directive directly:


Listing 7. Configuring named.conf options
options {
    directory "/var/bind";
    forwarders { 192.168.2.1; 192.168.3.1};
    // forward only;
}

This setup lets files specified without a full path be located in a relative directory; it also tells the local named to look first in 192.168.2.1 and 192.168.3.1 for non-cached results. The forward only directive (commented out here) says to look only in those nameservers on the local LAN rather than ask the root servers on the Internet.

A special zone directive is present in nearly all named.conf files:


Listing 8. Hint zone for root servers
zone "." {
    type hint;
    file "/etc/bind/db.root";
};

The contents of db.root (sometimes called named.ca for "certifying authority") is special. It points to canonical root servers, the domain registrars themselves. Their values change rarely, but you may obtain an official latest version from ftp.rs.internic.net. This is not a file a regular administrator will modify.

Beyond the root zone hint, a named.conf file will contain some master and/or slave zones. For example, for the local loopback:


Listing 9. Loopback zone configuration
zone "127.in-addr.arpa" {
    type master;
    file "/etc/bind/db.127";
};

More interestingly, a named server might act as master for a domain (and provide reverse lookup):


Listing 10. External zone configuration
zone "example.com" {
    type master;
    file "example.com.hosts";  // file relative to /var/bind
};
// Reverse lookup for 64.41.* IP addresses (backward IP address)
zone "41.64.in-addr.arpa" {
    type master;
    file "41.64.rev";
};

For a slave configuration, you might instead use:


Listing 11. External zone configuration (slave)
zone "example.com" {
    type slave;
    file "example.com.hosts";  // file relative to /var/bind
    masters { 192.168.2.1; };
};
// Reverse lookup for 64.41.* IP addresses (backward IP address)
zone "41.64.in-addr.arpa" {
    type slave;
    file "41.64.rev";
    masters { 192.168.2.1; };
};


Other configuration files

The named.conf file references a number of other configuration files with the file directive. These names are dependent on your specific setup, but in general will contain various resource records that are defined in RFC 1033 (Domain Administrators Operations Guide; see Resources for a link). The standard resource records are:

SOA
Start of authority. Parameters affecting an entire zone.
NS
Nameserver. A domain's name server.
A
Address. Hostname to IP address.
PTR
Pointer. IP address to hostname.
MX
Mail exchange. Where to deliver mail for a domain.
CNAME
Canonical name. Hostname alias.
TXT
Text. Stores arbitrary values.

The format of a record is: <name> <time-to-live> IN <type> <data>.

The name and time-to-live are optional and default to the last values used. The literal string IN means Internet and is always used in practice. The resource record files may also contain directives, which begin with a dollar sign. The most common of these is probably $TTL, which sets a default time-to-live. For example, a somewhat trivial record file for the 127.* localhost looks like this:


Listing 12. A trivial record file
# cat /etc/bind/db.127
; BIND reverse data file for local loopback interface
;
$TTL    604800
@       IN      SOA     localhost. root.localhost. (
                              1     ; Serial
                         604800     ; Refresh
                          86400     ; Retry
                        2419200     ; Expire
                         604800 )   ; Negative Cache TTL
;
@       IN      NS      localhost.
1.0.0   IN      PTR     localhost.

Other directives are $ORIGIN, which sets the domain name used to complete any relative domain name; $INCLUDE, which reads an external file; and $GENERATE, which creates a series of resource records covering a range of IP addresses.

4 of 8 | Previous | Next

Comments



static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Linux
ArticleID=132976
TutorialTitle=LPI exam prep: Domain Name System (DNS)
publish-date=12012005
author1-email=mertz@gnosis.cx
author1-email-cc=