Administration Guide Draft/DNS

= DNS and BIND =

Introduction
The Domain Name System (DNS organizes the Internet into a hierarchy of domains, providing a system to resolve easy to remember host and domain names to their IP address. An example of this is typing  into a Web browser and having the google webpage come up. Another example is using the   command instead of the   command. These are both examples of forward lookups. DNS can provide reverse lookups which is resolving a hostname when given an IP address. Reverse lookups are handy for web sites tracking users, tools such as   and , checking the reverse DNS records of email addresses, which can be useful against fighting spam, and so on. DNS also solves name uniqueness problems on networks: a hostname only needs to be unique in the domain or organization, not the entire Internet.



At the top of the DNS hierarchy is a "dot", which is the root domain. The root domain holds together all domains underneath it. Below the root domain are the familiar com's, edu's, net's, and so on. These are called global Top Level Domains (gTLD). Below gTLDs are subdomains, for example, google.com.

When working with DNS you will hear about zones, which are basically a group of machines within a domain. Every period in a DNS name indicates a point where authority can be delegated, so you can think of a zone as part of the DNS namespace. Using australia.test.com as an example, australia is a zone in the test.com domain.

DNS Queries
In most cases a DNS query is sent when you need the IP address of a hostname. The following example will use the host testhost, and the domain testdomain.com. The process is as follows:


 * If the DNS server you are using is using cache facilities, the cache is first checked for any information about testhost.testdomain.com. If an A record for testhost.testdomain.com is found, the process is complete.
 * If no information about testhost.testdomain.com exists in cache, the cache is then checked for any information on testdomain.com. This process continues, taking away parts of the DNS namespace from left to right.
 * When the query reaches the end, which is the end of .com, a query for testhost.testdomain.com is sent to a root level nameserver. The root level nameserver refers you to a nameserver in the .com domain, which will know more about the query for testhost.testdomain.com.
 * The .com level nameserver refers you to a testdomain.com level nameserver. The testdomain.com level nameserver will contain the A record (IP address) for the testhost.testdomain.com system.

Types of DNS Queries
There are three types of queries you can send to a DNS server. These are recursive, iterative, and inverse:
 * Recursive: the DNS server will provide the full answer by following all referrals.
 * Iterative: non-recursive. The DNS server first checks its cache. If the query can not be resolved, a referral is sent to the resolver on your local system. Most local resolvers are stub resolvers, which mean they can not follow referrals. Therefore you should have at least one nameserver in  that can provide recursive queries.
 * Inverse: inverse queries map a resource record to a domain.

Types of DNS Servers
There are many different types of DNS servers. The following is a list of the most common:


 * Master: holds zone files for the domain it is authoritative for. DNS is not owned by one central organization, instead authority is delegated so that everyone running a domain, or a zone, has control over their DNS.
 * Slave: downloads zone information from Master DNS servers. Slave servers will reply with an authoritative answer as long as the information was not from cache.
 * Advertising: only serves information for the zone it is authoritative for. Does not provide recursive queries. An advertising server will not be able to resolve any queries outside the domain it is authoritative for.
 * Cache-only: uses a root hints zone file, and provides recursive queries. A cache-only server does not hold authoritative information or serve a domain.

Client Configuration
For client configuration there are four important files:,  ,  , and .

/etc/hosts
The following is an example  file:

127.0.0.1      localhost.localdomain localhost testmachine
 * 1            localhost6.localdomain6 localhost6

The syntax is as follows: IP address, Fully Qualified Domain Name (FQDN), aliases or hostnames.A localhost entry is required otherwise applications will break. The second line is for IPv6, which will not be covered in this guide. Using this example, the  and   commands will be the same as using the   command.

/etc/host.conf
The following is an example  file:

order hosts,bind multi on nospoof on

The  section defines the order the resolver library will use. In this case the resolver will first query the local hosts file,, and then a DNS server. The  option allows a machine in   to have multiple IP addresses, which is useful for systems with more than one network interface. Use the  option to help prevent IP spoofing.

/etc/nsswitch.conf
On systems running the GNU version 2 of the standard library, glibc, the  file takes precedence over. If you are running glibc ignore the  file. For DNS configuration the most important entry in  is the hosts entry:

hosts:	files dns

This defines the order the resolver will use. Using this example, the resolver will first query the local hosts file. If the query can not be resolved using the information in, a DNS server is queried. If the  file only contained an entry for localhost, a DNS server would be used for all queries other than those for localhost.

/etc/resolv.conf
The  file is used to list the IP addresses of nameservers to use for DNS queries. This nameservers listed will be used to resolve all queries that can not be resolved using the  file. The following is an example  file:

domain testdomain.com nameserver 192.168.0.1 nameserver 192.168.0.2

Currently you are allowed to have 3  directives. List these in order of preference. If queries timeout using the first nameserver, the query is attempted again using the second nameserver, and so on.

The  directive is used to specify a default domain name to append to queries. If DNS fails to lookup a name, the default domain is appended. For example, if a query for testhost fails, the  entry will be appended, in this example resulting in a query for testhost.testdomain.com. The  directive is similar to the   directive. The  directive specifies one default domain, whereas   allows you to specify many. The following is an example of the  directive:

search testdomain1.com search testdomain2.com search testdomain3.com

If a query for testhost.testdomain1.com timed out, a query for testhost.testdomain2.com would be attempted. If this timed out, a query for testhost.testdomain3.com would be attempted.

Installing BIND
Run the following command to install BIND:

yum install bind

= DNS and BIND =

Configuring BIND
Before you start named you need to create the main configuration file,. Zone database files are also be required.

/etc/named.conf
The  file is the main configuration file for BIND. The first section is the  section. The following is an example  section. A complete  file follows at the end of this section:

options { directory "/etc/bind"; allow-query {any;}; recursion no; pid-file "/var/run/named/named.pid"; zone-statistics yes; statistics-file "/etc/bind/named­stats.log"; };

The  directive tells named  the default location of the zone database files. If you set  you will need to create the   directory. The user running named requires read access to this directory, and depending on configuration needs, may require write access. This guide assumes that after you have configured the zone database files, named will not require write access to any zone database files. To increase security, place zone database files that require write access in a separate directory to zone database files that only require read access.

The  directive controls who is able to send queries to the DNS server. Using  allows anyone to query your DNS server. This is not recommended - queries should be limited to systems on your own subnet. The following is an example that only allows systems in the 192.168.0.0/24 network to query the DNS server:

allow-query {192.168.0.0/24;};

The  directive controls the cache functionality. Using  disables caching and will cause named to only return iterative responses. These responses are not stored in cache. If you want to cache queries run a separate caching-server. If that is not possible, limit who can perform recursive queries. This should be limited to the subnet you are on. The following is an example that only allow systems in the 192.168.0.0/24 network to perform recursive queries:

allow-recursion {192.168.0.0/24;};

Control the location of the named pid file using the  directive. The default location is, which by default, should not be writeable by the user running named. Create a directory under, for example, / , to store the named pid file and give the user you use to run named with write access to this directory. If you use another location other than the default, specify this location using the  directive.

The  directive controls whether the DNS server will collect statistically information. If this is set to yes you can view statics using the  command. These statstics are also used by tools such as dnsgraph, which can be downloaded here:

Running the  command will write a file called   under the directory specified with the   directive. Control the location and the name of the statics file using the  directive.

Configuring Zones
Use the  directive to define zones. Zone database files contain Resource Records. There are many different types of Resource Records, such as A records which map a hostname to an IP address, CNAME records which are used to map aliases to real names (for example, FTP and WWW mapping to the same server which is running both services), and MX, Mail Exchanger records. This list is note exhaustive, but lists the main Resource Records you will use.

Providing recursive queries outside of your own domain requires a root hints zone. The zone database file for the root hints zone contains a list of top level nameservers. The following is an example root hints zone file in. Define zone files underneath the options section in :

zone "." { type hint; file "/etc/bind/root.hint"; };

The following is an example zone for testdomain.com:

zone "testdomain.com" { type master; allow-transfer {192.168.0.5;}; file "/etc/bind/db.testdomain.com"; };

The name of the zone is defined between the talking marks after, in this case the zone name is testdomain.com. The  option configures the server to be a master server, which means it is authoritative for this zone. If  is set to slave the zone data is transferred from a master server. If you are specifying a slave zone, you need to configure where the master server is using the  directive. The following is an example slave zone which uses a master server with an IP address of 192.168.0.6:

masters {192.168.0.6;};

The  option controls who can perform a zone transfer. Zone transfers are used to replicate zone database files between servers. Definitely restrict who can perform a zone transfer, as zone files are a fantastic point to build up a network topology of a remote network. Restrict zone transfers using IP addresses, as shown in the example testdomain.com zone.

Define the location of the zone database file using the  option. This file is not anything special, it is simply a text file.

Two other zones you may require are zones for localhost and reverse lookups. The first is an example of a localhost host zone:

zone "localhost" { type master; file "/etc/bind/db.127"; };

The following is an example reverse lookup zone for a 192.168.0.0/24 network:

zone "0.168.192.in-addr.arpa" { type master; file "/etc/bind/db.0.168.192.in-addr.arpa"; };

Reverse lookup zone files are used to support reverse lookups, which is resolving a hostname when given an IP address. A reverse lookup zone is not required.

The in-addr.arpa is a specially reserved domain to support reverse lookups. When a DNS query is performed, the namespace (for example, host.testdomain.com) is searched from right to left. If this was performed on an IP address you would never find the correct network or host:

Starting from the right will not work: 192.168.0.1

Reversing the order allows searching starting from in-addr.arpa: 1.0.168.192.in-addr.arpa

The following is a complete  example:

options { directory "/etc/bind"; allow-query {any;}; recursion no; pid­file "/var/run/named/named.pid"; zone-statistics yes; statistics-file "/etc/bind/named­stats.log"; };

zone "." { type hint; file "/etc/bind/root.hint"; };

zone "testdomain.com" { type master; allow-transfer {192.168.0.5;}; file "/etc/bind/db.testdomain.com"; };

zone "localhost" { type master; file "/etc/bind/db.127"; };

zone "0.168.192.in-addr.arpa" { type master; file "/etc/bind/db.0.168.192.in­addr.arpa"; };

These are the basic configuration options available in. For a complete listing please refer to

/etc/named.conf Permissions
Run the following command as root to set the correct user and group for :

chown named:named /etc/named.conf

Run the following command as root to set the correct mode:

chmod 600 /etc/named.conf

If you are running SELinux, run the following command to set the correct SELinux context:

chcon -t named_var_run_t /etc/named.conf

Zone Database Files
Zone database files are text files which contain Resource Records. The following is the example of the first section of a zone database file. A  symbol is used for comments. White spaces will cause problems so use  symbols if you require spacing. A complete zone database file follows at the end of this section:

$TTL 3D @ IN SOA testdomain.com. hostmaster ( 2007022601 ;serial number 8H ;refresh 2H ;retry 4W ;expiry time 1H ;minimum )

The  value defines the default time-to-live value for Resource Records that do not specify one. This sets the duration for how long a resource record is valid, in other words, how long a server can cache this information without having to make a request for it again.

The  defines the Start Of Authority (SOA). This means the Resource Records in this zone database file contain authoritative information. The  stands for "replace with the zone name". Since version 9 of BIND this information can be obtained from, or it could be written as follows:

testdomain.com. IN SOA testdomain.com. hostmaster

is an email address that you can be contacted on. It is important to note the  at the end of. You must have a trailing  at the end of the domain specified in the SOA.

After the SOA a number of values are defined:


 * The serial number  follows a year:month:day:number of modifications that day syntax. The example   stands for 2007, February 26, and the database file was modified twice that day. Every time a zone database file is modified you must modify the serial number. Secondary nameservers use this information to notice when configuration changes have occurred. The serial number of the zone file on the master server is compared to the serial number of the zone file on the secondary server. If the serial number on the master server is more recent, a zone transfer occurs.


 * The refresh time defines how often a secondary server checks its zone database files against a master server.


 * When a request or zone refresh fails, the retry value defines how long a secondary server waits before trying to contact a master server.


 * If a secondary server is unable to contact a master server, the expiry time defines when the secondary server will discard all zone data.


 * The minimum time can cause some debate. In earlier versions of BIND (4,8) this value set the default time-­to-­live on resource records which did not specify one. In BIND 9 the minimum time is used to define how long a negative answer is cached. A negative answer is the response to a query for a domain which does not exist. Caching negative answers has the same benefits as caching positive responses: decreased resolving time and reduced network bandwidth, as the process of queries and referrals explained earlier does not have to keep taking place once the negative answer is cached. The time-­to-­live on cached negative answers is the minimum value of the minimum time and the  value. Since the maximum minimum value is 3 hours, this value will usually be used as the time-­to-­live for cached negative answers. For more information on negative answers visit

Resource Records follow a name ttl class resource record parameter syntax. The following is an example of the Resource Records section of a zone database file:

@ IN NS testserver.testdomain.com. @ IN MX 10 mail.testdomain.com. localhost IN A 127.0.0.1 mail IN A 192.168.0.1 testserver IN A 192.168.0.1 testclient IN A 192.168.0.2 laptop IN CNAME test
 * name - ttl - class - rr - parameter

The first Resource Record is an NS entry, which stands for nameserver. The NS entry for  is the actual machine the DNS server is running on. You should have at least two nameserver entries. When you use the  tool the results will have an authority section, which contains a list of namesevers. A referral has a list of nameservers to query, so without nameserver entries in Resource Records, queries would not be possible.

Note, there is also an A record for the NS entry. Nameservers in your own domain require an A record - these are known as glue records. Glue records hold the DNS system together. Without an A record the testserver.testdomain.com nameserver would not be found, and queries would fail.

The next entry is an MX (Mail Exchanger) record. MX records are used for routing mail. The  between the MX and the name of the mail server sets the preference value. The server with the lowest prefernce will have the highest priority. The following is an example of a network with two mail servers. Multiple MX records are good for mail backup incase one server fails:

@ IN MX 10 mail.foo.bar. @ IN MX 20 backup.foo.bar. mail IN A 192.168.0.1 backup IN A 192.168.0.2

The  server has a higher priority that the   server. If the  server failed,   would be used for mail. There are A records for both mail servers. An A record is required for mail and nameservers within your own domain.

The following is an example A Resource Record, with details following afterwards:

testserver IN A 192.168.0.1

The name on the left hand side of the Resource Record is the hostname, which in this case is testserver. A TTL value is not defined, so this record will get the default of 3 days which was defined at the beginning of the zone database file using the  option.

The IN class stands for Internet Protocol. This is the most common class and most likely the only class you will need for a basic DNS server.

The Resource Record is the type of record, for example A, CNAME, and MX. An A record is used to map a hostname to an IP address. You must only have one A record per hostname: many hostnames pointing to one IP address is fine, but mapping one hostname to multiple IP address will cause routing problems.

The parameter at the end, in this case 192.168.0.1, can be another alias or hostname, or an IP address.

The following is an example of a CNAME resource record, with details following afterwards:

testclient IN A 192.168.0.2 laptop IN CNAME testclient

CNAME records are used to map aliases or hostnames to real names defined in A records. In this example, the  command would return the same results as the   command. The following is an example of when CNAMEs can be useful. One server (testserver) is providing both WWW and FTP services:

testserver IN A 192.168.0.1 www IN CNAME testserver ftp IN CNAME testserver

In both of these cases queries for  and   would direct you to the testserver (with the IP address of 192.168.0.1). However, using a CNAME record results in two lookups: one lookup is required for the CNAME, and another for the A record. Balance the use of CNAME records on heavily loaded servers as they will add more load. The following is a valid example of mapping different hostnames to one IP address, which may be better in high-load situations:

testserver IN A 192.168.0.1 www IN A 192.168.0.1 ftp IN A 192.168.0.1

The following is a complete zone database file: $TTL 3D @ IN SOA testdomain.com. hostmaster ( 2007022601 ;serial number 8H ;refresh 2H ;retry 4W ;expiry time 1H ;minimum ) @ IN NS testserver.testdomain.com. @ IN MX 10 mail.testdomain.com. localhost IN A 127.0.0.1 mail IN A 192.168.0.1 testserver IN A 192.168.0.1 testclient IN A 192.168.0.2 laptop IN CNAME test

Reverse Lookup Zone Database Files
The following is an example reverse lookup zone database file for a 192.168.0.0/24 network. The SOA section has not been included, since it is the same as the previous example. This example concentrates on the Resource Records:

@ IN NS testserver.testdomain.com. 1 IN PTR testserver.testdomain.com. 2 IN PTR testclient.testdomain.com.

PTR (Pointer) records are used in reverse lookup zone database files. PTR records are basically the same as an A record. The values (1,2) in front of the IN class are the host portions of the IP addresses. For example, the testserver.testdomain.com machine uses a 192.168.0.1 IP address. Since this is a 192.168.0.0/24 network, the last octet of the IP address is the host section - therefore a value of 1 is used here. To make it clearer, if a new machine named pc1, with an IP address of 192.168.0.15 was added to the network. The correct entry would be as follows:

15 IN PTR pc1.testdomain.com.

Use Fully Qualified Domain Names in reverse lookup zone files. Using the following example a query for pc1 would result in pc12.0.168.192.in-­addr.arpa trying to be resolved. This is not desirable:

15 IN PTR pc1

Localhost Zone Database File
The following is an example localhost zone database file. An NS and A record are required. Localhost queries can usually be resolved by the local machine, so are localhost zone is not necessary in all cases:

$TTL 3D @ IN SOA localhost. root.localhost. ( 2007022601 8H 2H 4W 1H ) @ NS localhost. @ A 127.0.0.1

Root Hints Zone Database File
The Root Hints zone database file contains a list of root level name servers. This file is used for queries outside of your own domain. Run the following command to create the root hints zone database file:

dig at e.root-servers.net. ns > /etc/bind/root.hint

Cache-only /etc/named.conf
The following is an example  for a cache-only DNS server:

options { directory "/etc/bind"; allow-query {subnet;}; allow-transfer {none;}; };

zone "." { type hint; file "/etc/bind/root.hint"; };

Use  to define a subnet that can send queries to your server. Disable zone transfers using.

= DNS and BIND =

Configuring Logging
By default named uses syslog, but you can define your own logging in named.conf. Create a new file named  that contains the following:

logging { channel simple_log { file "/etc/bind/bind.log" versions 3 size 5m; severity warning; print-­time yes; print-­severity yes; print-­category yes; }; category default { simple_log; }; };

This is a basic example and should only be used as a guide. This will log all warnings (as defined with ) to. There is a 5 megabyte limit on this file. For more information on logging please refer to

Include the following line in named.conf to include the  file:

include "/etc/bind/logging";

After a reload using the  command the log file will look similar to the following:

10­Mar­2007 10:52:48.002 general: info: zone testdomain.com/IN: loaded serial 2007031001 10­Mar­2007 10:52:48.002 notify: info: zone testdomain.com/IN: sending notifies (serial 2007031001) 10­Mar­2007 10:52:48.002 notify: info: client 192.168.0.1#1024: received notify for zone 'testdomain.com'

= DNS and BIND =

Configuring the rndc tool
The rndc tool is used to control named. This tool can be used locally (on the same machine running named), or remotely. Run the following command to create the rndc configuration files:

/usr/local/sbin/rndc-confgen

This will produce the following output; however, the secret key will be different:

key "rndc-key" { algorithm hmac-md5; secret "sqDTXGGjF9nwpb4n6nxJhQ=="; };

options { default-key "rndc-key"; default-server 127.0.0.1; default-port 953; };



The first section (between  and  ) is for the rndc.conf file. Copy this into a new file and save it as. The following is an example  file:

key "rndc-key" { algorithm hmac-md5; secret "sqDTXGGjF9nwpb4n6nxJhQ=="; };

options { default-key "rndc-key"; default-server 127.0.0.1; default-port 953; };

The  file is self explanatory: an algorithm and a secret key are defined. You can set the IP address rndc will connect to along with the port using  and   respectively. The  file is the client side configuration. The IP address and port are for a remote server. If you are running rndc on the same server as named, leave the  and   options as their default.

Copy the next section into  after the options section:

key "rndc-key" { algorithm hmac-md5; secret "sqDTXGGjF9nwpb4n6nxJhQ=="; };

controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; }; };

This is the server side configuration. You can configure an IP address and port to listen on. These can be left as the default values. If you change the IP address here, conigure the /etc/rndc.conf  file:

key "rndc-key" { algorithm hmac-md5; secret "sqDTXGGjF9nwpb4n6nxJhQ=="; };

controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; }; };

Use the  option in   after the options section to include this file. Change the permissions appropriately, particularly so that the named user has read permissions:

include "/etc/bind/named_key";

Using the rndc tool
The following are useful rndc commands:


 * : write detailed statistical information about the DNS server to a file named  underneath the directory specified using   in named.conf. This tool requires that   be configured in named.conf.


 * : reloads all configuration and zone database files. Run this command after modifying configuration or zone database files so that your changes take affect.


 * : display statistical information about the DNS server. The output is similar to the following:

number of zones: 2 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF recursive clients: 0/0/1000 tcp clients: 0/100 server is up and running

Run the following command as root to display a full list of rndc commands:

rndc

The rndc tool is located in the  directory. If this directory is not configured in your $PATH, run rndc using the following command:

/usr/local/sbin/rndc

= DNS and BIND =

Checking Configuration Files
The  directory contains two useful tools:   and. These tools are to check whether your configuration files are valid.

Checking /etc/named.conf
Run the  command to check whether your named.conf file is valid. If no results are returned, the configuration should be correct:

/usr/local/sbin/named-checkconf /etc/named.conf

Replace  with the location of your named.conf file.

Checking Zone Database Files
The following is an example of checking the db.testdomain.com zone database file using the named-checkzone command:

/usr/local/sbin/named-checkzone testdomain.com /etc/bind/db.testdomain.com

The first argument is the zone name as it appears in named.conf, in this case testdomain.com. The last argument is the location of the zone database file for testdomain.com, in this case /etc/bind/db.testdomain.com. The output of the named-checkzone command should be similar to the following:

zone testdomain.com/IN: loaded serial 2007031008 OK

= DNS and BIND =

Starting and Testing BIND
Run the following command to start BIND:

/usr/local/sbin/named ­-u named ­-c /etc/named.conf


 * The  switch specifies the user to run named with.


 * The  switch specifies the location of the named.conf file.

On certain systems running a 2.6.19+ kernel, starting named may cause a "process 'named' is using obsolete setsockopt SO_BSDCOMPAT" error. It is safe to ignore this error.

Testing BIND
Run the  command to confirm BIND started correctly:

netstat -an

The output will contain items similar to the following:

Active Internet connections (servers and established) Proto Recv­Q Send­Q Local Address      Foreign Address    State tcp      0     0  127.0.0.1:53       0.0.0.0:*          LISTEN tcp      0     0  192.168.0.1:53     0.0.0.0:*          LISTEN tcp      0     0  127.0.0.1:953      0.0.0.0:*          LISTEN udp      0     0  0.0.0.0:1024       0.0.0.0:* udp      0     0  127.0.0.1:53       0.0.0.0:* udp      0     0  192.168.0.1:53     0.0.0.0:*

The  output shows listening sockets on TCP and UDP port 53 (DNS), and TCP port 953 for rndc connections. Note the UDP port 1024 socket - BIND requires a source port for outbound queries, which is a random unprivileged port.

Using dig
The dig tool can be used to test your DNS server. The bind-utils package includes the dig tool. Run the following command to confirm the bind-utils package is installed:

rpm -q bind-utils

If bind-utils is not installed, install the package using the following command:

yum install bind-utils

Run the  command to check the DNS server. Replace testdomain.com with your domain:

dig testdomain.com

The output will be similar to the following, when using the configuration files in this guide:

ADDITIONAL: 0 testdomain.com. 86400  IN      SOA     testdomain.com. hostmaster.testdomain.com. 2007022604 28800 7200 2419200 86400
 * <<>> DiG 9.3.2­P2 <<>> testdomain.com
 * global options: printcmd
 * Got answer:
 * ­>>HEADER<<­ opcode: QUERY, status: NOERROR, id: 29672
 * flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
 * QUESTION SECTION:
 * testdomain.com.                   IN      A
 * AUTHORITY SECTION:
 * Query time: 1 msec
 * SERVER: 192.168.0.1#53(192.168.0.1)
 * WHEN: Mon Feb 26 17:45:39 2007


 * MSG SIZE rcvd: 69

The AUTHORITY SECTION shows our server is the authoritative for the testdomain.com domain. By default, dig will query for an A record, which is shown in the QUESTION SECTION.

You can use the dig tool to query for a specific host:

dig testserver.testdomain.com

The output will be similar to the following when querying for a hostname:

testserver.testdomain.com. 259200 IN      A       192.168.0.1 testdomain.com. 259200 IN      NS  testserver.testdomain.com.
 * QUESTION SECTION:
 * testserver.testdomain.com.             IN      A
 * ANSWER SECTION:
 * AUTHORITY SECTION:

These results contain an ANSWER SECTION because the query was for an A record for testserver.testdomain.com, which was found on our server. The AUTHORITY SECTION lists the nameservers required to perform the query. Resource Records can be specified using the dig tool. The following is an example of specifying an MX record:

dig MX testdomain.com

The output, using the configuration files in this guide, will be similar to the following:

testserver.testdomain.com. 259200 IN      MX      10 mail.testdomain.com. testdomain.com. 259200 IN      NS      testserver.testdomain.com. mail.testdomain.com. 259200 IN      A       192.168.0.1 testserver.testdomain.com. 259200 IN      A       192.168.0.1
 * QUESTION SECTION:
 * testserver.testdomain.com.             IN      MX
 * ANSWER SECTION:
 * AUTHORITY SECTION:
 * ADDITIONAL SECTION:

The MX record was found as shown in the ANSWER SECTION. This is what you want to have: an MX record and a corresponding A record; however, you can use CNAMEs to reference nameservers and MX records, but this is not recommended.

= DNS and BIND =

Running BIND in a Chroot Jail
This guide will not go into details. Please navigate to  for step-by-step instructions.


 * Create a /chroot/named directory, with the correct structure. For example, /dev, /var, and /etc directories.


 * Move  into the   directory.


 * Move all zone database files to the  directory.


 * Create the special files required, such as /dev/null and /dev/random.

Once the directory structure and special files have been created, run the following command to start named:

/usr/local/sbin/named ­-u named ­-t /chroot/named ­-c /etc/named.conf

The  switch specifies the directory the named process will chroot to after processing any options, and before it accepts any queries. The process for named chrooting is as follows: chroot to directory, setuid before forking, then bind the INET sockets.

= DNS and BIND =

DNS and Mail
An email address is made up of a user section and a domain section. The user section is in front of the  and the domain follows after. For local delivery the MTA does not need to perform a DNS query, but when transferring mail to an outside domain it does.

When sending mail outside your own domain the MTA will query for an MX record for the domain specified in the email address. If sending mail to testuser@testdomain.com  the MTA will essentially   ­ this will give the MTA the information needed to transfer mail to the testdomain.com domain.

One thing that makes mail different to a normal DNS query is that mail may not be going to the exact machine specified in the address. An example will make this clearer: sending mail to testuser@testdomain.com probably will not send mail to a machine called testdomain.com, but more likely mail.testdomain.com. This is achieved with MX and A records as shown earlier. If the mail server is in your domain you need an A record. A common configuration problem, although providing a working solution, is to have MX records pointing to a CNAME:

IN MX 10 mail.testdomain.com. mail IN CNAME server1 server1 IN A 192.168.0.1

This configuration works but can result in the CNAME being lost. There is an A record for server1 and a CNAME for the MX record, but nothing to join them. The correct configuration would be as follows:

IN MX 10 mail.testdomain.com. mail IN A 192.168.0.1 server1 IN CNAME mail

A records for mail and server1 both pointing to 192.168.0.1 is also acceptable.

= DNS and BIND =

Security Considerations
This section requires a whole guide. Instead of a complete guide, this section will give points of advice, rather than how to implement each idea:


 * Run dedicated servers: an internal advertising and an external server capable of resolving queries outside of your domain.


 * Use  in named.conf to restrict zone transfers to only specified servers. Do not forget to restrict zone transfers for both master and slave servers.


 * Separate cache and DNS functionality:  in named.conf will disable caching. If caching must be done on the same server, restrict who can perform recursive, caching queries by using the   in named.conf. Allowing recursive queries from every one increases the chances of DNS cache poisoning. This is a good reason to run dedicated servers, this avoids your entire DNS system being brought down because of one poisoned cache.


 * Restrict who can query your DNS server: use  to restrict queries except from the specified subnet.


 * For iptables, allow UDP and TCP port 53. UDP is used for almost all queries, but queries larger than 512 bytes and zone transfers require TCP. Depending on the information you are serving and whether or not you are allowing zone transfers, you can get away with only allowing UDP port 53. Allow TCP port 953 for rndc, and of course allow traffic on the loopback (lo) interface. The following is an iptables examples (for a machine with only a eth0 network interface card) that allows UDP and TCP port 53, and TCP 953 for rndc:

iptables ­-A INPUT ­-i lo ­-j ACCEPT iptables ­-A OUTPUT ­-o lo ­-j ACCEPT iptables ­-A INPUT ­-i eth0 ­-p tcp ­­--dport 53 ­-j ACCEPT iptables ­-A INPUT ­-i eth0 ­-p udp ­­--dport 53 ­-j ACCEPT iptables ­-A INPUT ­-i eth0 ­-p tcp ­­--dport 953 ­-j ACCEPT

This example does not take outbound traffic into consideration.


 * The "Securing an Internet Name Server" PDF found at  has a lot of information on securing a nameserver.

= DNS and BIND =

Resources and Thanks
The following is a list of books and resources that were used when researching the content found in this guide. The links were valid at the time of writing:

Linux Network Administrators Guide (Online and Printed Versions)

LPI Certification in a Nutshell

Linux Security Cookbook

Linux Users of Victoria (LUV) mailing lists

IRC: #ubuntu-­au on Freenode (thanks for the help realist!)

Linux man pages