From Fedora Project Wiki

DNS and BIND

Starting, Stopping, and Testing BIND

Run the following command as root to start BIND:

service named start

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.

Run the following command as root to stop BIND. This command will not work unless the rndc tool has been configured:

service named stop

Run the following command as root to restart BIND:

service named restart

Testing BIND

Run the netstat 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 netstat -an 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.

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 dig testdomain.com 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:

; <<>> 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,
ADDITIONAL: 0
;; QUESTION SECTION:
;testdomain.com.                    IN      A
;; AUTHORITY SECTION:
testdomain.com.             86400   IN      SOA     testdomain.com.
hostmaster.testdomain.com. 2007022604 28800 7200 2419200 86400
;; 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:

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

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:

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

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, and can cause mail to be lost.

Administration Guide - TOC Previous Page - Checking Configuration Files Next Page - Running BIND in a chroot jail