NSLU2-Linux
view · edit · print · history

HowTo.BuildPrimaryDNSServer History

Hide minor edits - Show changes to markup

November 25, 2007, at 03:06 PM by Silvia Schuckert -- There was a dot after ns1.leedomain.com missing.
Changed line 194 from:
                        IN NS   ns1.leedomain.com
to:
                        IN NS   ns1.leedomain.com.
November 25, 2007, at 02:06 PM by Silvia Schuckert --
Added line 131:

;Goes in /opt/etc/named/

Deleted line 146:

;Goes in /opt/etc/named/

November 25, 2007, at 01:17 PM by Silvia Schuckert --
Added lines 145-146:

;Goes in /opt/etc/named/

Added line 149:

;Goes in /opt/etc/named/

Added line 165:

;Goes in /opt/etc/named/

Added line 183:

;Goes in /opt/etc/named/

Added line 201:

;Goes in /opt/etc/named/

October 25, 2007, at 04:37 AM by Lee Kimber --
Added line 432:
Deleted line 433:
October 25, 2007, at 04:36 AM by Lee Kimber -- Additional troubleshooting steps added
Added lines 429-447:

A couple of errors I have seen are:

Rollforward errors, such as


25-Oct-2007 05:02:40.121 general: error: zone leedomain.com/IN: journal rollforward failed: journal out of sync with zone

The fix for this is to delete the appropriate .jnl file in the /opt/etc/named/ directory. Or delete them all.

Bad owner name errors, such as:

25-Oct-2007 05:07:43.204 general: error: db.serveblog.net:15: #mailq.serveblog.net: bad owner name (check-names)
25-Oct-2007 05:07:43.200 general: error: zone serveblog.net/IN: loading master file db.serveblog.net: bad owner name (check-names)

In my case, there were caused by having commented out a host record with a # sign. Change the # to a ; or delete the record.

December 24, 2006, at 03:00 AM by Taylor -- spelling correction
Changed lines 310-311 from:

You don't have to use -sS. I do recommend you scan all the server's porsts though so that you know what else is visible on that machine.

to:

You don't have to use -sS. I do recommend you scan all the server's ports though so that you know what else is visible on that machine.

September 04, 2006, at 09:27 AM by Lee Kimber -- Small clarity improvement
Changed lines 54-55 from:

The 'logging' section is commented out until after testing is complete. This is because this logging separates start-up messages finto syslog and running messages into a user-specified log. Keeping them all together during testing is quicker.

to:

The 'logging' section is commented out until after testing is complete. This is because this logging will squirt bind's start-up messages into syslog and bind's running messages into a user-specified log. Keeping them all together during testing - in the system's messages log - makes testing and troubleshooting easier.

September 02, 2006, at 10:49 AM by Lee Kimber -- Minor update added
Changed lines 18-19 from:

Now to configure it. There's so much contradictory material on the Web about configuring bind that it's easy to see why people struggle. The following steps work, though at the time of writing I still have not got it to resolve non-fully qualified hostnames. Meaning: it resolves the internal network host 'www.leedomain.com' to the correct IP address but will not resolve 'www' to any IP address. If any DNS gurus can see what I need to change to enable that please update this page.

to:

Now to configure it. There's so much contradictory material on the Web about configuring bind that it's easy to see why people struggle. The following steps work for me. And they do correctly resolve non-fully qualified host names, contrary to my earlier findings.

August 30, 2006, at 07:36 AM by Lee Kimber --
Changed lines 3-4 from:

This is the first step I took in working towards getting a DHCP-DDNS-enabled Unslung box up and runnning. The DHCP and Dynamic part of this are documented at IntegrateDHCPDynamicDNS?. What follows are the steps to create a working primary DNS server.

to:

This is the first step I took in working towards getting a DHCP-DDNS-enabled Unslung box up and runnning. The DHCP and Dynamic part of this are documented at IntegrateDHCPandDynamicDNS. What follows are the steps to create a working primary DNS server.

Deleted line 392:
August 30, 2006, at 07:34 AM by Lee Kimber --
Changed lines 3-4 from:

This is the first step I took in working towards getting a DHCP-DDNS-enabled Unslung box up and runnning. I haven't had time to work on the DHCP and Dynamic part of this yet. When I do I will document it if I succeed. What follows are the steps to create a working primary DNS server.

to:

This is the first step I took in working towards getting a DHCP-DDNS-enabled Unslung box up and runnning. The DHCP and Dynamic part of this are documented at IntegrateDHCPDynamicDNS?. What follows are the steps to create a working primary DNS server.

Please update here or send questions to Lee Kimber <lee atnospam kimberconsulting dot com>.

August 29, 2006, at 10:11 PM by Lee Kimber -- Added IntegrateDHCPandDynamicDNS link
Changed lines 426-428 from:

Copy the edited named.conf to /opt/etc/named/ and restart the server. Doing this will leave /var/log/messages to catch system problems, such as a failed bind start up but leave your specified log file to catch bind's running problems.

I will add to this how to if I get Dynamic DNS up and running.

to:

Copy the edited named.conf to /opt/etc/named/ and restart the server. Doing this will leave /var/log/messages to catch system problems, such as a failed bind start up, but leave your specified log file to catch bind's running problems.

Since writing the above, I have got DHCP and Dynamic DNS up and running on a slug. The configuration and testing of that are described in IntegrateDHCPandDynamicDNS.

August 29, 2006, at 09:28 PM by Lee Kimber -- Minor edit to clarify
Changed lines 56-60 from:
  1. key "rndc-key" {
  2. algorithm hmac-md5;
  3. secret "VDHtbx5AHIeDC?/YmTPd9HA?==";
  4. };
to:
Deleted line 123:

//; beleive the below is not necessary as included above

August 08, 2006, at 02:52 PM by Lee Kimber -- More minor formatting improvements
Added lines 1-2:
Changed lines 10-11 from:

ipkg install bind

to:

ipkg install bind

Changed lines 36-37 from:

mkdir /opt/etc/named

to:

mkdir /opt/etc/named

Changed lines 40-41 from:

/opt/sbin/rndc-confgen -a

to:

/opt/sbin/rndc-confgen -a

Changed line 54 from:

[@

to:

[@

Changed line 133 from:

[@

to:

[@

Changed line 149 from:

[@

to:

[@

Changed line 163 from:

[@

to:

[@

Changed line 181 from:

[@

to:

[@

Changed line 198 from:

[@

to:

[@

Changed lines 287-288 from:

tail -f /var/log/messages

to:

tail -f /var/log/messages

Changed lines 293-294 from:

/opt/etc/init.d/S09named start

to:

/opt/etc/init.d/S09named start

Changed lines 305-306 from:

/opt/etc/init.d/S09named restart

to:

/opt/etc/init.d/S09named restart

Changed lines 311-312 from:

nmap -sS <DNS_server_IP>

to:

nmap -sS <DNS_server_IP>

Changed lines 317-318 from:

dig @<DNS_server_IP> www.bbc.co.uk

to:

dig @<DNS_server_IP> www.bbc.co.uk

Changed line 321 from:

[@

to:

[@

Changed line 352 from:

[@

to:

[@

Changed line 363 from:

[@

to:

[@

Changed line 399 from:

[@

to:

[@

Changed line 416 from:

[@

to:

[@

August 08, 2006, at 02:45 PM by Lee Kimber -- Formatting clean up
Deleted lines 0-1:

Configure a Master or Primary DNS server

Added lines 430-431:

I will add to this how to if I get Dynamic DNS up and running.

August 08, 2006, at 02:44 PM by Lee Kimber -- Initial creation of Build DNS Server page
Added lines 1-431:

Configure a Master or Primary DNS server

This is the first step I took in working towards getting a DHCP-DDNS-enabled Unslung box up and runnning. I haven't had time to work on the DHCP and Dynamic part of this yet. When I do I will document it if I succeed. What follows are the steps to create a working primary DNS server.

Install

Get an Unslung system up and working. I used Unslung v6.8 Beta for mine, running on a 512Mb flash drive (until I can pick up a 2.5” laptop disk from eBay. It will give significantly better performance). Update, add unslung-feeds, update again. I also install openssh and coreutils by default.

Install bind:

ipkg install bind

This will install a copy of bind9.

Configuration

Now to configure it. There's so much contradictory material on the Web about configuring bind that it's easy to see why people struggle. The following steps work, though at the time of writing I still have not got it to resolve non-fully qualified hostnames. Meaning: it resolves the internal network host 'www.leedomain.com' to the correct IP address but will not resolve 'www' to any IP address. If any DNS gurus can see what I need to change to enable that please update this page.

For hygiene reasons, I created all my configuration files in the /root/ directory and copied them into the /opt/etc/named/ directory each time I was ready to test the configuration. You may want to do this in a non-root user directory.

The overview of the process is:

Write the required system config files:

  • named.conf

Write desired zone files:

  • db.localhost
  • db.localhost.rev
  • db.leedomain.com
  • db.192.168.1.rev

Write a file for lookups that cannot be internally resolved:

  • root.servers

All of the above files will eventually go into a directory called /opt/etc/named/. Check if it is there and create it if it isn't by typing:

mkdir /opt/etc/named

Create an rndc.key file:

/opt/sbin/rndc-confgen -a

This should create a file called rndc.key in /opt/etc/named/. You may not need this if you are not going on to do dynamic DNS. It's part of the system that allows other applications - such as an rndc-enabled DHCP server – to update bind's confiiguration files. Actually, you may not need it if even you do go on to work on DDNS. That's because the optware bind package also installs dnssec-keygen, which appears to also create a key suitable for rndc applications to use. In reading on this, I have not found my way through the ins and outs of each key-creation method.

Once you've created all the files, copy the bind configuration and zone files from /root/ (or wherever you created them) to /opt/etc/named. Then start the server for testing.

That's the overview. Here are the configuration and zone files in more detail.

Named.conf

Notes about this file.

The 'logging' section is commented out until after testing is complete. This is because this logging separates start-up messages finto syslog and running messages into a user-specified log. Keeping them all together during testing is quicker.

# Goes in /opt/etc/named/named.conf
#key "rndc-key" {
#        algorithm hmac-md5;
#        secret "VDHtbx5AHIeDC/YmTPd9HA==";
#};

acl "home" { 192.168.1.0/24; 127.0.0.1; };

options {
        directory "/opt/etc/named";
        allow-query { "home"; };
        allow-recursion { 192.168.1.0/24; 127.0.0.1; };
        forwarders { 192.168.1.1; };
};

controls {
        inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
};

// log to /var/log/named/example.log all events from info UP in severity (no debug)
// defaults to use 3 files in rotation
// BIND 8.x logging MUST COME FIRST in this file
// BIND 9.x parses the whole file before using the log
// failure messages up to this point are in (syslog) /var/log/messages
//
//logging {
//  channel leedomain_log {
//   file "/var/log/leedomain.log" versions 3 size 2m;
//   severity info;
//   print-severity yes;
//   print-time yes;
//   print-category yes;
//};
//category default {
//  leedomain_log;
//};
//};

// Add local zone definitions here.
zone "localhost" {
        type master;
        file "db.localhost";
        allow-update { none; };
        notify no;
};


zone "0.0.127.in-addr.arpa" {
        type master;
        file "db.localhost.rev";
        allow-update { none; };
        notify no;
};

zone "leedomain.com" {
        type master;
        file "db.leedomain.com";
        allow-update { key "rndc-key"; };
        notify yes;
};

zone "1.168.192.in-addr.arpa" {
        type master;
        file "db.192.168.1.rev";
        allow-update { key "rndc-key"; };
        notify yes;
};

zone "." {
        type hint;
        file "root.servers";
};

//; beleive the below is not necessary as included above
include "/opt/etc/named/rndc.key";

db.localhost

$TTL    86400 ; 24 hours could have been written as 24h
$ORIGIN localhost.
; line below = localhost 1D IN SOA localhost root.localhost
@  1D  IN        SOA @  root (
                              2006080801 ; serial
                              3H ; refresh
                              15 ; retry
                              1w ; expire
                              3h ; minimum
                             )
@  1D  IN  NS @
   1D  IN  A  127.0.0.1

db.localhost.rev

$TTL    86400 ;
; could use $ORIGIN 0.0.127.IN-ADDR.ARPA.
@       IN      SOA     localhost. root.localhost.  (
                        2006080801 ; Serial
                        3h      ; Refresh
                        15      ; Retry
                        1w      ; Expire
                        3h )    ; Minimum
        IN      NS      localhost.
1       IN      PTR     localhost.

db.leedomain.com

; leedomain.com
$TTL    604800
@       IN      SOA     ns1.leedomain.com.      root.leedomain.com.     (
                2006080801 ; Serial
                    604800 ; Refresh
                     86400 ; Retry
                   2419200 ; Expire
                   604800) ; Negative Cache TTL
;
@       IN      NS      ns1
        IN      MX      10 seanas1
        IN      A       192.168.1.78
ns1     IN      A       192.168.1.79
seanas1 IN      A       192.168.1.78

db.192.168.1.rev

$TTL    86400   ; 1 day
$ORIGIN 1.168.192.in-addr.arpa.
@       1D      IN      SOA  ns1.leedomain.com. root.leedomain.com.     (
                2006080801 ; Serial
                    604800 ; Refresh
                     86400 ; Retry
                   2419200 ; Expire
                   604800) ; Negative Cache TTL
;
; Name servers
                        IN NS   ns1.leedomain.com
;
; Fixed host mappings allegedly inserted by DDNS

root.servers

;       This file holds the information on root name servers needed to
;       initialize cache of Internet domain name servers
;       (e.g. reference this file in the "cache  .  "
;       configuration file of BIND domain name servers).
;
;       This file is made available by InterNIC
;       under anonymous FTP as
;           file                /domain/named.root
;           on server           FTP.INTERNIC.NET
;       -OR-                    RS.INTERNIC.NET
;
;       last update:    Jan 29, 2004
;       related version of root zone:   2004012900
;
;
; formerly NS.INTERNIC.NET
;
.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
;
; formerly NS1.ISI.EDU
;
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     192.228.79.201
;
; formerly C.PSI.NET
;
.                        3600000      NS    C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12
;
; formerly TERP.UMD.EDU
;
.                        3600000      NS    D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.      3600000      A     128.8.10.90
;
; formerly NS.NASA.GOV
;
.                        3600000      NS    E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10
;
; formerly NS.ISC.ORG
;
.                        3600000      NS    F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.      3600000      A     192.5.5.241
;
; formerly NS.NIC.DDN.MIL
;
.                        3600000      NS    G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
.                        3600000      NS    H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.      3600000      A     128.63.2.53
;
; formerly NIC.NORDU.NET
;
.                        3600000      NS    I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17
;
; operated by VeriSign, Inc.
;
.                        3600000      NS    J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.      3600000      A     192.58.128.30
;
; operated by RIPE NCC
;
.                        3600000      NS    K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.      3600000      A     193.0.14.129
;
; operated by ICANN
;
.                        3600000      NS    L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.      3600000      A     198.32.64.12
;
; operated by WIDE
;
.                        3600000      NS    M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.      3600000      A     202.12.27.33
; End of File

These files reflect my internal test domain 'leedomain.com', my internal network is 192.168.1.0/24 and, of course, my host names and their IP addresses. Edit these files to suit your domain, network, and host names.

Testing

At this point you could start the bind server by issuing a 'start' argument to the initialisation script that the ipkg installation routine installed. But I advise you to open another ssh session to the server and watch the syslog file in realtime as you start the bind server in the original ssh window. Once you've opened the second ssh session, issue the command:

tail -f /var/log/messages

to see incoming messages as you start the bind server.

Now go to the original ssh window and start the bind server by issuing the command:

/opt/etc/init.d/S09named start

All being well you should see the cursor return to a command prompt. In the second window, you should see action and error messages (if any!).

Useful things to look out for here are:

  1. Is the word 'error' showing up anywhere? Typically, it shows up through typos in the naming of zone files, that shows up as a file not found error.
  2. Syntax problems in the named.conf file will be indicated with a line number after the file's name.

Fix any errors, copy the repaired files to the /opt/etc/named/ directory and restart the bind server with the command”

/opt/etc/init.d/S09named restart

Watch that /var/log/messages file for errors.

If the sever looks as though it started correctly, you can test if it is visible and working to your LAN clients. I test that it is visible by using nmap on a separate Linux box, with the command:

nmap -sS <DNS_server_IP>

You don't have to use -sS. I do recommend you scan all the server's porsts though so that you know what else is visible on that machine.

Assuming that nmap revealed that the server is listening on DNS port 53, you can continue to use the Linux client to test it. The following command will ask the system to resolve www.bbc.co.uk.

dig @<DNS_server_IP> www.bbc.co.uk

In the result that comes back, you should see a section called 'ANSWER SECTION'. It should contain an IP address that a known-working DNS server gives you (or a nearby IP address, at least). Here's how this test looks on my Unslung DNS server:

; <<>> DiG 9.3.2 <<>> @192.168.1.79 www.bbc.co.uk
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26154
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.bbc.co.uk.                 IN      A

;; ANSWER SECTION:
www.bbc.co.uk.          122     IN      CNAME   www.bbc.net.uk.
www.bbc.net.uk.         292     IN      A       212.58.227.71

;; AUTHORITY SECTION:
bbc.net.uk.             92572   IN      NS      ns0.thdo.bbc.co.uk.
bbc.net.uk.             92572   IN      NS      ns0.thny.bbc.co.uk.

;; ADDITIONAL SECTION:
ns0.thdo.bbc.co.uk.     6172    IN      A       212.58.224.20
ns0.thny.bbc.co.uk.     6172    IN      A       212.58.240.20

;; Query time: 75 msec
;; SERVER: 192.168.1.79#53(192.168.1.79)
;; WHEN: Tue Aug  8 14:33:23 2006
;; MSG SIZE  rcvd: 151

So that we know what a problem looks like, let's try the test with a known-non-existent web address. We can do that by dropping a 'w' from 'www.bbc.co.uk'.

dig @<DNS_server_IP> ww.bbc.co.uk

; <<>> DiG 9.3.2 <<>> @192.168.1.79 ww.bbc.co.uk
; (1 server found)
;; global options:  printcmd
;; connection timed out; no servers could be reached

Now that we know that our server is working, let's see if it is correctly supplying our local, manually-entered client IP addresses. In the LAN zone file, we added a host called SEANAS1? at 192.168.1.78.

dig @<DNS_server_IP> seanas1.leedomain.com

; <<>> DiG 9.3.2 <<>> @192.168.1.79 seanas1.leedomain.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19299
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;seanas1.leedomain.com.         IN      A

;; ANSWER SECTION:
seanas1.leedomain.com.  604800  IN      A       192.168.1.78

;; AUTHORITY SECTION:
leedomain.com.          604800  IN      NS      ns1.leedomain.com.

;; ADDITIONAL SECTION:
ns1.leedomain.com.      604800  IN      A       192.168.1.79

;; Query time: 76 msec
;; SERVER: 192.168.1.79#53(192.168.1.79)
;; WHEN: Tue Aug  8 14:40:22 2006
;; MSG SIZE  rcvd: 89

Success!

If we know that our DNS server is working, it's likely that a failure to resolve this local host would indicate a problem in our zone file.

If we want cleaner logging during operation we can now uncomment out the logging lines in named.conf:

So:

//logging {
//  channel leedomain_log {
//   file "/var/log/leedomain.log" versions 3 size 2m;
//   severity info;
//   print-severity yes;
 //  print-time yes;
//   print-category yes;
//};
//category default {
//  leedomain_log;
//};
};

becomes

logging {
  channel leedomain_log {
   file "/var/log/leedomain.log" versions 3 size 2m;
   severity info;
   print-severity yes;
   print-time yes;
   print-category yes;
};
category default {
  leedomain_log;
};
};

Copy the edited named.conf to /opt/etc/named/ and restart the server. Doing this will leave /var/log/messages to catch system problems, such as a failed bind start up but leave your specified log file to catch bind's running problems.

view · edit · print · history · Last edited by Silvia Schuckert.
Based on work by Silvia Schuckert, Lee Kimber, and Taylor.
Originally by Lee Kimber.
Page last modified on November 25, 2007, at 03:06 PM